7485488e907e236133a016ba7064c89bf9ab6da3 broke lightning corner case #13256

sendrawtransaction now rejects

02000000000101ef682765dd04d56bfbda730487535294e58f0a70285fcc86c3e2674b3585f80c000000000000000000010000000000000000016a03483045022100bbfbaad7eda35238fb9a0da596ec1229b75aaccce4b19d97df02dfb388a82795022061f25ee6a2097fb8d5504ab4f77b2e12215f8e3cc17cda711919ff6091d897e701008976a9148517b784dbe99eb8d432a2f7981a851e7be2c7b78763ac6721030b652621b88baa0b5b221321dd297e3abee663e127b658ee26421f231c8e0be77c8201208763a91418f5da1d5c63d87c9cb7944ce2b20a2f09481e2188527c2103f2c637a05e16f4f2524a030983a3ec704281c780bd71f8cccdd3a3172a09bf3452ae6775016db175ac68686d000000

This is what happens when a lightning output is now considered too small for current fee levels: we create an OP_RETURN spend to give it to miners. With master branch (commit 4cfe17c3382ba750131cdc8703b2978132822070) we now get:

sendrawtx exit 26, gave error code: -26?error message:?tx-size-small (code 64)?'

We could choose to abandon the UTXO in this case, but I consider than antisocial.

@jl2012

@fanquake Not an RPC issue: do you have a label for 'policy' or 'standardness'?

Edit: looks like 'TX fees and policy' is the right one. Thanks!

Since it's OP_RETURN, you could just pad the output until the entire tx non-witness size is 82 bytes. Although that could be considered a bit rude.

@rustyrussell: are you sure it was https://github.com/bitcoin/bitcoin/commit/4cfe17c3382ba750131cdc8703b2978132822070? This commit did only change wallet files and its very unlikely it would have changed something in the area of standardness.

NM: overlooked the OP desc where you refer to 7485488e907e236133a016ba7064c89bf9ab6da3 which makes sense.

I assume the miner donations would be more efficient (i.e. more likely to be included by miners due to higher fee per vsize) if the inputs were bundled into a single tx with appropriate sighash flags. This could be done per wallet or even by a third party taking into account inputs from different wallets.

Is to possible to use an ANYONECANPAY|NONE signature, instead of using OP_RETURN? I think this would be more efficient with many such inputs

Well if you're burning to fee, its probably easier to just keep around a queue of them and batch them eventually after you have a few (or, at that point, actually claim the money with some other input).

Waiting for batching almost certainly means they'll never be spent. Wallets have to maintain significant state to spend these outputs (they were generated by mutual agreement with a peer), which will be lost in the long run.

We'll switch to:

1. Use a lower fee: we still might have a chance of spending the tx and getting some non-dust input in our wallet.
2. Use sighash_none, and hope someone steals it :)

@rustyrussell Why you "hope" someone steals it? You could use SIGHASH_NONE AND keep a queue of these signatures for claiming it later!