Re: [bitcoin-dev] Increasing the blocksize as a (generalized) softfork.
So I'm very strongly against this "generalized softfork" idea -- I also don't see how upgraded nodes and non-upgraded nodes can possibly end up with the same UTXO set. The only way for non-upgraded nodes to get the correct UTXO set is to upgrade. It is important to keep in mind this was proposed as an alternative to a hardfork. With a hardfork the UTXOs also diverge as upgraded and non-upgraded clients follow different chains. --joe. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Increasing the blocksize as a (generalized) softfork.
Jonathan Toomim [j...@toom.im] wrote: > > The generalized softfork method has the advantage of being merge-mined That's an over-generalization. There are two kinds of soft-forks WRT mining, those which: 1. involve new validation rules by data-hiding from non-upgraded modes (e.g. extension blocks, generalized softfork) 2. involve NO new validation logic (e.g. P2SH) Miners which are not validating transactions *should* be deprived of revenue, because their role is transaction validation, not simply brute forcing sha256d. So I'm very strongly against this "generalized softfork" idea -- I also don't see how upgraded nodes and non-upgraded nodes can possibly end up with the same UTXO set. > > Once a chain is seen to be 6 or more blocks ahead of my chain tip, we should > > enter "zombie mode" and refuse to mine or relay > > I like this method. However, it does have the problem of being voluntary. If > nodes don't upgrade to a version that has the latent zombie gene long before a > fork, then it does nothing. Which is why it should be put into core long before forks. ;-) -- Cheers, Bob McElrath "For every complex problem, there is a solution that is simple, neat, and wrong." -- H. L. Mencken ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Increasing the blocksize as a (generalized) softfork.
On Dec 30, 2015, at 3:49 PM, Jonathan Toomim wrote: > Since we've been relying on the trustworthiness of miners during soft forks > in the past (and it only failed us once!), why not make it explicit? (Sorry for the premature send.) signature.asc Description: Message signed with OpenPGP using GPGMail ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Increasing the blocksize as a (generalized) softfork.
On Dec 30, 2015, at 11:00 AM, Bob McElrath via bitcoin-dev wrote: > joe2015--- via bitcoin-dev [bitcoin-dev@lists.linuxfoundation.org] wrote: >> That's the whole point. After a conventional hardfork everyone >> needs to upgrade, but there is no way to force users to upgrade. A >> user who is simply unaware of the fork, or disagrees with the fork, >> uses the old client and the currency splits. >> >> Under this proposal old clients effectively enter "zombie" mode, >> forcing users to upgrade. > > This is a very complex way to enter zombie mode. Another way you could make non-upgraded nodes enter zombie mode is to explicitly 51% attack the minority fork. All soft forks are controlled, coordinated, developer-sanctioned 51% attacks against nodes that do not upgrade. The generalized softfork technique is a method of performing a soft fork that completely eliminates any usefulness to non-upgraded nodes while merge-mining another block structure to provide functionality to the nodes who have upgraded and know where to look for the new data. Soft forks are "safe" forks because you can trust the miners to censor blocks and transactions that do not conform to the new consensus rules. Since we've been relying on the trustworthiness of miners during soft forks in the past (and it only failed us once!), why not The generalized softfork method has the advantage of being merge-mined, so miners don't have to lose any revenue while performing this 51% attack against non-upgraded nodes. But then you're stuck with all of your transactions in a merge-mined/commitment-based data structure, which is a bit awkward and ugly. But you could avoid all of that code ugliness by just convincing the miners to donate some hashrate (say, 5.1% if the IsSupermajority threshold is 95%, or you could make it dynamic to save some money) to ensuring that the minority fork never has any transactions in the chain. That way, you can replace the everlasting code ugliness with a little bit of temporary sociopolitical ugliness. Fortunately, angry people are easier to ignore than ugly code. /s Maybe we could call this a softly enforced hard fork? It's basically a combined hard fork for the supermajority and a soft fork to make the minority chain useless. I don't personally think that these 51% attacks are useful or necessary. This is one of the main reasons why I don't like soft forks. I find them distasteful, and think that leaving minorities free to practice their own religions and blockchain rules is a good thing. But I could see how this could address some of the objections that others have raised about the dangers of hardforks, so I'm putting it out there. > Once a chain is seen to be 6 or more blocks ahead of my chain tip, we should > enter "zombie mode" and refuse to mine or relay I like this method. However, it does have the problem of being voluntary. If nodes don't upgrade to a version that has the latent zombie gene long before a fork, then it does nothing. signature.asc Description: Message signed with OpenPGP using GPGMail ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] [BIP Draft] Decentralized Improvement Proposals
On Wednesday, December 30, 2015 6:22:59 PM Tomas wrote: > > The specification itself looks like an inefficient and bloaty reinvention > > of version bits. > > The actual assignment of version bits isn't clear from the > specification. Are you saying that any implementation that wants to > propose a change is encouraged to pick a free version bit and use it? That should probably be clarified in the BIP, I agree. Perhaps it ought to be assigned the same as BIP numbers themselves, by the BIP editor? (Although as a limited resource, maybe that's not the best solution.) > Furthermore, my proposal addresses the danger of forward-incompatible > changes; a hard-fork can no longer occur as every implementation will > agree on the active the set of rules even if it has not implemented > them. This seems to be lacking in the version bits proposal. I don't think that's possible. First of all, a hardfork can always occur, since this is something done by the economy and not (even possibly opposed to) miners. Furthermore, consider the change affecting how further rule changes are made, such as a PoW algorithm change. Luke ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] How to preserve the value of coins after a fork.
Emin, I have two technical criticisms of your proposal, and one economic criticism. >Unified miners would make sure that they mine transactions on Dum first, then >on Dee. Recall that Dee miners can always just take Dum transactions and stick >them in their blocks. This seems to contradict a later section that says that users can use Dee natively, without paying fees necessary to get a transaction into Dum. You can't have this both ways - either you can get a transaction into Dee without getting it into Dum first, or you can't. >Such an attack would be quite visible, and it would leave Dum vulnerable. >Unified clients could counter this launching a 51% counterattack on Dum. What if some other group that wants to hurt both Dum and Dee were to make a false-flag attack against Dee? Mutually assured destruction doesn't work if you can't accurately attribute attacks. >This would create some gentle pressure to explicitly unify the two chains (by >merging Dee and Dum at some compromise and doing away with Unified) I don't think a compromise would be reachable at that point - suppose one had a market cap of 1.2 billion, and the other had a market cap of 0.8 billion. How would the coins on the unified chain be distributed? You could give each chain an equal number of coins, but that's not fair to the people holding the more valuable coins. You could give each chain a number of coins proportional to the market cap, but that invites price manipulation. In any case, if you had a way of reaching compromise, why not use it instead of creating two chains? Overall, I think this proposal is a bad idea. >You seem to not be familiar with how multisig transactions on Bitcoin work - >99.9% of the time theyre hidden behind p2sh and there is no way to know what >keys are involved. Equally, multisig is just one of many complex scripts >possible. That doesn't end up mattering, though, as I understand his proposal. The unified client would just see that both validly spend an output with a scriptPubKey of OP_HASH160 0xabcdef... OP_EQUAL. On Wed, Dec 30, 2015 at 1:32 PM, Peter Todd via bitcoin-dev wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > > > On 30 December 2015 12:22:43 GMT-08:00, "Emin Gün Sirer" > wrote: >>On Wed, Dec 30, 2015 at 3:16 PM, Peter Todd wrote: >> >>> Note how transaction malleability can quickly sabotage naive notions >>of >>> this idea. >>> >> >>Bitcoin-United relies on a notion of transaction equivalence that >>doesn't >>involve the transaction hash at all, so it should be immune to >>malleability >>issues and compatible with segwit. >> > >From the post, two transactions are equal if they "consume the same >>inputs >>and result in the same outputs, not counting the miner fee. Simple >>pay-to-pubkey-hash and pay-to-script-hash transactions are >>straightforward. >>Multikey transactions are evaluated for equivalency by their inputs and >>outputs, so it is allowable for a 2-out-of-3 payment to be signed by >>one >>set of two keys on Dum and another set of two keys on Dee, as long as >>the >>transaction consumes the same coins and produces the same outputs. Not >>that >>we'll ever encounter such a case, but making this point helps >>pedagogically >>with getting across the notion of transaction equivalence. What counts >>are >>the consumed inputs and the destination and amounts of the outputs." > > You seem to not be familiar with how multisig transactions on Bitcoin work - > 99.9% of the time theyre hidden behind p2sh and there is no way to know what > keys are involved. Equally, multisig is just one of many complex scripts > possible. > > Look into what a segwit transaction hashes - that's a better notion of > non-malleable transaction. But even then lots of transactions are malleable, > and its easy to trigger those cases intentionally by third parties. > > Most likely any Bitcoin United scheme would quickly diverge and fail; much > simpler and more predictable to achieve convincing consensus, e.g. via proof > of stake voting, or Adam Bank's extension blocks suggestions. (or of course, > not trying to force controversial forks in the first place) > > -BEGIN PGP SIGNATURE- > > iQE9BAEBCgAnIBxQZXRlciBUb2RkIDxwZXRlQHBldGVydG9kZC5vcmc+BQJWhD9N > AAoJEMCF8hzn9Lncz4MH/0JPGVc2JLtD5q0I2w0vqmBqsoSzSueCtnKa2K1Ea10g > w9I4uhK7+cgfCLbofJznVHMChXu0uCxtWwqSj++uJx238TEupcu951gUhFfuPOeH > Egye8jmDkDFiB1P40kUSVk9N64Zt3kWLk4xSsfjawVHz/WWpM24Fn8k/bmI7JiLl > nmVwoBdRsTKffM/1dr8ix4U8YPSmJ7W+jAByNHUpSgc1R73YylqNT95pF8QD35df > dQwSK9DIc+2N4CKnp22xLvYeCivFjeS2Fm4kbcKQwMjcqlJ1mWghP/c8q/lzhaGN > Ac15/pgeHp8dPP8c81zkN9ps14rrnXoHnrzjiY+TwKY= > =FfK1 > -END PGP SIGNATURE- > > ___ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfo
Re: [bitcoin-dev] fork types (Re: An implementation of BIP102 as a softfork.)
On Wed, Dec 30, 2015 at 5:05 PM, Adam Back via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > There is also another type of fork a firm hard fork that can do the > same but for format changes that are not possible with a soft-fork. > I was drafting an email for a new thread with some links about this topic, instead I'll just send this as a reply now that we are writing down fork types... auxiliary blocks and evil soft-forks or forced soft-forks: https://bitcointalk.org/index.php?topic=283746.0 https://bitcointalk.org/index.php?topic=874313.0 soft-fork block size increase using extension blocks: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008356.html generalized soft-forks: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/012073.html bip102 forced soft-fork: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/012153.html extension blocks were also discussed in this interview: http://diyhpl.us/wiki/transcripts/bitcoin-sidechains-unchained-epicenter-adam3us-gmaxwell/ also there was something about a "soft-hard fork". some discussion from today re: origin of the term evil fork, evil soft-fork, forced soft-fork: https://www.reddit.com/r/Bitcoin/comments/3yrsxt/bitcoindev_an_implementation_of_bip102_as_a/cyg2g7q some much older discussion about extension blocks and sidechains: http://gnusha.org/bitcoin-wizards/2015-01-01.log some discussion about "generalized soft-forks" and extension blocks and evil soft-forks: http://gnusha.org/bitcoin-wizards/2015-12-20.log some discussion about evil forks and evil soft-forks and extension blocks: http://gnusha.org/bitcoin-wizards/2015-12-30.log segwit soft-fork makes use of a similar idea: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011865.html https://bitcoin.org/en/bitcoin-core/capacity-increases-faq http://diyhpl.us/wiki/transcripts/scalingbitcoin/hong-kong/segregated-witness-and-its-impact-on-scalability/ Note: I am taking the term "forced soft-fork" from petertodd; it's pretty much the same thing as "evil fork" in every way but intent. This is an x-post from https://bitcointalk.org/index.php?topic=1296628.msg13400092#msg13400092 - Bryan http://heybryan.org/ 1 512 203 0507 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] fork types (Re: An implementation of BIP102 as a softfork.)
> I guess the same could be said about the softfork flavoured SW implementation No, segregated witness https://bitcoin.org/en/bitcoin-core/capacity-increases-faq is a soft-fork maybe loosely similar to P2SH - particularly it is backwards and forwards compatible by design. These firm forks have the advantage over hard forks that there is no left-over weak chain that is at risk of losing money (because it becomes a consensus rule that old transactions are blocked). There is also another type of fork a firm hard fork that can do the same but for format changes that are not possible with a soft-fork. Extension blocks show a more general backwards and forwards compatible soft-fork is also possible. Segregated witness is simpler. Adam On 30 December 2015 at 13:57, Marcel Jamin via bitcoin-dev wrote: > I guess the same could be said about the softfork flavoured SW > implementation. In any case, the strategy pattern helps with code structure > in situations like this. > > 2015-12-30 14:29 GMT+01:00 Jonathan Toomim via bitcoin-dev > : ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] How to preserve the value of coins after a fork.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 30 December 2015 12:22:43 GMT-08:00, "Emin Gün Sirer" wrote: >On Wed, Dec 30, 2015 at 3:16 PM, Peter Todd wrote: > >> Note how transaction malleability can quickly sabotage naive notions >of >> this idea. >> > >Bitcoin-United relies on a notion of transaction equivalence that >doesn't >involve the transaction hash at all, so it should be immune to >malleability >issues and compatible with segwit. > >From the post, two transactions are equal if they "consume the same >inputs >and result in the same outputs, not counting the miner fee. Simple >pay-to-pubkey-hash and pay-to-script-hash transactions are >straightforward. >Multikey transactions are evaluated for equivalency by their inputs and >outputs, so it is allowable for a 2-out-of-3 payment to be signed by >one >set of two keys on Dum and another set of two keys on Dee, as long as >the >transaction consumes the same coins and produces the same outputs. Not >that >we'll ever encounter such a case, but making this point helps >pedagogically >with getting across the notion of transaction equivalence. What counts >are >the consumed inputs and the destination and amounts of the outputs." You seem to not be familiar with how multisig transactions on Bitcoin work - 99.9% of the time theyre hidden behind p2sh and there is no way to know what keys are involved. Equally, multisig is just one of many complex scripts possible. Look into what a segwit transaction hashes - that's a better notion of non-malleable transaction. But even then lots of transactions are malleable, and its easy to trigger those cases intentionally by third parties. Most likely any Bitcoin United scheme would quickly diverge and fail; much simpler and more predictable to achieve convincing consensus, e.g. via proof of stake voting, or Adam Bank's extension blocks suggestions. (or of course, not trying to force controversial forks in the first place) -BEGIN PGP SIGNATURE- iQE9BAEBCgAnIBxQZXRlciBUb2RkIDxwZXRlQHBldGVydG9kZC5vcmc+BQJWhD9N AAoJEMCF8hzn9Lncz4MH/0JPGVc2JLtD5q0I2w0vqmBqsoSzSueCtnKa2K1Ea10g w9I4uhK7+cgfCLbofJznVHMChXu0uCxtWwqSj++uJx238TEupcu951gUhFfuPOeH Egye8jmDkDFiB1P40kUSVk9N64Zt3kWLk4xSsfjawVHz/WWpM24Fn8k/bmI7JiLl nmVwoBdRsTKffM/1dr8ix4U8YPSmJ7W+jAByNHUpSgc1R73YylqNT95pF8QD35df dQwSK9DIc+2N4CKnp22xLvYeCivFjeS2Fm4kbcKQwMjcqlJ1mWghP/c8q/lzhaGN Ac15/pgeHp8dPP8c81zkN9ps14rrnXoHnrzjiY+TwKY= =FfK1 -END PGP SIGNATURE- ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] How to preserve the value of coins after a fork.
On Wed, Dec 30, 2015 at 3:16 PM, Peter Todd wrote: > Note how transaction malleability can quickly sabotage naive notions of > this idea. > Bitcoin-United relies on a notion of transaction equivalence that doesn't involve the transaction hash at all, so it should be immune to malleability issues and compatible with segwit. >From the post, two transactions are equal if they "consume the same inputs and result in the same outputs, not counting the miner fee. Simple pay-to-pubkey-hash and pay-to-script-hash transactions are straightforward. Multikey transactions are evaluated for equivalency by their inputs and outputs, so it is allowable for a 2-out-of-3 payment to be signed by one set of two keys on Dum and another set of two keys on Dee, as long as the transaction consumes the same coins and produces the same outputs. Not that we'll ever encounter such a case, but making this point helps pedagogically with getting across the notion of transaction equivalence. What counts are the consumed inputs and the destination and amounts of the outputs." But you're right, if a naive implementation were to just use the transaction hash, the result would be a mess. - egs ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] How to preserve the value of coins after a fork.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Note how transaction malleability can quickly sabotage naive notions of this idea. Equally, if this looks like it might ever be implemented, rather than using a hard fork, using a forced soft-fork to deploy changes becomes attractive. On 30 December 2015 12:08:36 GMT-08:00, "Emin Gün Sirer via bitcoin-dev" wrote: >Ittay Eyal and I just put together a writeup that we're informally >calling >Bitcoin-United for preserving the value of coins following a permanent >fork: > > >http://hackingdistributed.com/2015/12/30/technique-to-unite-bitcoin-factions/ > >Half of the core idea is to eliminate double-spends (where someone >spends a >UTXO on chain A and the same UTXO on chain B, at separate merchants) by >placing transactions from A on chain B, and by taking the intersection >of >transactions on chain A and chain B when considering whether a payment >has >been received. > >The other half of the core idea is to enable minting of new coins and >collection of mining fees on both chains, while preserving the 21M >maximum. >This is achieved by creating a one-to-one correspondence between coins >on >one chain with coins on the other. > >Given the level of the audience here, I'm keeping the description quite >terse. Much more detail and discussion is at the link above, as well as >the >assumptions that need to hold for Bitcoin-United. > >The high bit is that, with a few modest assumptions, it is possible to >create a cohesive coin in the aftermath of a fork, even if the core >devs >are split, and even if one of the forks is (in the worst case) >completely >non-cooperative. Bitcoin-United is a trick to create a cohesive coin >even >when there is no consensus at the lowest level. > >Bitcoin-United opens up a lot of new, mostly game-theoretic questions: >what >happens to native clients who prefer A or B? What will happen to the >value >of native-A or native-B coins? And so on. > >We're actively working on these questions and more, but we wanted to >share >the Bitcoin-United idea, mainly to receive feedback, and partly to >provide >some hope about future consensus to the community. It turns out that it >is >possible to craft consensus at the network level even when there isn't >one >at the developer level. > >Happy New Year, and may 2016 be united, >- egs & ittay > > > > >___ >bitcoin-dev mailing list >bitcoin-dev@lists.linuxfoundation.org >https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev - -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -BEGIN PGP SIGNATURE- iQE9BAEBCgAnIBxQZXRlciBUb2RkIDxwZXRlQHBldGVydG9kZC5vcmc+BQJWhDuA AAoJEMCF8hzn9Lncz4MIAIObFNbRRJ5g52H8yprqAjX76Lt7vw+cwCnICNzHra5h iuTWxgbwED5fki2Q96ZzYAyUf7ju7rI45qBl8YuuVUlyxJgE6oV6h2oJoxGQNGz0 WvrOjWMkmARNs0FM4GMsKQWcmIMgZxWnWTMOXv0EDBLySsm8WFRu9H4drGBB+Fmb wFRyi0XVDiXxsVUoNj6pCdcpekdnuq+V87IoweoxigfqgWIM31Vb9QK8Y/7vWO2b 0lu0CvVdqvw5Npx55LWLF1tY8jbw6BYvgXwZGtUazKO+x8i3Qt6+tRm07+UXvkoR 3erxzhnoZa3F66ufz+ImY7l0E/AyRE5ox+1W68hO6sk= =d0+L -END PGP SIGNATURE- ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] How to preserve the value of coins after a fork.
Ittay Eyal and I just put together a writeup that we're informally calling Bitcoin-United for preserving the value of coins following a permanent fork: http://hackingdistributed.com/2015/12/30/technique-to-unite-bitcoin-factions/ Half of the core idea is to eliminate double-spends (where someone spends a UTXO on chain A and the same UTXO on chain B, at separate merchants) by placing transactions from A on chain B, and by taking the intersection of transactions on chain A and chain B when considering whether a payment has been received. The other half of the core idea is to enable minting of new coins and collection of mining fees on both chains, while preserving the 21M maximum. This is achieved by creating a one-to-one correspondence between coins on one chain with coins on the other. Given the level of the audience here, I'm keeping the description quite terse. Much more detail and discussion is at the link above, as well as the assumptions that need to hold for Bitcoin-United. The high bit is that, with a few modest assumptions, it is possible to create a cohesive coin in the aftermath of a fork, even if the core devs are split, and even if one of the forks is (in the worst case) completely non-cooperative. Bitcoin-United is a trick to create a cohesive coin even when there is no consensus at the lowest level. Bitcoin-United opens up a lot of new, mostly game-theoretic questions: what happens to native clients who prefer A or B? What will happen to the value of native-A or native-B coins? And so on. We're actively working on these questions and more, but we wanted to share the Bitcoin-United idea, mainly to receive feedback, and partly to provide some hope about future consensus to the community. It turns out that it is possible to craft consensus at the network level even when there isn't one at the developer level. Happy New Year, and may 2016 be united, - egs & ittay ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Increasing the blocksize as a (generalized) softfork.
joe2015--- via bitcoin-dev [bitcoin-dev@lists.linuxfoundation.org] wrote: > That's the whole point. After a conventional hardfork everyone > needs to upgrade, but there is no way to force users to upgrade. A > user who is simply unaware of the fork, or disagrees with the fork, > uses the old client and the currency splits. > > Under this proposal old clients effectively enter "zombie" mode, > forcing users to upgrade. This is a very complex way to enter zombie mode. A simpler way is to track valid PoW chains by examining only the header, that are rejected for other reasons. Once a chain is seen to be 6 or more blocks ahead of my chain tip, we should enter "zombie mode" and refuse to mine or relay, and alert the operator, because we don't know what we're doing and we're out of date. This way doesn't require any modifications to block structure at all. -- Cheers, Bob McElrath "For every complex problem, there is a solution that is simple, neat, and wrong." -- H. L. Mencken ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] [BIP Draft] Decentralized Improvement Proposals
> The specification itself looks like an inefficient and bloaty reinvention > of > version bits. The actual assignment of version bits isn't clear from the specification. Are you saying that any implementation that wants to propose a change is encouraged to pick a free version bit and use it? Furthermore, my proposal addresses the danger of forward-incompatible changes; a hard-fork can no longer occur as every implementation will agree on the active the set of rules even if it has not implemented them. This seems to be lacking in the version bits proposal. Tomas ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] Generalized soft forks
Please forgive the perhaps pedantic question but in the referred document http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/012073.html It talks about how a soft fork with >50% support will doom the other fork to being orphaned eventually but that hard forks could persist forever. I fail to see why the same logic that one side having the majority will eventually win wouldn't also apply to hard forks. Additionally it seems to me that a notable difference between a generalized soft fork as described and a hard fork majority is in the process by which they force the other fork to be orphaned. In a hard fork an unupgraded node would know you were in a forking situation due to your node getting a lot of blocks from the other fork and having to reject them (because they are invalid) whereas in a generalized soft fork you wouldn't know there was a fork going on so there would be less of an impetus to upgrade. Of course the downside of the hard fork is that the losing side would potentially lose money in the orphaned chain, but presumably this discussion of generalized soft forks is with regards to non-mining nodes so it shouldn't come into consideration. In fact if an non-upgraded miner were to start mining on top of that block which they cannot actually fully validate essentially this condones mining without verification (and trusting that others which have upgraded nodes to have validated the txns for you) as this situation can continue for a prolonged period of time does this not hurt network security ? >> On 2015/12/31, at 1:27, joe2015--- via bitcoin-dev >> wrote: >> >> On 2015-12-30 18:33, Marco Falke wrote: >> This is an interesting approach but I don't see how this is a soft >> fork. (Just because something is not a hard fork, doesn't make it a >> soft fork by definition) >> Softforks don't require any nodes to upgrade. [1] >> Nonetheless, as I understand your approach, it requires nodes to >> upgrade. Otherwise they are missing all transactions but the coinbase >> transactions. Thus, they cannot update their utxoset and are easily >> susceptible to double spends... >> Am I missing something obvious? >> -- Marco >> [1] https://en.bitcoin.it/wiki/Softfork#Implications > > It just depends how you define "softfork". In my original write-up I called > it a "generalized" softfork, Peter suggested a "firm" fork, and there are > some suggestions for other names. Ultimately what you call it is not very > important. > > --joe. > ___ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] [BIP Draft] Decentralized Improvement Proposals
On Wednesday, December 30, 2015 4:35:17 PM Tomas via bitcoin-dev wrote: > In an attempt to reduce developer centralization, and to reduce the risk > of forks introduced by implementation other than bitcoin-core, I have > drafted a BIP to support changes to the protocol from different > implementations. The premises in Motivation are false. BIPs are required to have a reference implementation, but that implementation need not necessarily be for Bitcoin Core specifically. The specification itself looks like an inefficient and bloaty reinvention of version bits. Luke ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] [BIP Draft] Decentralized Improvement Proposals
In an attempt to reduce developer centralization, and to reduce the risk of forks introduced by implementation other than bitcoin-core, I have drafted a BIP to support changes to the protocol from different implementations. The BIP can be found at: https://github.com/tomasvdw/bips/blob/master/decentralized-improvement-proposals.mediawiki I believe this BIP could mitigate the risk of forks, and decentralize the development of the protocol. If you consider the proposal worthy of discussion, please assign a BIP-number. Regards, Tomas van der Wansem ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] An implementation of BIP102 as a softfork.
I guess the same could be said about the softfork flavoured SW
implementation. In any case, the strategy pattern helps with code structure
in situations like this.
2015-12-30 14:29 GMT+01:00 Jonathan Toomim via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org>:
> As a first impression, I think this proposal is intellectually
> interesting, but crufty and hackish and should never actually be deployed.
> Writing code for Bitcoin in a future in which we have deployed a few
> generalized softforks this way sounds terrifying.
>
> Instead of this:
>
> CTransaction GetTransaction(CBlock block, unsigned int index) {
> return block->vtx[index];
> }
>
> We might have this:
>
> CTransaction GetTransaction(CBlock block, unsigned int index) {
> if (!IsBIP102sBlock(block)) {
> return block->vtx[index];
> } else {
> if (!IsOtherGeneralizedSoftforkBlock(block)) {
> // hooray! only one generalized softfork level to deal
> with!
> return
> LookupBlock(GetGSHashFromCoinbase(block->vtx[0].vin[0].scriptSig))->vtx[index];
>} else {
>throw NotImplementedError; // I'm too lazy to write
> pseudocode this complicated just to argue a point
> }
> }
>
> It might be possible to make that a bit simpler with recursion, or by
> doing subsequent generalized softforks in a way that doesn't have
> multi-levels-deep block-within-a-block-within-a-block stuff. Still: ugh.
>
>
>
>
> On Dec 29, 2015, at 9:46 PM, joe2015--- via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> > Below is a proof-of-concept implementation of BIP102 as a softfork:
> >
> > https://github.com/ZoomT/bitcoin/tree/2015_2mb_blocksize
> >
> https://github.com/jgarzik/bitcoin/compare/2015_2mb_blocksize...ZoomT:2015_2mb_blocksize?diff=split&name=2015_2mb_blocksize
> >
> > BIP102 is normally a hardfork. The softfork version (unofficial
> > codename BIP102s) uses the idea described here:
> >
> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/012073.html
> >
> > The basic idea is that post-fork blocks are constructed in such a way
> > they can be mapped to valid blocks under the pre-fork rules. BIP102s
> > is a softfork in the sense that post-fork miners are still creating a
> > valid chain under the old rules, albeit indirectly.
> >
> > From the POV of non-upgraded clients, BIP102s circumvents the
> > block-size limit by moving transaction validation data "outside" of
> > the block. This is a similar trick used by Segregated Witness and
> > Extension Blocks (both softfork proposals).
> >
> > From the POV of upgraded clients, the block layout is unchanged,
> > except:
> > - A larger 2MB block-size limit (=BIP102);
> > - The header Merkle root has a new (backwards compatible)
> > interpretation;
> > - The coinbase encodes the Merkle root of the remaining txs.
> > Aside from this, blocks maintain their original format, i.e. a block
> > header followed by a vector of transactions. This keeps the
> > implementation simple, and is distinct from SW and EB.
> >
> > Since BIP102s is a softfork it means that:
> > - A miner majority (e.g. 75%, 95%) force miner consensus (100%). This
> > is not true for a hardfork.
> > - Fraud risk is significantly reduced (6-conf unlikely depending on
> > activation threshold).
> > This should address some of the concerns with deploying a block-size
> > increase using a hardfork.
> >
> > Notes:
> >
> > - The same basic idea could be adapted to any of the other proposals
> > (BIP101, 2-4-8, BIP202, etc.).
> > - I used Jeff Garzik's BIP102 implementation which is incomplete (?).
> > The activation logic is left unchanged.
> > - I am not a Bitcoin dev so hopefully no embarrassing mistakes in my
> > code :-(
> >
> > --joe
> >
> > ___
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] An implementation of BIP102 as a softfork.
On 2015-12-30 18:33, Marco Falke wrote: This is an interesting approach but I don't see how this is a soft fork. (Just because something is not a hard fork, doesn't make it a soft fork by definition) Softforks don't require any nodes to upgrade. [1] Nonetheless, as I understand your approach, it requires nodes to upgrade. Otherwise they are missing all transactions but the coinbase transactions. Thus, they cannot update their utxoset and are easily susceptible to double spends... Am I missing something obvious? -- Marco [1] https://en.bitcoin.it/wiki/Softfork#Implications It just depends how you define "softfork". In my original write-up I called it a "generalized" softfork, Peter suggested a "firm" fork, and there are some suggestions for other names. Ultimately what you call it is not very important. --joe. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] An implementation of BIP102 as a softfork.
On Dec 30, 2015, at 6:19 AM, Peter Todd wrote: > Your fear is misplaced: it's trivial to avoid recursion with a bit of > planning... That makes some sense. I downgrade my emotions from "a future in which we have deployed a few generalized softforks this way sounds terrifying" to "the idea of a future in which we have deployed at least one generalized softfork this way gives me the heebie jeebies." signature.asc Description: Message signed with OpenPGP using GPGMail ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] An implementation of BIP102 as a softfork.
On Wed, Dec 30, 2015 at 06:19:55AM -0800, Peter Todd via bitcoin-dev wrote: > On Wed, Dec 30, 2015 at 05:29:05AM -0800, Jonathan Toomim via bitcoin-dev > wrote: > > As a first impression, I think this proposal is intellectually interesting, > > but crufty and hackish and should never actually be deployed. Writing code > > for Bitcoin in a future in which we have deployed a few generalized > > softforks this way sounds terrifying. > > > > > It might be possible to make that a bit simpler with recursion, or by doing > > subsequent generalized softforks in a way that doesn't have > > multi-levels-deep block-within-a-block-within-a-block stuff. Still: ugh. > > Your fear is misplaced: it's trivial to avoid recursion with a bit of > planning. > > For instance, if Bitcoin was redesigned to incorporate the forced fork Actually, a better name is probably "forced soft-fork", making this clear we're using the soft-fork mechanism to force everyone to upgrade. -- 'peter'[:-1]@petertodd.org 0831fc2554d9370aeba2701fff09980123d24a615eee7416 signature.asc Description: Digital signature ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] An implementation of BIP102 as a softfork.
On Wed, Dec 30, 2015 at 12:16:22PM +0100, Martijn Meijering via bitcoin-dev wrote: > That looks very interesting. But is effectively blocking old clients from > seeing transactions really safe? After all, such transactions are still > confirmed on the new chain. A person might try to send a similar > transaction several times, perhaps with increasing fees in an attempt to > get it to confirm and end up paying someone several times. It's very dangerous to simply send multiple transactions in such a way that they don't double-spend each other; you have no good way of knowing for sure that you're seeing the longest block chain with software alone. Competently designed software with fee-bumping wouldn't allow that mistake to be made; the UX should make it clear that txs sent are still pending until confirmed or clearly double-spent. > Maybe we could require the tx version number to be increased as well so > transactions sent from old clients would never confirm? Perhaps your code > already includes this idea, I need to look at it more closely. That can mess up pre-signed transations, e.g. refunds. -- 'peter'[:-1]@petertodd.org 0831fc2554d9370aeba2701fff09980123d24a615eee7416 signature.asc Description: Digital signature ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] An implementation of BIP102 as a softfork.
On Wed, Dec 30, 2015 at 05:29:05AM -0800, Jonathan Toomim via bitcoin-dev wrote: > As a first impression, I think this proposal is intellectually interesting, > but crufty and hackish and should never actually be deployed. Writing code > for Bitcoin in a future in which we have deployed a few generalized softforks > this way sounds terrifying. > It might be possible to make that a bit simpler with recursion, or by doing > subsequent generalized softforks in a way that doesn't have multi-levels-deep > block-within-a-block-within-a-block stuff. Still: ugh. Your fear is misplaced: it's trivial to avoid recursion with a bit of planning. For instance, if Bitcoin was redesigned to incorporate the forced fork concept, instead of block headers committing to just a merkle root, they could instead commit to H(version + digest) For version == 0, digest would be a merkle root of all transactions. If the version was > 0, any digest would be allowed and the block would be interpreted as a NOP with no effect on the UTXO set. In the event of a major change - e.g. what would otherwise be a hard-forking change to the way the merkle root was calculated - a soft-fork would change the block validity rules to make version == 0 invalid, and verison == 1 blocks would interpret the digest according to the new merkle root rules. Again, version > 1 blocks would be treated as NOPs. A good exercise is to apply the above to the existing Bitcoin ecosystem as a soft-fork - it certainely can be done, and done right is technically very simple. Regardless of how it's done - existing Bitcoin compatible or clean sheet redesign - you get the significant safety advantages soft-forks have over hard-forks in nearly all situations where you'd have to do a hard-fork. OTOH, it's kinda scary how this institutionalizes what could be seen as 51% attacks, possibly giving miners significantly more control over the system politically. I'm not sure I agree with that viewpoint - miners can do this anyway - but that has made people shy away from promoting this idea in the past. (previously it's been often referred to as an "evil" soft-fork) -- 'peter'[:-1]@petertodd.org 0831fc2554d9370aeba2701fff09980123d24a615eee7416 signature.asc Description: Digital signature ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] An implementation of BIP102 as a softfork.
That looks very interesting. But is effectively blocking old clients from seeing transactions really safe? After all, such transactions are still confirmed on the new chain. A person might try to send a similar transaction several times, perhaps with increasing fees in an attempt to get it to confirm and end up paying someone several times. Maybe we could require the tx version number to be increased as well so transactions sent from old clients would never confirm? Perhaps your code already includes this idea, I need to look at it more closely. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] An implementation of BIP102 as a softfork.
This is an interesting approach but I don't see how this is a soft fork. (Just because something is not a hard fork, doesn't make it a soft fork by definition) Softforks don't require any nodes to upgrade. [1] Nonetheless, as I understand your approach, it requires nodes to upgrade. Otherwise they are missing all transactions but the coinbase transactions. Thus, they cannot update their utxoset and are easily susceptible to double spends... Am I missing something obvious? -- Marco [1] https://en.bitcoin.it/wiki/Softfork#Implications ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] An implementation of BIP102 as a softfork.
As a first impression, I think this proposal is intellectually interesting, but
crufty and hackish and should never actually be deployed. Writing code for
Bitcoin in a future in which we have deployed a few generalized softforks this
way sounds terrifying.
Instead of this:
CTransaction GetTransaction(CBlock block, unsigned int index) {
return block->vtx[index];
}
We might have this:
CTransaction GetTransaction(CBlock block, unsigned int index) {
if (!IsBIP102sBlock(block)) {
return block->vtx[index];
} else {
if (!IsOtherGeneralizedSoftforkBlock(block)) {
// hooray! only one generalized softfork level to deal with!
return
LookupBlock(GetGSHashFromCoinbase(block->vtx[0].vin[0].scriptSig))->vtx[index];
} else {
throw NotImplementedError; // I'm too lazy to write pseudocode
this complicated just to argue a point
}
}
It might be possible to make that a bit simpler with recursion, or by doing
subsequent generalized softforks in a way that doesn't have multi-levels-deep
block-within-a-block-within-a-block stuff. Still: ugh.
On Dec 29, 2015, at 9:46 PM, joe2015--- via bitcoin-dev
wrote:
> Below is a proof-of-concept implementation of BIP102 as a softfork:
>
> https://github.com/ZoomT/bitcoin/tree/2015_2mb_blocksize
> https://github.com/jgarzik/bitcoin/compare/2015_2mb_blocksize...ZoomT:2015_2mb_blocksize?diff=split&name=2015_2mb_blocksize
>
> BIP102 is normally a hardfork. The softfork version (unofficial
> codename BIP102s) uses the idea described here:
> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/012073.html
>
> The basic idea is that post-fork blocks are constructed in such a way
> they can be mapped to valid blocks under the pre-fork rules. BIP102s
> is a softfork in the sense that post-fork miners are still creating a
> valid chain under the old rules, albeit indirectly.
>
> From the POV of non-upgraded clients, BIP102s circumvents the
> block-size limit by moving transaction validation data "outside" of
> the block. This is a similar trick used by Segregated Witness and
> Extension Blocks (both softfork proposals).
>
> From the POV of upgraded clients, the block layout is unchanged,
> except:
> - A larger 2MB block-size limit (=BIP102);
> - The header Merkle root has a new (backwards compatible)
> interpretation;
> - The coinbase encodes the Merkle root of the remaining txs.
> Aside from this, blocks maintain their original format, i.e. a block
> header followed by a vector of transactions. This keeps the
> implementation simple, and is distinct from SW and EB.
>
> Since BIP102s is a softfork it means that:
> - A miner majority (e.g. 75%, 95%) force miner consensus (100%). This
> is not true for a hardfork.
> - Fraud risk is significantly reduced (6-conf unlikely depending on
> activation threshold).
> This should address some of the concerns with deploying a block-size
> increase using a hardfork.
>
> Notes:
>
> - The same basic idea could be adapted to any of the other proposals
> (BIP101, 2-4-8, BIP202, etc.).
> - I used Jeff Garzik's BIP102 implementation which is incomplete (?).
> The activation logic is left unchanged.
> - I am not a Bitcoin dev so hopefully no embarrassing mistakes in my
> code :-(
>
> --joe
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
signature.asc
Description: Message signed with OpenPGP using GPGMail
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
