[bitcoin-dev] Can kick

I am leaning towards supporting a can kick proposal. Features I think are desirable for this can kick: 0. Block size limit around 2 to 4 MB. Maybe 3 MB? Based on my testnet data, I think 3 MB should be pretty safe. 1. Hard fork with a consensus mechanisms similar to BIP101 2. Approximately 1 or

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] Scaling by Partitioning

Thanks for your response and links. I think the difference is that those proposals all shard the mining work, whereas what I wrote in my post shards the coin itself. In other words different parts of the coin space are forever segregated, never ending up in the same block. It's a big difference

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] BIP 9 style version bits for txns

I proposed in my Wildcard Inputs BIP that the version field be split in two. The first 4 bytes are version number (which in practice is being used for script version), and the second 4 bits are used for transaction type. I don't think the BIP9 mechanism really applies to transactions. A block is

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] Scaling by Partitioning

Payment recipients would need to operate a daemon for each chain, thus guaranteeing no scaling advantage. (There are other issues, but I believe that to be enough of a show stopper not to continue). On 12/08/2015 08:27 AM, Akiva Lichtner via bitcoin-dev wrote: > Hello, > > I am seeking some

Re: [bitcoin-dev] BIP 9 style version bits for txns

I suppose whether the wallet devs want to implement the soft fork or not is irrelevant. They only need to indicate if they are ready i.e. they've tested the new soft fork, hard fork or feature and validated that it doesn't break their nodes or wallet software. On Dec 9, 2015 6:40 AM, "Chris

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] Scaling by Partitioning

If the system is modified to scale up that means the number of transactions is going up. That means the number of miners can also go up, and so will the portion of malicious nodes. At least this seems reasonable. The problem with partitions is that an attacker can focus on one partition. However

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] BIP 9 style version bits for txns

A wallet doesn't receive transactions from other wallets. That is what a node does. Wallets just make transactions and then sends them to the nodes. Nodes then send them to other nodes. In the early days of bitcoin, all wallets were nodes, but now a lot of wallets are just wallets with out any

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] Scaling by Partitioning

It's true that miners would have to be prepared to work on any partition. I don't see where the number affects defeating double spending, what matters is the nonce in the block that keeps the next successful miner random. I expect that the number of miners would be ten times larger as well, so an

Re: [bitcoin-dev] Scaling by Partitioning

If partition is selected from a random key (the hash of the output for example) then payment recipients would need to operate a full node on each of the chains. What's the point of partitioning if virtually everybody needs to operate each partition? The mining aspect has it's own set of issues,