Re: [bitcoin-dev] Capacity increases for the Bitcoin system.

TLDR: 1.7MB effective block size is a better estimate than 1.6MB for p2pkh with segwit. 2MB for 2/2 multisig still seems accurate. Additional post-segwit soft forked script improvements can improve the effective block size for p2pkh txns from 1.7MB to 1.9MB, and for 2/2 multisig from

Re: [bitcoin-dev] Capacity increases for the Bitcoin system.

On Mon, Dec 21, 2015 at 05:21:55AM +, Btc Drak via bitcoin-dev wrote: > On Mon, Dec 21, 2015 at 4:33 AM, Pieter Wuille via bitcoin-dev < > > So I'd like to ask the community that we work towards this plan, as it > > allows to make progress without being forced to make a possibly divisive > >

Re: [bitcoin-dev] Capacity increases for the Bitcoin system.

To clarify, although I have defended the deployment of segwit as a hardfork, I have no strong opinion on whether to do that or do it as a softfork first and then do a hardfork to move things out of the coinbase to a better place. I have a strong opinion against never doing the later hardfork

Re: [bitcoin-dev] Capacity increases for the Bitcoin system.

On Mon, Dec 21, 2015 at 4:33 AM, Pieter Wuille via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > On Tue, Dec 8, 2015 at 6:07 AM, Wladimir J. van der Laan wrote: > > On Mon, Dec 07, 2015 at 10:02:17PM +, Gregory Maxwell via > bitcoin-dev wrote: > >> TL;DR: I propose we work

Re: [bitcoin-dev] Capacity increases for the Bitcoin system.

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 2015/12/20 20:50, Mark Friedenbach via bitcoin-dev wrote: > I am fully in support of the plan laid out in "Capacity increases > for the bitcoin system". > > This plan provides real benefit to the ecosystem in solving a > number of longstanding

Re: [bitcoin-dev] Capacity increases for the Bitcoin system.

I am fully in support of the plan laid out in "Capacity increases for the bitcoin system". This plan provides real benefit to the ecosystem in solving a number of longstanding problems in bitcoin. It improves the scalability of bitcoin considerably. Furthermore it is time that we stop

Re: [bitcoin-dev] Capacity increases for the Bitcoin system.

I think someone, maybe Pieter, commented on this relay issue that it would be likely very transitory, as a lot of stuff would be fairly quickly upgraded in practice from previous deployment experience, and I think anyway there is a huge excess connectivity and capacity in the p2p network vs having

Re: [bitcoin-dev] Capacity increases for the Bitcoin system.

This means that a server supporting SW might only hear of the tx data and not get the signature data for some transactions, depending on how the relay rules worked (e.g. if the SW peers had higher minrelaytxfee settings than the legacy peers). This would complicate fast block relay code like

Re: [bitcoin-dev] Capacity increases for the Bitcoin system.

A segwit supporting server would be required to support relaying segwit transactions, although a non-segwit server could at least inform a wallet of segwit txns observed, even if it doesn't relay all information necessary to validate. Non segwit servers and wallets would continue operations as if

Re: [bitcoin-dev] Capacity increases for the Bitcoin system.

On Fri, Dec 11, 2015 at 11:18 AM, Jorge Timón wrote: > This is basically what I meant by > > struct hashRootStruct > { > uint256 hashMerkleRoot; > uint256 hashWitnessesRoot; > uint256 hashextendedHeader; > } > > but my design doesn't calculate other_root as it appears in your

Re: [bitcoin-dev] Capacity increases for the Bitcoin system.

On Dec 9, 2015 5:40 PM, "Gavin Andresen" wrote: > > On Wed, Dec 9, 2015 at 3:03 AM, Gregory Maxwell via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: >> >> I think it would be logical to do as part of a hardfork that moved >> commitments generally; e.g. a

Re: [bitcoin-dev] Capacity increases for the Bitcoin system.

On Wed, Dec 9, 2015 at 7:54 AM, Jorge Timón wrote: > From this question one could think that when you said "we can do the > cleanup hardfork later" earlier you didn't really meant it. And that > you will oppose to that hardfork later just like you are opposing to > it now. > As

Re: [bitcoin-dev] Capacity increases for the Bitcoin system.

My apologies for the apparent miscommunication earlier. It is of interest to me that the soft-fork be done which is necessary to put a commitment in the most efficient spot possible, in part because that commitment could be used for other data such as the merged mining auxiliary blocks, which are

Re: [bitcoin-dev] Capacity increases for the Bitcoin system.

Fair enough. On Dec 9, 2015 4:03 PM, "Gregory Maxwell" wrote: > On Wed, Dec 9, 2015 at 7:54 AM, Jorge Timón wrote: > > From this question one could think that when you said "we can do the > > cleanup hardfork later" earlier you didn't really meant it. And that >

Re: [bitcoin-dev] Capacity increases for the Bitcoin system.

On Wed, Dec 9, 2015 at 3:03 AM, Gregory Maxwell via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > I think it would be logical to do as part of a hardfork that moved > commitments generally; e.g. a better position for merged mining (such > a hardfork was suggested in 2010 as

Re: [bitcoin-dev] Capacity increases for the Bitcoin system.

On 12/08/2015 10:12 AM, Gavin Andresen via bitcoin-dev wrote: > Why segwitness as a soft fork? Stuffing the segwitness merkle tree in > the coinbase is messy and will just complicate consensus-critical code > (as opposed to making the right side of the merkle tree in > block.version=5 blocks the

Re: [bitcoin-dev] Capacity increases for the Bitcoin system.

If SegWit were implemented as a hardfork, could the entire blockchain be reorganized starting from the Genesis block to free up historical space? ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org

Re: [bitcoin-dev] Capacity increases for the Bitcoin system.

On Mon, Dec 07, 2015 at 10:02:17PM +, Gregory Maxwell via bitcoin-dev wrote: > The Scaling Bitcoin Workshop in HK is just wrapping up. Many fascinating > proposals were presented. I think this would be a good time to share my > view of the near term arc for capacity increases in the Bitcoin

Re: [bitcoin-dev] Capacity increases for the Bitcoin system.

On Dec 8, 2015 7:08 PM, "Wladimir J. van der Laan via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org> wrote: > - Gregory linked to an implementation but as he mentions it is not completely > finished yet. ETA for a Segwit testnet is later this month, then you can test as well.

Re: [bitcoin-dev] Capacity increases for the Bitcoin system.

Thanks for laying out a road-map, Greg. I'll need to think about it some more, but just a couple of initial reactions: Why segwitness as a soft fork? Stuffing the segwitness merkle tree in the coinbase is messy and will just complicate consensus-critical code (as opposed to making the right side

Re: [bitcoin-dev] Capacity increases for the Bitcoin system.

On 12/08/2015 09:12 AM, Gavin Andresen via bitcoin-dev wrote: > Stuffing the segwitness merkle tree in the coinbase If such a change is going to be deployed via a soft fork instead of a hard fork, then the coinbase is the worst place to put the segwitness merkle root. Instead, put it in the

Re: [bitcoin-dev] Capacity increases for the Bitcoin system.

On 12/08/2015 11:41 AM, Mark Friedenbach wrote: > A far better place than the generation transaction (which I assume means > coinbase transaction?) is the last transaction in the block. That allows > you to save, on average, half of the hashes in the Merkle tree. I don't care what color that

Re: [bitcoin-dev] Capacity increases for the Bitcoin system.

On Tue, Dec 8, 2015 at 5:41 PM, Mark Friedenbach via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > A far better place than the generation transaction (which I assume means > coinbase transaction?) is the last transaction in the block. That allows > you to save, on average, half of

Re: [bitcoin-dev] Capacity increases for the Bitcoin system.

On Dec 9, 2015, at 8:09 AM, Gregory Maxwell wrote: > On Tue, Dec 8, 2015 at 11:48 PM, Jonathan Toomim wrote: > > By contrast it does not reduce the safety factor for the UTXO set at > all; which most hold as a much greater concern in general; I don't agree

Re: [bitcoin-dev] Capacity increases for the Bitcoin system.

On Wed, Dec 9, 2015 at 7:29 AM, Gregory Maxwell via bitcoin-dev wrote: > What was being discussed was the location of the witness commitment; > which is consensus critical regardless of where it is placed. Should > it be placed in an available location which

Re: [bitcoin-dev] Capacity increases for the Bitcoin system.

On Dec 8, 2015, at 6:02 AM, Gregory Maxwell via bitcoin-dev wrote: > The particular proposal amounts to a 4MB blocksize increase at worst. I understood that SegWit would allow about 1.75 MB of data in the average case while also allowing up to 4 MB of

Re: [bitcoin-dev] Capacity increases for the Bitcoin system.

On Tue, Dec 8, 2015 at 11:48 PM, Jonathan Toomim wrote: > I understood that SegWit would allow about 1.75 MB of data in the average > case while also allowing up to 4 MB of data in the worst case. This means > that the mining and block distribution network would need a larger safety

Re: [bitcoin-dev] Capacity increases for the Bitcoin system.

On Wed, Dec 9, 2015 at 12:59 AM, Gregory Maxwell via bitcoin-dev wrote: > On Tue, Dec 8, 2015 at 3:12 PM, Gavin Andresen via bitcoin-dev > wrote: > We already have consensus critical enforcement there, the height, >

Re: [bitcoin-dev] Capacity increases for the Bitcoin system.

On Dec 9, 2015, at 7:50 AM, Jorge Timón wrote: > I don't undesrtand. SPV nodes won't think they are validating transactions > with the new version unless they adapt to the new format. They will be simply > unable to receive payments using the new format if it is a softfork

Re: [bitcoin-dev] Capacity increases for the Bitcoin system.

On Wed, Dec 9, 2015 at 1:58 AM, Jorge Timón wrote: > struct hashRootStruct > { > uint256 hashMerkleRoot; > uint256 hashWitnessesRoot; > int32_t nHeight; > } Or better, for forward compatibility (we may want to include more things apart from nHeight and hashWitnessesRoot in the

Re: [bitcoin-dev] Capacity increases for the Bitcoin system.

Agree. This data does not belong in the coinbase. That space is for miners to use, not devs. I also think that a hard fork is better for SegWit, as it reduces the size of fraud proofs considerably, makes the whole design more elegant and less kludgey, and is safer for clients who do not

Re: [bitcoin-dev] Capacity increases for the Bitcoin system.

On Dec 9, 2015, at 7:48 AM, Luke Dashjr wrote: > How about we pursue the SegWit softfork, and at the same time* work on a > hardfork which will simplify the proofs and reduce the kludgeyness of merge- > mining in general? Then, if the hardfork is ready before the softfork, they

Re: [bitcoin-dev] Capacity increases for the Bitcoin system.

On Tue, Dec 8, 2015 at 3:12 PM, Gavin Andresen via bitcoin-dev wrote: > Why segwitness as a soft fork? Stuffing the segwitness merkle tree in the > coinbase is messy and will just complicate consensus-critical code (as > opposed to making the right side of

Re: [bitcoin-dev] Capacity increases for the Bitcoin system.

On Tuesday, December 08, 2015 11:40:42 PM Jonathan Toomim via bitcoin-dev wrote: > Agree. This data does not belong in the coinbase. That space is for miners > to use, not devs. This has never been guaranteed, nor are softforks a "dev action" in the first place. > I also think that a hard fork

Re: [bitcoin-dev] Capacity increases for the Bitcoin system.

On Wed, Dec 9, 2015 at 1:09 AM, Gavin Andresen wrote: > Create a 1-megabyte transaction, with all of it's inputs spending > segwitness-spending SIGHASH_ALL inputs. > > Because the segwitness inputs are smaller in the block, you can fit more of > them into 1 megabyte. Each

Re: [bitcoin-dev] Capacity increases for the Bitcoin system.

I see, thanks for clearing that up, I misread what Gavin stated. On Wed, Dec 9, 2015 at 12:29 AM, Gregory Maxwell wrote: > On Wed, Dec 9, 2015 at 4:44 AM, Ryan Butler wrote: > >>I agree, but nothing I have advocated creates significant technical > >>debt.

Re: [bitcoin-dev] Capacity increases for the Bitcoin system.

Greg, if you have actual data showing that putting the commitment in the last transaction would be disruptive, and how disruptive, that would be appreciated. Of the mining hardware I have looked at, none of it cared at all what transactions other than the coinbase are. You need to provide a path

Re: [bitcoin-dev] Capacity increases for the Bitcoin system.

On Wed, Dec 9, 2015 at 4:44 AM, Ryan Butler wrote: >>I agree, but nothing I have advocated creates significant technical >>debt. It is also a bad engineering practice to combine functional >>changes (especially ones with poorly understood system wide >>consequences and low

Re: [bitcoin-dev] Capacity increases for the Bitcoin system.

On Wed, Dec 09, 2015 at 01:31:51AM +, Gregory Maxwell via bitcoin-dev wrote: > On Wed, Dec 9, 2015 at 1:09 AM, Gavin Andresen > wrote: > > Create a 1-megabyte transaction, with all of it's inputs spending > > segwitness-spending SIGHASH_ALL inputs. > > Because the

Re: [bitcoin-dev] Capacity increases for the Bitcoin system.

On Tue, Dec 08, 2015 at 05:21:18AM +, Gregory Maxwell via bitcoin-dev wrote: > On Tue, Dec 8, 2015 at 4:58 AM, Anthony Towns via bitcoin-dev > wrote: > > Having a cost function rather than separate limits does make it easier to > > build blocks

[bitcoin-dev] Capacity increases for the Bitcoin system.

The Scaling Bitcoin Workshop in HK is just wrapping up. Many fascinating proposals were presented. I think this would be a good time to share my view of the near term arc for capacity increases in the Bitcoin system. I believe we’re in a fantastic place right now and that the community is ready to

Re: [bitcoin-dev] Capacity increases for the Bitcoin system.

On Mon, Dec 7, 2015 at 4:02 PM, Gregory Maxwell wrote: > The Scaling Bitcoin Workshop in HK is just wrapping up. Many fascinating > proposals were presented. I think this would be a good time to share my > view of the near term arc for capacity increases in the Bitcoin system. I > believe we’re in