Transcript for #bitcoin-dev 2016/01/20

00:00 maaku sipa: so the coinbase scriptWitness is transmitted with the block, but contains extra data not hashed as part of the witness tree?
00:00 sipa maaku: indeed
00:00 maaku ok thank you.
00:02 sipa it allows chaining future consensus structures into it
00:02 sipa in a way that doesn't require mining software to know what kinds of commitments are to be created
00:05 maaku sipa: right I'm coding up an alternative (specify the path up to 7-deep in a single byte) and want to make sure I understand the code there first
00:07 sipa maaku: i was planning to take that approach first too, but I believe it's wasteful for consensus commitments to do that
00:07 sipa maaku: i was planning to take that approach first too, but I believe it's wasteful for consensus commitments to do that
00:07 sipa non-consensus commitments can use a generic tree
00:07 sipa non-consensus commitments can use a generic tree
00:07 Lauda Sipa some people are seriously confused in regards to SegWit.
00:07 sipa non-consensus commitments can use a generic tree
00:07 Lauda Sipa some people are seriously confused in regards to SegWit.
00:08 maaku sipa: I'm not convinced that the witness tree is so privledged as to take a high-level slot in future trees
00:08 maaku e.g. more important than header commitments or aux mining proofs
00:16 maaku sipa: so you can encode an up-to-7-depth path in a single byte. the highest set bit is the level, and the bits below that determine left/right branching, right?
00:16 maaku 0b00000001 is the root 0b00000010 is the left branch of root, 0b00000011 is the right branch of root, etc.
00:16 sipa maaku: where does that byte go?
00:17 maaku so the proposal is this: between 0xaa21a9ed and the 32-byte root hash you put that byte
00:17 maaku so the proposal is this: between 0xaa21a9ed and the 32-byte root hash you put that byte
00:17 maaku and the scriptWitness for coinbase is up to 7 hashes for the other branches
00:18 maaku and for future extensions the commitment is checked to be at least 37 bytes, and the extra bytes between 0xaa21a9ed and the witnessPath, merkleRoot are ignored
00:19 sipa what other branches?
00:19 maaku so right now it would be [0xa21a9ed, witnessPath, merkleRoot]. after skip list header comments, maybe [0xaa21a9ed, skipListPath, witnessPath, merkleRoot]
00:20 maaku sipa: well the mining code now would be just [magic, 0x01, witness root] and witnessScript is empty
00:21 maaku but in the future we could have an arbitrary tree structure that gives preference to commitments that are more proof-size sensitive (e.g. stuff affecting mobile wallets or merged mining)
00:21 maaku and it's upgradeable because all the commitments really could be placed anywhere in the first 7 levels, but there'd be sensible defaults that results in a huffman-like tree structure
00:21 maaku and it's upgradeable because all the commitments really could be placed anywhere in the first 7 levels, but there'd be sensible defaults that results in a huffman-like tree structure
00:31 viajero what time zone is used for the logs?
00:31 sipa maaku: ok, need to get to the airport; i don't fully understand your proposal yet, so i can't comment
00:32 viajero (the logs of this channel)
00:32 maaku viajero: UTC I would presume
00:32 maaku viajero: UTC I would presume
00:32 maaku also whoever is maintaining the logs, lines are being logged in triplicate
00:32 sipa indeed, UTC
00:33 maaku sipa: ok safe travels
00:33 viajero yeah, needs soime fixing. very inconvenient to go through
00:33 viajero yeah, needs soime fixing. very inconvenient to go through
00:34 Lauda but forcing pruned blocks without witness by default. and only letting segwit implementations have the special parameter to enable archival mode.. not great"
00:34 Lauda "segwit. all the little fixes and future new features... great.
00:34 Lauda Does this have any negative (possible) effects?
00:34 Lauda Does this have any negative (possible) effects?
00:34 maaku Lauda: "forcing pruned blocks without witness by default" <-- ??
00:35 Lauda I have no idea what this is exactly supposed to mean.
00:35 Lauda I have no idea what this is exactly supposed to mean.
00:35 sipa the initial implementation will download, verify, and store all witnesses
00:35 Lauda People just have a general understanding of SegWit that is wrong.
00:35 sipa the only thing that changes is that it introduces a future mode where witnesses are kept less long than other block data
00:36 Lauda sipa they get deleted after some time or?
00:36 Lauda sipa they get deleted after some time or?
00:36 maaku So what sipa said. I *think* the quote might be talking about non-upgraded nodes.
00:36 Lauda Possibly yes.
00:36 Lauda Possibly yes.
00:36 maaku But the consequences of that are the same as with any other soft-fork. E.g. pre-P2SH clients don't understand the P2SH outputs
00:36 sipa about non-upgraded nodes, read: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/012014.html
00:42 viajero I haven't followed the recent core vs. classic drama closely but I was wondering if there already have been any efforts made to find a mediator who is trusted from both sides (like maybe nick szabo or anyone else who is willing and appropriate) to give it one last try to calm things down and find some kind of consensus without the danger of some kind of hostile takeover (classic) and half or more of the core team stepping down in the
00:42 viajero process?
00:43 Lauda Thanks again sipa, maaku
00:43 Lauda Thanks again sipa, maaku
00:54 Lauda Sipameaning those that dont even have a segwit client are left with shitty blocks of uncheckable data..
00:54 Lauda meaning the only way to get full with signature data.. is to upgrade to segwit implementation.. because to get archival data you need to push a parameter only available if your a segwit user.
00:54 Lauda Sipameaning those that dont even have a segwit client are left with shitty blocks of uncheckable data..
00:54 Lauda which is removing freedom of choice of differing implementations.. as it forces those who want to be archival nodes, to use segwit..
00:54 Lauda sipa*
00:54 Lauda sipa*
00:55 sipa point them to my ML post on the security of soft forks
00:55 sipa it's no so black and white
00:55 Lauda Done.
00:55 Lauda Done.
00:57 maaku Lauda: I'm sure someone could code up a client that downloaded that data but didn't validate it. Not sure what the point would be though.
00:57 maaku viajero: The problem is that the point of contention is political, not technical, it seems.
00:58 maaku There's a lot more going on than you can see on Reddit or the forums, and there are people acting as mediators as well as some direct conversations going on.
00:59 viajero maaku: yeah, I get the same impression.
01:00 viajero ok, so is the impression incorrect that the classic hardfork might get more than 75% anytime and things might fall appart son after (or at least, many core devs aren't willing to contribute to classic
01:00 maaku viajero: but the basic problem is political, and the stance of bitcoin core (as much as we can generalize a disparate group of developers) is that such decisions should be made on a technical, not political basis
01:00 maaku so.. what to do? I don't know. this is probably off topic for #bitcoin-dev but I'm not sure where to send it
01:01 viajero yeah, thats why I ended up here. didn't know where else to aks these questions
01:02 Lauda maaku so it would be possible to code a client that would receive full txdata, with the signatures?
01:02 Lauda maaku so it would be possible to code a client that would receive full txdata, with the signatures?
01:03 sipa Lauda: yes, obviously. any segwit supporting client will do that
01:03 Lauda sipa what about a client that does not support segwit?
01:03 maaku Lauda: why would you care to?
01:03 Lauda Just out of curiousity.
01:04 sipa they won't see the witness data
01:04 sipa but they also don't care about it
01:04 Lauda Someone mentioned it. So it is not possible for a client that does not support Segwit to see the witness data?
01:04 Lauda Someone mentioned it. So it is not possible for a client that does not support Segwit to see the witness data?
01:04 maaku Lauda: it is certainly possible
01:04 maaku Lauda: but it's meaningless to do.
01:04 maaku Lauda: but it's meaningless to do.
01:04 sipa of course it is "possible"... but that "possible" just means supporting segwit
01:05 maaku viajero: maybe the badly named bitcoin core slack? slack.bitcoincore.org
01:05 Chiwawa_ imagine people wanted to stick with bitcoin-core 0.11 and not upgrade, will they be cut off from getting witness data, by defalt if segwit gets consensus?
01:05 Chiwawa_ imagine people wanted to stick with bitcoin-core 0.11 and not upgrade, will they be cut off from getting witness data, by defalt if segwit gets consensus?
01:05 maaku (I'm not there though)
01:05 viajero my thinking is, that even if the contention is political, isn't it worth trying to find someone who mediates on "top level" before everything breaks apart? is there even anyone who might fit in that role? (or is my impression just plain wrong that things are on the brink of falling apart?)
01:06 maaku Chiwawa_: they could certainly code up their wallet to get it, but again what's the point? are they going to check the witness themselves?
01:06 Lauda maaku with 'check the witness' you mean validate signatures?
01:06 maaku viajero: perhaps this post might give you some perspective on the other side : https://www.reddit.com/r/btc/comments/41fup9/to_core_developers_we_are_not_firing_you_we_are/cz2c02w
01:06 Lauda or?
01:07 maaku (the point being that if a political mediation was necessary, bitcoin's failed anyway regardless of the outcome)
01:07 maaku Lauda: yes
01:07 Lauda maaku can't they validate them in this specific case?
01:07 maaku it's more than just ECDSA checks, but yes "check the signatures" is what I meant
01:07 maaku Lauda: that's the only difference between a segwit and non-segwit client
01:07 Lauda So a non-segwit client can get the signatures
01:07 Lauda but is unable to
01:07 Lauda validate them
01:08 Lauda non-segwit client as in one coded to get them
01:08 maaku Lauda: eeehhh this is really getting philosophical at this point
01:08 Lauda Well let's say in theory
01:08 maaku the segwit patch set does really two things (1) fetch the witness, (2) validate the witness
01:08 Lauda Someone created a client that can download the data but does not support SegWit.
01:08 maaku you only need to do (1) if you are going to do (2), otherwise you're downloading stuff you're never going to use anyway
01:09 maaku and if you do (1) and (2) ... you're a segwit client
01:09 Lauda In theory a non segwit client could do (1) but not (2), right?
01:09 maaku see I don't know what "does not support segwit" means
01:09 maaku can you explain what you mean?
01:10 Lauda A client that does not want to use SegWit.
01:10 Lauda A client that does not want to use SegWit.
01:10 maaku what do you mean "use" segwit?
01:10 Lauda implement?
01:10 maaku are you talking about transaction validation, or transaction generation?
01:10 viajero maaku: I read that already. thats one of the posts that gave me the impression that things might fall apart if classic wins. I personally would always support classic over core. but right now it seems that classic might win and what you are describing in your reddit post will actually happen very soon
01:10 viajero maaku: I read that already. thats one of the posts that gave me the impression that things might fall apart if classic wins. I personally would always support classic over core. but right now it seems that classic might win and what you are describing in your reddit post will actually happen very soon
01:10 Lauda maaku let's say Bitcoin Core 0.11
01:11 Lauda can it do (1)?
01:11 Lauda once SegWit is activated
01:11 maaku viajero: i don't have a crystal ball
01:11 viajero fuck, sorry. I would always support core over classic!!! my msitake....
01:11 viajero fuck, sorry. I would always support core over classic!!! my msitake....
01:12 maaku viajero: heh i figured from context that's what you meant
01:12 maaku viajero: heh i figured from context that's what you meant
01:12 maaku Lauda: no, but hypothetically you could back-port just the part that downloads the witness data
01:12 gijensen How can Classic win if it has no code?
01:12 gijensen How can Classic win if it has no code?
01:12 maaku all you would do is waste disk space, but yes
01:12 maaku gijensen: that is the essence of the issue
01:13 Lauda maaku that's my question. It would be possibly to modify a client so that it does (1) without supporting SegWit? Because in order to do (2) it would have to implement changes necessary for SegWit.
01:13 viajero well, as I understand it, it wins the moment it gets more than 75% hashing power. the crowd doesn't seem to care, that classic has no proper team of developers
01:13 viajero well, as I understand it, it wins the moment it gets more than 75% hashing power. the crowd doesn't seem to care, that classic has no proper team of developers
01:14 maaku gijensen: because core is all evil autocrats that took VC money and are perverting bitcoin to our own ends. so we'll take a demonstrably worse solution in every way and use that just because f*ck you core.
01:14 Lauda viajero not sure if this is the right channel for that?
01:14 gijensen viajero, I don't think it does that, I just looked at a diff, it seems to do nothing?
01:14 gijensen viajero, I don't think it does that, I just looked at a diff, it seems to do nothing?
01:15 gijensen maaku, that's what it looks like to me haha
01:16 maaku Lauda: again it hinges on what you mean by "support segwit" -- you could for example take a segwit-validating client and make it only send to non-segwit addresses
01:16 maaku just like you can take a current version of bitcoin core and make it only send to 1- addresses instead of 3- addresses