< parsimony_>
hi Bitcoin Core devs and affiliated parties... has anyone with some reputation considered offering the big-blockists a method of saving face while coming around to support Segwit?
< parsimony_>
They might actually *want* to support it but can't do to the need to have an out that will allow the saving of face
< parsimony_>
i thought this would be the most appropriate forum for floating this kind of suggestion, i dunno
< BashCo_>
I'm seeing people just look into the benefits for themselves instead of listening to bad info. Most people just want more tx capacity and they don't care about the details. Segwit will increase tx volume more than BIP109 and is backward compatible.
< dcousens>
(may be the wrong channel... #bitcoin?)
< gmaxwell>
bad incentives, signal segwit, take the fees, don't actually enforce it later.
< dcousens>
if you signal though, it would still trigged BIP9 though?
< dcousens>
trigger*
< sipa>
dcousens: we don't want BIP9 to trigger if isn't actually enforced...
< dcousens>
sipa: so the concern would be miners not producing segwit blocks after activation?
< dcousens>
(for example)
< dcousens>
I mean, wouldn't the fee market carry it on past that point, you'd miss out on fees post-activation since you wouldn't be able to include certain transactions without segwit blocks?
< gmaxwell>
People, perhaps even you, are mistaking version bits for a vote. It isn't from an engineering perspective, and can't be. A vote is a statement of what you want. What versionbits are attempting to do is quorum sensing-- trying to determine what you will do-- so that all participants can do it at once. For it to achieve its end there should be little to no incentive to dishonestly signal it.
< gmaxwell>
If in my efforts to contact users of the system or the mailing list thread had indicated that it wasn't universally (or nearly so) wanted, I would have opposed including it. The assumption is that it's wanted. Purpose of BIP9 is so that it will only happen once miners would actually enforce it.
< luke-jr>
if it was just a minor fee difference, it might be little enough to not produce too-bad false-signal incentives, but rejecting the entire tx is too much IMO
< bitcoin-git>
[bitcoin] pstratem opened pull request #9227: Make nWalletDBUpdated atomic to avoid a potential race. (master...2016-11-26-nwalletdbupdated-race) https://github.com/bitcoin/bitcoin/pull/9227
< luke-jr>
(especially if it can function inverted)
< dcousens>
gmaxwell: I understand it isn't a vote, but, it is my understanding that the 'economic consensus' should guide the miners into what they should support (political incentives aside), my point in referencing the above was to discuss the idea of how users could help inform miners, economically, what they wanted to be using [and be supported]
< gmaxwell>
Sure. but they can send email-- point being, gimmicks are no good if they create bad incentives.
< bitcoin-git>
[bitcoin] TheBlueMatt opened pull request #9230: Fix some benign races in timestamp logging (master...2016-11-loglocks) https://github.com/bitcoin/bitcoin/pull/9230
< BlueMatt>
cfields (or someone with more autotols knowledge) want to look at #9229? build fails on windows but autotools looks like it should detect when inet_pton doesnt exist and then ifdef it out?