[bugfix] Do not send witnesses in cmpctblock

[sipa]

This is a small bugfix for #8149: we should not sent witnesses inside cmpctblock without negotiating whether the peers support them.

[TheBlueMatt]

The BIP specifies you should encode transactions exactly as they would be in "tx" messages, so this does not really fix the issue - ultimately we need to inform the compact block stuff whether to include the witnesses (though its probably easier/better to just change the spec to require witness-inclusion).

[sipa]

I'm working on a spec for making witness + compactblocks work (using sendcmpct version 2 to indicate that blocktxn, cmpctblock should include witnesses, and that short ids should be based on wtxids), which seems to work quite well. This is just a minimal change to prevent things from breaking when witness nodes start talking to older compactblocks-aware nodes.

[TheBlueMatt]

Correct me if I'm wrong, but transaction encoding/hash with witness for a non-witness transaction and transaction encoding/hash without witness are the same, no? I'd think no one would ship code with compact blocks before we fix the witness/compact combination, so might as well just remove the code for non-witness compact with version 1...it'll only break current master nodes after segwit activates, so I'm not too worried.

[sipa]

0.13.0 will ship with compact blocks, but very likely without segwit activation. A potential future 0.13.1 with segwit activation can't send witnesses to 0.13.0 nodes, as they would consider those blocks invalid and/or the shorttixds would mismatch. You need to negotiate which parts of transactions are relevant unless you want relay between old and new nodes to be severely impacted any time a new piece of data is defined in transactions. The code is quite small, see my segwitcb branch.

[TheBlueMatt]

I mean you can still define version 1 to include witnesses, it doesnt effect the current protocol for non-witness transactions and continues to work fine, no?

[sipa]

Yes, you could. But it would mean 0.13.1 can't send to 0.13.0 nodes.

[TheBlueMatt]

Sure they could! 0.13.0 will know how to deserialize with witnesses,
even if the block-processing-with-witnesses is not enabled. I think you
meant to say 0.13.0 wont be able to send to 0.13.1, because it would
drop the witnesses from processing, which I'd think is true?

On 06/28/16 06:39, Pieter Wuille wrote:

Yes, you could. But it would mean 0.13.1 can't send to 0.13.0 nodes.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#8271 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AAnoHqS1W2YWU0XIBATMqAzGSoiBp9geks5qQMGZgaJpZM4I-m8y.

[sipa]

To 0.13.0 nodes these blocks should not have witnesses, as there has not been a softfork to define them. Sure it could strip them off before processing when received from a 0.13.1 node, but that is inefficient (especially for a protocol that tries to minimize bandwidth) and does not solve the problem for other potential future data extensions to the serialization.

0.13.1 will never request from 0.13.0 after segwit activation, as blocks are only downloaded from other peers that can provide witnesses.

[sipa]

The discussion above should probably happen elsewhere.

The PR here is a pure bugfix, though one that would only occur on testnet, and if there is ever a client on the network which does support BIP152 but not segwit.

[sdaftuar]

utACK. We should merge this for 0.13.0.

[laanwj]

utACK 252675e