Re: [bitcoin-dev] Block size: It's economics & user preparation & moral hazard
On Thu, Dec 17, 2015 at 7:44 PM, Peter Toddwrote: > If Bitcoin remains decentralized, miners have veto power over any > blocksize increases. You can always soft-fork in a blocksize reduction > in a decentralized blockchain that actually works. > The actual users of the system have significant power, if they (could) choose to use it. There are "chicken" effects though. They can impose costs on the other participants but using those options harms themselves. If the cost of inaction is greater than the costs of action, then the chicken effects go away. In the extreme, they could move away from decentralisation and the concept of miners and have a centralised checkpointing system. This would be a bankrupting cost to miners but at the cost to the users of the decentralised nature of the system. At a lower extreme, they could change the mining hash function. This would devalue all of the miner's investments. A whole new program of ASIC investments would have to happen and the new miners would be significantly different. It would also establish that merchants and users are not to be ignored. On the other hand, bankrupting miners would make it harder to convince new miners to make the actual investments in ASICs required to establish security. As a gesture, if merchants and exchanges wanted to get their "seat" at the table, they could create a representative group that insists on a trivial soft fork. For example, they could say that they will not accept any block from block N to block N + 5000 that doesn't have a specific bit set in the version. Miners have an advantage where they can say that they have the majority of the hashing power. As part of the public action problem that merchants face, there is no equivalent metric. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Segregated Witness in the context of Scaling Bitcoin
Anthony, On Thu, Dec 17, 2015 at 6:55 PM, Anthony Towns via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > On Thu, Dec 17, 2015 at 04:51:19PM +0100, sickpig--- via bitcoin-dev wrote: > > On Thu, Dec 17, 2015 at 2:09 PM, Jorge Timón wrote: > > > Unless I'm missing something, 2 mb x4 = 8mb, so bip102 + SW is already > > > equivalent to the 2-4-8 "compromise" proposal [...] > > isn't SegWit gain ~75%? hence 2mb x 1.75 = 3.5. > > Segwit as proposed gives a 75% *discount* to witness data with the > same limit, so at a 1MB limit, that might give you (eg) 2.05MB made up > of 650kB of base block data plus 1.4MB of witness data; where 650kB + > 1.4MB/4 = 1MB at the 1MB limit; or 4.1MB made up of 1.3MB of base plus > 2.8MB of witness, for 1.3MB+2.8MB/4 = 2MB at a 2MB limit. > > > 4x is theoric gain you get in case of 2-2 multisig txs. > > With segregated witness, 2-2 multisig transactions are made up of 94B > of base data, plus about 214B of witness data; discounting the witness > data by 75% gives 94+214/4=148 bytes. That compares to about 301B for > a 2-2 multisig transaction with P2SH rather than segwit, and 301/148 > gives about a 2.03x gain, not a 4x gain. A 2.05x gain is what I assumed > to get the numbers above. > > You get further improvements with, eg, 3-of-3 multisig, but to get > the full, theoretical 4x gain you'd need a fairly degenerate looking > transaction. > > Pay to public key hash with segwit lets you move about half the > transaction data into the witness, giving about a 1.6x improvement by > my count (eg 1.6MB = 800kB of base data plus 800kB of witness data, > where 800kB+800kB/4=1MB), so I think a gain of between 1.6 and 2.0 is > a reasonable expectation to have for the proposed segwit scheme overall. > > many thanks for the explanation. so it should be fair to say that BIP 102 + SW would bring a gain between 2*1.6 and 2*2. Just for the sake of simplicity if we take the middle of the interval we could say that BIP102 + SW will bring us a max block (virtual) size equal to 1MB * 2 * 1.8 = 3.6 Is it right? ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] The increase of max block size should be determined by block height instead of block time
Well, if it's not going to be height, I think median time of the previous block is better than the time of the current one, and would also solve Chun Wang's concerns. But as said I prefer to use heights that correspond to diff recalculation (because that's the window that bip9 will use for the later 95% confirmation anyway). On Dec 18, 2015 9:02 PM, "Jeff Garzik"wrote: > From a code standpoint, based off height is easy. > > My first internal version triggered on block 406,800 (~May 5), and each > block increased by 20 bytes thereafter. > > It was changed to time, because time was the standard used in years past > for other changes; MTP flag day is more stable than block height. > > It is preferred to have a single flag trigger (height or time), rather > than the more complex trigger-on-time, increment-on-height, but any > combination of those will work. > > Easy to change code back to height-based... > > > > On Fri, Dec 18, 2015 at 2:52 PM, Jorge Timón < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> I agree that nHeight is the simplest option and is my preference. >> Another option is to use the median time from the previous block (thus >> you know whether or not the next block should start the miner confirmation >> or not). In fact, if we're going to use bip9 for 95% miner upgrade >> confirmation, it would be nice to always pick a difficulty retarget block >> (ie block.nHeight % DifficultyAdjustmentInterval == 0). >> Actually I would always have an initial height in bip9, for softforks too. >> I would also use the sign bit as the "hardfork bit" that gets activated >> for the next diff interval after 95% is reached and a hardfork becomes >> active (that way even SPV nodes will notice when a softfork or hardfork >> happens and also be able to tell which one is it). >> I should update bip99 with all this. And if the 2 mb bump is >> uncontroversial, maybe I can add that to the timewarp fix and th recovery >> of the other 2 bits in block.nVersion (given that bip102 doesn't seem to >> follow bip99's recommendations and doesn't want to give 6 full months as >> the pre activation grace period). >> On Dec 18, 2015 8:17 PM, "Chun Wang via bitcoin-dev" < >> bitcoin-dev@lists.linuxfoundation.org> wrote: >> >>> In many BIPs we have seen, include the latest BIP202, it is the block >>> time that determine the max block size. From from pool's point of >>> view, it cannot issue a job with a fixed ntime due to the existence of >>> ntime roll. It is hard to issue a job with the max block size unknown. >>> For developers, it is also easier to implement if max block size is a >>> function of block height instead of time. Block height is also much >>> more simple and elegant than time. >>> ___ >>> 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] The increase of max block size should be determined by block height instead of block time
I believe the attacks are the same for height or median time of the prev block are equal, only the time of the current block has more edge cases. On Dec 18, 2015 9:15 PM, "Jeff Garzik"wrote: > My preference is height activation + one step per block (i.e. also > height). Height seems KISS. > > AFAICT most of the attacks would occur around the already-heavily-watched > flag day activation event, in a height based environment, a useful > attribute. > > However I would like to hear from others about possible attacks with the > various approaches, before diverging from the default community approach of > switch-based-on-time. > > > > > > > On Fri, Dec 18, 2015 at 3:10 PM, Jorge Timón wrote: > >> Well, if it's not going to be height, I think median time of the previous >> block is better than the time of the current one, and would also solve Chun >> Wang's concerns. >> But as said I prefer to use heights that correspond to diff recalculation >> (because that's the window that bip9 will use for the later 95% >> confirmation anyway). >> On Dec 18, 2015 9:02 PM, "Jeff Garzik" wrote: >> >>> From a code standpoint, based off height is easy. >>> >>> My first internal version triggered on block 406,800 (~May 5), and each >>> block increased by 20 bytes thereafter. >>> >>> It was changed to time, because time was the standard used in years past >>> for other changes; MTP flag day is more stable than block height. >>> >>> It is preferred to have a single flag trigger (height or time), rather >>> than the more complex trigger-on-time, increment-on-height, but any >>> combination of those will work. >>> >>> Easy to change code back to height-based... >>> >>> >>> >>> On Fri, Dec 18, 2015 at 2:52 PM, Jorge Timón < >>> bitcoin-dev@lists.linuxfoundation.org> wrote: >>> I agree that nHeight is the simplest option and is my preference. Another option is to use the median time from the previous block (thus you know whether or not the next block should start the miner confirmation or not). In fact, if we're going to use bip9 for 95% miner upgrade confirmation, it would be nice to always pick a difficulty retarget block (ie block.nHeight % DifficultyAdjustmentInterval == 0). Actually I would always have an initial height in bip9, for softforks too. I would also use the sign bit as the "hardfork bit" that gets activated for the next diff interval after 95% is reached and a hardfork becomes active (that way even SPV nodes will notice when a softfork or hardfork happens and also be able to tell which one is it). I should update bip99 with all this. And if the 2 mb bump is uncontroversial, maybe I can add that to the timewarp fix and th recovery of the other 2 bits in block.nVersion (given that bip102 doesn't seem to follow bip99's recommendations and doesn't want to give 6 full months as the pre activation grace period). On Dec 18, 2015 8:17 PM, "Chun Wang via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org> wrote: > In many BIPs we have seen, include the latest BIP202, it is the block > time that determine the max block size. From from pool's point of > view, it cannot issue a job with a fixed ntime due to the existence of > ntime roll. It is hard to issue a job with the max block size unknown. > For developers, it is also easier to implement if max block size is a > function of block height instead of time. Block height is also much > more simple and elegant than time. > ___ > 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
[bitcoin-dev] The increase of max block size should be determined by block height instead of block time
In many BIPs we have seen, include the latest BIP202, it is the block time that determine the max block size. From from pool's point of view, it cannot issue a job with a fixed ntime due to the existence of ntime roll. It is hard to issue a job with the max block size unknown. For developers, it is also easier to implement if max block size is a function of block height instead of time. Block height is also much more simple and elegant than time. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] The increase of max block size should be determined by block height instead of block time
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 18 December 2015 11:52:19 GMT-08:00, "Jorge Timón via bitcoin-dev"wrote: >I agree that nHeight is the simplest option and is my preference. >Another option is to use the median time from the previous block FWIW all these median time based schemes should be using median time past: the point is to use a time that the block creator has no direct control of, while still tying the rule to wall clock time for planning purposes. -BEGIN PGP SIGNATURE- iQE9BAEBCgAnIBxQZXRlciBUb2RkIDxwZXRlQHBldGVydG9kZC5vcmc+BQJWdG/r AAoJEMCF8hzn9Lncz4MH/iYJv6aB9rvfvy1KuSSHAQDQ++6j7Flmk2n8f/S4jt4q 92MZnKDw09HxUJiWvwREi81wHpq4JedgK1Z/+8m3wlK+jaIyWZ7Su+Jm+EqsoOSJ Sx6oisbyFlhVEUAdaG/XOX/K0mqh01NSvGGpoQjHAYzcG3pI03OC4G7Qg4WGeZLx O0yb387DmK/of52JGJcei3TUx0w8Up/GdXDqerLxioH7fhGhtGCj0vyD4LugnNLQ hka5g+hri27YltfaRxncNQ0nZT4rAfgRgRH1Qi3kHnc6ZgRcRjjb36TyrWjZ34eb 9+YDAirFwu8HGmi7lfxh9DDtVjPZCwKal7/rNeRI744= =7f+W -END PGP SIGNATURE- ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Block size: It's economics & user preparation & moral hazard
On Fri, Dec 18, 2015 at 2:56 AM, Pieter Wuillewrote: > On Fri, Dec 18, 2015 at 6:11 AM, Jeff Garzik wrote: > >> You present this as if the Bitcoin Core development team is in charge > >> of deciding the network consensus rules, and is responsible for making > >> changes to it in order to satisfy economic demand. If that is the > >> case, Bitcoin has failed, in my opinion. > > > > Diverging from the satoshi block size change plan[1] and current > economics > > would seem to require a high level of months-ahead communication to > users. > > I don't see any plan, but will you say the same thing when the subsidy > Yes, I forgot the link: [1] https://bitcointalk.org/index.php?topic=1347.msg15366#msg15366 > dwindles, and mining income seems to become uncertain? It will equally > be an economic change, which equally well will have been predictable, > and it will equally well be treatable with a hardfork to increase the > subsidy. > That is a red herring. Nobody I know has proposed this, and I am opposed to changing that fundamental. It is well known that the 1M limit was never intended to stay, unlike 21M coin limit etc. 1M was set high in the beginning because it is a DoS engineering limit, not an [accidental] economic policy tool. > But I am not against a block size increase hard fork. My talk on > segregated witness even included proposed pursuing a hard fork at a > slightly later stage. > Great! > But what you're arguing for is that - despite being completely > expected - blocks grew fuller, and people didn't adapt to block size > pressure and a fee market, so the Core committee now needs to kick the > can down the road, because we can't accept the risk of economic > change. That sounds very much like a bailout to me. > I am arguing for continuing what we know works. We are 100% certain blocks-not-full-on-avg works, where a "buffer" of space exists between avg block size and hard limit. Any other avenue is by definition speculation and risk. You _think_ you know what a healthy fee market _should_ be. Massive damage occurs to bitcoin if you are wrong - and I listed several vis expectation, there is clear consensus and expectation that block size would increase, from 2010 onward. It was always a question of _when_ not if. Sticking with 1M presents clear risk of (a) economic fracture and (b) community fracture. It quite clearly risks massive change to an unknown system at an unknown, unpredictable date in the future. BIP 102 presents an expected upgrade at a predictable date in the future. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] The increase of max block size should be determined by block height instead of block time
On Dec 18, 2015 9:43 PM, "Peter Todd"wrote: > FWIW all these median time based schemes should be using median time past: the point is to use a time that the block creator has no direct control of, while still tying the rule to wall clock time for planning purposes. Well, if after the "planned clock time" you need to wait for the next diff retarget and then wait for 95% (bip9) I think the value of being able to use "human friendly clock time" is very dubious (specially since median time is different from real-world time anyway). But yeah, not giving the creator of the current block direct control over whether its block starts the activation process or not is achieved with median time of the previous block just as well as nHeight does. So even if I disagree with the value that median time brings over the simpler height approach, let's please decide on one and always use that for both hardforks and softforks as part of bip9 (which we would need to modify). An initial time threshold is not necessary for uncontroversial softforks, but it doesn't hurt (you can always set it in the past if you want to not use it) and in fact it simplifies bip9's implementation. Let's please decide once and for all, update bip9 and bip99 and stop doing something different on every hardfork patch we write. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Segregated Witness in the context of Scaling Bitcoin
Not entirely correct, no. Edge cases also matter. Segwit is described as 4MB because that is the largest possible combined block size that can be constructed. BIP 102 + segwit would allow a maximum relay of 8MB. So you have to be confident that an 8MB relay size would be acceptable, even if a block full of actual transactions would be closer to 3.5MB. On Fri, Dec 18, 2015 at 6:01 PM, sickpig--- via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Anthony, > > > On Thu, Dec 17, 2015 at 6:55 PM, Anthony Towns via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> On Thu, Dec 17, 2015 at 04:51:19PM +0100, sickpig--- via bitcoin-dev >> wrote: >> > On Thu, Dec 17, 2015 at 2:09 PM, Jorge Timón wrote: >> > > Unless I'm missing something, 2 mb x4 = 8mb, so bip102 + SW is already >> > > equivalent to the 2-4-8 "compromise" proposal [...] >> > isn't SegWit gain ~75%? hence 2mb x 1.75 = 3.5. >> >> Segwit as proposed gives a 75% *discount* to witness data with the >> same limit, so at a 1MB limit, that might give you (eg) 2.05MB made up >> of 650kB of base block data plus 1.4MB of witness data; where 650kB + >> 1.4MB/4 = 1MB at the 1MB limit; or 4.1MB made up of 1.3MB of base plus >> 2.8MB of witness, for 1.3MB+2.8MB/4 = 2MB at a 2MB limit. >> >> > 4x is theoric gain you get in case of 2-2 multisig txs. >> >> With segregated witness, 2-2 multisig transactions are made up of 94B >> of base data, plus about 214B of witness data; discounting the witness >> data by 75% gives 94+214/4=148 bytes. That compares to about 301B for >> a 2-2 multisig transaction with P2SH rather than segwit, and 301/148 >> gives about a 2.03x gain, not a 4x gain. A 2.05x gain is what I assumed >> to get the numbers above. >> >> You get further improvements with, eg, 3-of-3 multisig, but to get >> the full, theoretical 4x gain you'd need a fairly degenerate looking >> transaction. >> >> Pay to public key hash with segwit lets you move about half the >> transaction data into the witness, giving about a 1.6x improvement by >> my count (eg 1.6MB = 800kB of base data plus 800kB of witness data, >> where 800kB+800kB/4=1MB), so I think a gain of between 1.6 and 2.0 is >> a reasonable expectation to have for the proposed segwit scheme overall. >> >> > many thanks for the explanation. > > so it should be fair to say that BIP 102 + SW would bring a gain between > 2*1.6 and 2*2. > > Just for the sake of simplicity if we take the middle of the interval we > could say > that BIP102 + SW will bring us a max block (virtual) size equal to 1MB * 2 > * 1.8 = 3.6 > > Is it right? > > > > > ___ > 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