ZoomT



Offline



Activity: 15

Merit: 0







NewbieActivity: 15Merit: 0 Increasing the blocksize as a (generalized) softfork. December 20, 2015, 11:12:48 AM #1 Introduction



It is generally assumed that increasing the blocksize limit requires a

hardfork. Instead we show that a increasing the limit can be achieved using a

"generalized" softfork. Like standard softforks, generalized softforks need a

mere miner majority (>50% hashpower) rather than global consensus.



Standard Softforks



After a softfork two potential chains exist:



* The new chain B3,B4,B5,... valid under the new rules and old rules.

* The old chain B3',B4',B5',... valid under the old rules only.



E.g.



Code: +-- B3 --- B4 --- B5

|

... -- B1 -- B2 --+

|

+-- B3' -- B4' -- B5' -- B6'



Assuming that >50% of the hashpower follow the new rules, the old chain is

doomed to be orphaned:



Code: +-- B3 --- B4 --- B5 --- B6 --- B7 --- B8 --- ...

|

... -- B1 -- B2 --+

|

+-- B3' -- B4' -- B5' -- B6' (orphaned)



Hardforks may result in two chains that can co-exist indefinitely:



Code: +-- B3 --- B4 --- B5 --- B6 --- B7 --- B8 --- ...

|

... -- B1 -- B2 --+

|

+-- B3' -- B4' -- B5' -- B6' -- B7' -- B8' -- ...



Generalized Softforks



A *generalized* softfork introduces a transform function f(B)=B' that maps a

block B valid under the new rules to a block B' valid under the old rules.



After a generalized softfork three chains may exist:



* The new chain B3,B4,B5,... valid under the new rules only.

* The mapped chain f(B3),f(B4),f(B5),... valid under the old rules.

* The old chain B3',B4',B5',... valid under the old rules only.



E.g.



Code: +-- B3 ---- B4 ---- B5

|

... -- B1 -- B2 --+-- f(B3) - f(B4) - f(B5)

|

+-- B3' --- B4' --- B5' --- B6'



This is "generalized" softfork since defining f(B)=B (identity function)

reduces to the standard softfork case above.



As with standard softforks, if the majority of the hashpower follow the new

rules then the old chain B3',B4',B5',... is doomed to be orphaned:



Code: +-- B3 ---- B4 ---- B5 ---- B6 ---- B7 ---- ...

|

... -- B1 -- B2 --+-- f(B3) - f(B4) - f(B5) - f(B6) - f(B7) - ...

|

+-- B3' --- B4' --- B5' --- B6' (orphaned)



Example:



Segregated Witness can be thought of as an example of a generalized softfork.

Here the new block format consists of the combined old block and witness data.

The function f() simply strips the witness data to reveal a valid block under

the old rules:



Code: NewBlock := OldBlock ++ Witness

f(NewBlock) = OldBlock



An Arbitrary Block-size Increase Via a Generalized Softfork



Segregated Witness only allows for a modest effective blocksize increase

(although there can be other motivations for SW, but that is off-topic).



Instead we engineer a generalized softfork that allows an arbitrarily increase

of the blocksize limit. The proposal consists of two parts: (a) new rules for

valid blocks, and (b) a transformation function f().



The new block rules are very similar to the old block rules but with some

small changes. In summary the changes are:



* The MAX_BLOCK_SIZE limit is raised to some new limit

(e.g. 8Mb, BIP101, 2-4-8, BIP202, etc., or some other limit)

* The MerkleRoot field in the header has been re-interpreted.

* The CoinBaseTx must obey some additional new rules.



As with old blocks, a block under the new rules consists of a block header

followed by a vector of transactions [CoinBaseTx, Tx1, .., Txn], i.e.



Code: NewBlock := BlockHeader ++ NumTx ++ CoinBaseTx ++ Tx1 ++ .. ++ Txn



The block header format is the same as under the old rules defined as follows:



Code: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Ver | PrevHash |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| MerkleRoot | Time |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Bits | Nonce |

+-+-+-+-+-+-+-+-+



Under the old rules MerkleRoot is the Merkle root of the hashes of all

transactions included in the block, i.e.



Code: MerkleRoot = merkleRoot([hash(CoinBaseTx), hash(Tx1), .., hash(Txn)])



Under the new rules we instead define:



Code: MerkleRoot = merkleRoot([hash(CoinBaseTx)])



That is, under the new rules, MerkleRoot is the Merkle root of a singleton

vector containing the CoinBaseTx hash only.



In order to preserve the security properties of Bitcoin we additionally

require that the CoinBaseTx somehow encodes the Merkle root of the remaining

transactions [Tx1, .., Txn]. For example, this could be achieved by requiring

a mandatory OP_RETURN output that encodes this information, e.g.



Code: OP_RETURN merkleRoot([hash(Tx1), .., hash(Txn)])



Alternatively the Merkle root could be encoded in the coinbase itself. This

ensures that new transactions cannot be added/deleted from the block without

altering the MerkleRoot field in the header.



Aside from these changes and the increased MAX_BLOCK_SIZE, the new block must

obey all the rules of the old block format, e.g. valid PoW, have valid block

reward, contain valid transactions, etc., etc.



In order to be a generalized softfork we also need to define a mapping f()

from valid new blocks to valid blocks under the old rules. We can define this

as follows:



Code: NewBlock := BlockHeader ++ NumTx ++ CoinBaseTx ++ Tx1 ++ .. ++ Txn

f(NewBlock) := BlockHeader ++ 1 ++ CoinBaseTx



That is, function f() simply truncates the block so that it contains the

coinbase transaction only. After truncation, the MerkleRoot field of the

block header is valid under the old rules.



The proposed new rules combined with the transformation f() comprise a

generalized softfork. After the fork a new chain B3,B4,B5,... will be

generated under the new rules defined above, including an increased blocksize

limit. This new chain can be mapped to a valid chain f(B3),f(B4),f(B5),...

under the old rules. Assuming that >50% of the hashpower has adopted the new

rules, the mapped chain will orphan any competing chain under the old rules,

just like a standard softfork.



An interesting consequence of this design is that, since all mapped blocks are

empty, old clients will never see transactions confirming. This is be a

strong incentive for users to update their clients.



Conclusion



Conventional wisdoms suggests that increasing the blocksize limit requires a

hardfork. We show that it can instead be achieved using a generalized

softfork. Like with a standard softfork, a generalized softfork merely

requires a majority (>50%) of hash power rather than global consensus.

Experience has shown that the former is significantly easier to achieve.



Future Work:



Investigate other kinds of hardforks that can instead be implemented as

generalized softforks, and the security implications of such...



7943a2934d0be2f96589fdef2b2e00a2a7d8c3b782546bb37625d1669accb9b1

72f018588572ca2786168cb531d10e79b81b86d3fada92298225a0f950eed3a5

It is generally assumed that increasing the blocksize limit requires ahardfork. Instead we show that a increasing the limit can be achieved using a"generalized" softfork. Like standard softforks, generalized softforks need amere miner majority (>50% hashpower) rather than global consensus.After a softfork two potential chains exist:* The new chain B3,B4,B5,... valid under the new rules and old rules.* The old chain B3',B4',B5',... valid under the old rules only.E.g.Assuming that >50% of the hashpower follow the new rules, the old chain isdoomed to be orphaned:Hardforks may result in two chains that can co-exist indefinitely:A *generalized* softfork introduces a transform function f(B)=B' that maps ablock B valid under the new rules to a block B' valid under the old rules.After a generalized softfork three chains may exist:* The new chain B3,B4,B5,... valid under the new rules only.* The mapped chain f(B3),f(B4),f(B5),... valid under the old rules.* The old chain B3',B4',B5',... valid under the old rules only.E.g.This is "generalized" softfork since defining f(B)=B (identity function)reduces to the standard softfork case above.As with standard softforks, if the majority of the hashpower follow the newrules then the old chain B3',B4',B5',... is doomed to be orphaned:Example:Segregated Witness can be thought of as an example of a generalized softfork.Here the new block format consists of the combined old block and witness data.The function f() simply strips the witness data to reveal a valid block underthe old rules:Segregated Witness only allows for a modest effective blocksize increase(although there can be other motivations for SW, but that is off-topic).Instead we engineer a generalized softfork that allows an arbitrarily increaseof the blocksize limit. The proposal consists of two parts: (a) new rules forvalid blocks, and (b) a transformation function f().The new block rules are very similar to the old block rules but with somesmall changes. In summary the changes are:* The MAX_BLOCK_SIZE limit is raised to some new limit(e.g. 8Mb, BIP101, 2-4-8, BIP202, etc., or some other limit)* The MerkleRoot field in the header has been re-interpreted.* The CoinBaseTx must obey some additional new rules.As with old blocks, a block under the new rules consists of a block headerfollowed by a vector of transactions [CoinBaseTx, Tx1, .., Txn], i.e.The block header format is the same as under the old rules defined as follows:Under the old rules MerkleRoot is the Merkle root of the hashes of alltransactions included in the block, i.e.Under the new rules we instead define:That is, under the new rules, MerkleRoot is the Merkle root of a singletonvector containing the CoinBaseTx hash only.In order to preserve the security properties of Bitcoin we additionallyrequire that the CoinBaseTx somehow encodes the Merkle root of the remainingtransactions [Tx1, .., Txn]. For example, this could be achieved by requiringa mandatory OP_RETURN output that encodes this information, e.g.Alternatively the Merkle root could be encoded in the coinbase itself. Thisensures that new transactions cannot be added/deleted from the block withoutaltering the MerkleRoot field in the header.Aside from these changes and the increased MAX_BLOCK_SIZE, the new block mustobey all the rules of the old block format, e.g. valid PoW, have valid blockreward, contain valid transactions, etc., etc.In order to be a generalized softfork we also need to define a mapping f()from valid new blocks to valid blocks under the old rules. We can define thisas follows:That is, function f() simply truncates the block so that it contains thecoinbase transaction only. After truncation, the MerkleRoot field of theblock header is valid under the old rules.The proposed new rules combined with the transformation f() comprise ageneralized softfork. After the fork a new chain B3,B4,B5,... will begenerated under the new rules defined above, including an increased blocksizelimit. This new chain can be mapped to a valid chain f(B3),f(B4),f(B5),...under the old rules. Assuming that >50% of the hashpower has adopted the newrules, the mapped chain will orphan any competing chain under the old rules,just like a standard softfork.An interesting consequence of this design is that, since all mapped blocks areempty, old clients will never see transactions confirming. This is be astrong incentive for users to update their clients.Conventional wisdoms suggests that increasing the blocksize limit requires ahardfork. We show that it can instead be achieved using a generalizedsoftfork. Like with a standard softfork, a generalized softfork merelyrequires a majority (>50%) of hash power rather than global consensus.Experience has shown that the former is significantly easier to achieve.Future Work:Investigate other kinds of hardforks that can instead be implemented asgeneralized softforks, and the security implications of such...7943a2934d0be2f96589fdef2b2e00a2a7d8c3b782546bb37625d1669accb9b172f018588572ca2786168cb531d10e79b81b86d3fada92298225a0f950eed3a5

achow101

Legendary





Offline



Activity: 2254

Merit: 3454





bc1qshxkrpe4arppq89fpzm6c0tpdvx5cfkve2c8kl







ModeratorLegendaryActivity: 2254Merit: 3454bc1qshxkrpe4arppq89fpzm6c0tpdvx5cfkve2c8kl Re: Increasing the blocksize as a (generalized) softfork. December 20, 2015, 04:22:26 PM #3 I see a few problems with those proposal



1) You are proposing to fork the blockchain without consensus. This in itself is a problem, we don't want to fork without consensus (even with a soft fork) because there is still the possibility of the old chain surviving, and that can lead to some major problems.



2) Your generalized soft fork idea breaks one of the basic principles of Bitcoin, storing all of the transaction history in the blockchain. It is not possible to know what the transaction data is if you use your idea to transform blocks under new rules to blocks under old rules. It isn't backwards compatible so it isn't a soft fork. If I ran a client with the old rules, then I would not be able to know what the transactions were in that block without having to download the fork. That is completely pointless.



GitHub | GPG Key Fingerprint 0x17565732E08E5E41 Bitcoin Core contributor | Tip Me!: bc1qshxkrpe4arppq89fpzm6c0tpdvx5cfkve2c8kl

ZoomT



Offline



Activity: 15

Merit: 0







NewbieActivity: 15Merit: 0 Re: Increasing the blocksize as a (generalized) softfork. December 20, 2015, 04:38:02 PM #4 Quote from: knightdk on December 20, 2015, 04:22:26 PM 1) You are proposing to fork the blockchain without consensus.

A generalized softfork has the same minimum requirements of a standard softfork, i.e. >50% of mining hashpower. In practice it would wiser to shoot for something beyond the bare minimum, such as the standard 75% or 95% of hash power as with other forks. The point is that this proposal is no different than other softforks in terms of requirements.



Quote 2) Your generalized soft fork idea breaks one of the basic principles of Bitcoin, storing all of the transaction history in the blockchain.

This proposal is an alternative to hardforks which completely replace the blockchain with a new version under different rules. My proposal does exactly the same thing, but does so essentially as a softfork. The new chain keeps all the the transaction history on the chain under the new rules. A generalized softfork has the same minimum requirements of a standard softfork, i.e. >50% of mining hashpower. In practice it would wiser to shoot for something beyond the bare minimum, such as the standard 75% or 95% of hash power as with other forks. The point is that this proposal is no different than other softforks in terms of requirements.This proposal is an alternative towhich completely replace the blockchain with a new version under different rules. My proposal does exactly the same thing, but does so essentially as a softfork. The new chain keeps all the the transaction history on the chain under the new rules.

ZoomT



Offline



Activity: 15

Merit: 0







NewbieActivity: 15Merit: 0 Re: Increasing the blocksize as a (generalized) softfork. December 20, 2015, 04:42:44 PM #5 Quote from: socrates1024 on December 20, 2015, 03:56:22 PM Do you see a difference?

I have seen a similar proposal labeled as "extended blocks". It is also possible to view these ideas as a "generalized softforks" if one so desires.



The main difference is that there are no different types of blocks. In fact, the new block format is essentially the same as the old block format sans for a new blocksize limit. I have seen a similar proposal labeled as "extended blocks". It is also possible to view these ideas as a "generalized softforks" if one so desires.The main difference is that there are no different types of blocks. In fact, the new block format is essentially the same as the old block format sans for a new blocksize limit.

Taek



Offline



Activity: 543

Merit: 500









Hero MemberActivity: 543Merit: 500 Re: Increasing the blocksize as a (generalized) softfork. December 20, 2015, 04:46:06 PM #6



+ send transactions

+ receive transactions

+ receive transactions from the extended blocks



Though the definition is incomplete, though it only affects the implementation a little. When you add coins to the extended blocks, they get stuck in 'anyonecanspend' outputs as recognized by the old nodes. In your transformation, you add some specification that money sent back to old nodes be pulled out of the most sensible set of the anyonecanspend outputs (for some strict definition of sensible). You would also need to add a rule that the new blockchain can't spend so many outputs to old addresses that the transformation results in an old block greater than 1mb. Finally, I think it's worth highlighting that the transformation is somehow performed in a way that the POW is still valid on the old chain (ie using the coinbase txn to store a hash), though I think that this is implicitly clear.



Quote from: knightdk on December 20, 2015, 04:22:26 PM I see a few problems with those proposal



1) You are proposing to fork the blockchain without consensus. This in itself is a problem, we don't want to fork without consensus (even with a soft fork) because there is still the possibility of the old chain surviving, and that can lead to some major problems.



2) Your generalized soft fork idea breaks one of the basic principles of Bitcoin, storing all of the transaction history in the blockchain. It is not possible to know what the transaction data is if you use your idea to transform blocks under new rules to blocks under old rules. It isn't backwards compatible so it isn't a soft fork. If I ran a client with the old rules, then I would not be able to know what the transactions were in that block without having to download the fork. That is completely pointless.







I would refute both of those problems, especially if you maintain the three properties listed above. The old chain surviving is only problematic for miners that do not upgrade. This is the same as a 51% attack, and in fact all softforks are basically 51% attacks on non-upgraded miners, it's just that they are not typically deployed until much more than 51% hashpower is reached. Additionally, all nodes still have a full transaction history that they recognize as valid, even the old nodes. Their history will also contain a bunch of 'anyonecanspend' transactions that miner's for some reason aren't mining, but they can do full trustless verification of the coins that they own, and can spend them if they are willing to pay the fee. ZoomT, I would assert that your definition of a generalized softfork is incomplete. You want to make sure that old nodes can:+ send transactions+ receive transactions+ receive transactions from the extended blocksThough the definition is incomplete, though it only affects the implementation a little. When you add coins to the extended blocks, they get stuck in 'anyonecanspend' outputs as recognized by the old nodes. In your transformation, you add some specification that money sent back to old nodes be pulled out of the most sensible set of the anyonecanspend outputs (for some strict definition of sensible). You would also need to add a rule that the new blockchain can't spend so many outputs to old addresses that the transformation results in an old block greater than 1mb. Finally, I think it's worth highlighting that the transformation is somehow performed in a way that the POW is still valid on the old chain (ie using the coinbase txn to store a hash), though I think that this is implicitly clear.I would refute both of those problems, especially if you maintain the three properties listed above. The old chain surviving is only problematic for miners that do not upgrade. This is the same as a 51% attack, and in fact all softforks are basically 51% attacks on non-upgraded miners, it's just that they are not typically deployed until much more than 51% hashpower is reached. Additionally, all nodes still have a full transaction history that they recognize as valid, even the old nodes. Their history will also contain a bunch of 'anyonecanspend' transactions that miner's for some reason aren't mining, but they can do full trustless verification of the coins that they own, and can spend them if they are willing to pay the fee.

achow101

Legendary





Offline



Activity: 2254

Merit: 3454





bc1qshxkrpe4arppq89fpzm6c0tpdvx5cfkve2c8kl







ModeratorLegendaryActivity: 2254Merit: 3454bc1qshxkrpe4arppq89fpzm6c0tpdvx5cfkve2c8kl Re: Increasing the blocksize as a (generalized) softfork. December 20, 2015, 04:47:00 PM #7 Quote from: ZoomT on December 20, 2015, 04:38:02 PM A generalized softfork has the same minimum requirements of a standard softfork, i.e. >50% of mining hashpower. In practice it would wiser to shoot for something beyond the bare minimum, such as the standard 75% or 95% of hash power as with other forks. The point is that this proposal is no different than other softforks in terms of requirements.

Hard forks don't need consensus, we just want consensus to actually do one. It only requires the same amount of hashpower to execute. The difference between soft forks and hard forks is not the hashpower required, it is whether the new rules are backwards compatible (soft fork) or not (hard fork)



Quote from: ZoomT on December 20, 2015, 04:38:02 PM Besides, this proposal is an alternative to hardforks which completely replace the blockchain with a new version under different rules. My proposal does exactly the same thing, but does so essentially as a softfork. The new chain keeps all the the transaction history on the chain under the new rules.

Nothing about your proposal makes it backwards compatible (a soft fork). It is not possible to still use Bitcoin if you are running an old version of software, as is the case with hard forks. The point of a soft fork is that I don't need to upgrade but I can still send transactions, see confirmations, see other transactions, and consider other transactions and blocks as still valid even if they run under the new rules. Your proposal makes it so that I can't see confirmations (so I can't spend the Bitcoin because the transaction will remain in the mempool and then disappear when no one continues to relay it after it has been confirmed), and it won't consider new blocks containing actual block data as valid since they are too big. It is still a hard fork. Hard forks don't need consensus, we just want consensus to actually do one. It only requires the same amount of hashpower to execute. The difference between soft forks and hard forks is not the hashpower required, it is whether the new rules are backwards compatible (soft fork) or not (hard fork)Nothing about your proposal makes it backwards compatible (a soft fork). It is not possible to still use Bitcoin if you are running an old version of software, as is the case with hard forks. The point of a soft fork is that I don't need to upgrade but I can still send transactions, see confirmations, see other transactions, and consider other transactions and blocks as still valid even if they run under the new rules. Your proposal makes it so that I can't see confirmations (so I can't spend the Bitcoin because the transaction will remain in the mempool and then disappear when no one continues to relay it after it has been confirmed), and it won't consider new blocks containing actual block data as valid since they are too big. It is still a hard fork. GitHub | GPG Key Fingerprint 0x17565732E08E5E41 Bitcoin Core contributor | Tip Me!: bc1qshxkrpe4arppq89fpzm6c0tpdvx5cfkve2c8kl

DannyHamilton



Offline



Activity: 2338

Merit: 1729









LegendaryActivity: 2338Merit: 1729 Re: Increasing the blocksize as a (generalized) softfork. December 20, 2015, 04:50:30 PM #8 Quote from: knightdk on December 20, 2015, 04:22:26 PM I see a few problems with those proposal



1) You are proposing to fork the blockchain without consensus. This in itself is a problem, we don't want to fork without consensus (even with a soft fork) because there is still the possibility of the old chain surviving, and that can lead to some major problems.



Actually, using this proposal, it looks like the only way the old chain could survive is if the users that don't want the new chain create a hard fork to reject the blocks created by those that do want the new chain.



Quote from: knightdk on December 20, 2015, 04:22:26 PM 2) Your generalized soft fork idea breaks one of the basic principles of Bitcoin, storing all of the transaction history in the blockchain. It is not possible to know what the transaction data is if you use your idea to transform blocks under new rules to blocks under old rules. It isn't backwards compatible so it isn't a soft fork. If I ran a client with the old rules, then I would not be able to know what the transactions were in that block without having to download the fork. That is completely pointless.



If I'm understanding this proposal correctly, it could be described as a hard fork with a simultaneous majority hash power attack on the old fork.



The OP has indicated a method by which the hash power that hashes the blocks on the new format side of the hard fork can simultaneously hash empty blocks on the old format side.



That way, once the hashing participants on the new format side have enough hash power, the old format side will no longer be able to confirm any transactions ever again. They will be forced to either hard fork to keep their old format, or they will have to join the new format. Actually, using this proposal, it looks like the only way the old chain could survive is if the users that don't want the new chain create a hard fork to reject the blocks created by those that do want the new chain.If I'm understanding this proposal correctly, it could be described as a hard fork with a simultaneous majority hash power attack on the old fork.The OP has indicated a method by which the hash power that hashes the blocks on the new format side of the hard fork can simultaneously hash empty blocks on the old format side.That way, once the hashing participants on the new format side have enough hash power, the old format side will no longer be able to confirm any transactions ever again. They will be forced to either hard fork to keep their old format, or they will have to join the new format. https://21.co/dannyhamilton/



My Merit sending policy: My Merit sending policy: https://bitcointalk.org/index.php?topic=2822212.0

achow101

Legendary





Offline



Activity: 2254

Merit: 3454





bc1qshxkrpe4arppq89fpzm6c0tpdvx5cfkve2c8kl







ModeratorLegendaryActivity: 2254Merit: 3454bc1qshxkrpe4arppq89fpzm6c0tpdvx5cfkve2c8kl Re: Increasing the blocksize as a (generalized) softfork. December 20, 2015, 05:00:39 PM #9 Quote from: DannyHamilton on December 20, 2015, 04:50:30 PM If I'm understanding this proposal correctly, it could be described as a hard fork with a simultaneous majority hash power attack on the old fork.



The OP has indicated a method by which the hash power that hashes the blocks on the new format side of the hard fork can simultaneously hash empty blocks on the old format side.



That way, once the hashing participants on the new format side have enough hash power, the old format side will no longer be able to confirm any transactions ever again. They will be forced to either hard fork to keep their old format, or they will have to join the new format.

So it really would just be discouraging any use of the old chain and force people to switch to the new one.



The way I understood it was that it is supposed to be that people on the old chain can still use Bitcoin normally. As I said in an earlier post, this is not possible unless somehow all of the UTXOs in the new block are presented in the old block format. But I think in order to do that, a software upgrade is still needed so that the client actually knows what to do with that data because it cannot be in the same format that is currently used. Either way, I don't think the idea that this is a soft fork works, it is still a hard fork. So it really would just be discouraging any use of the old chain and force people to switch to the new one.The way I understood it was that it is supposed to be that people on the old chain can still use Bitcoin normally. As I said in an earlier post, this is not possible unless somehow all of the UTXOs in the new block are presented in the old block format. But I think in order to do that, a software upgrade is still needed so that the client actually knows what to do with that data because it cannot be in the same format that is currently used. Either way, I don't think the idea that this is a soft fork works, it is still a hard fork. GitHub | GPG Key Fingerprint 0x17565732E08E5E41 Bitcoin Core contributor | Tip Me!: bc1qshxkrpe4arppq89fpzm6c0tpdvx5cfkve2c8kl

ZoomT



Offline



Activity: 15

Merit: 0







NewbieActivity: 15Merit: 0 Re: Increasing the blocksize as a (generalized) softfork. December 20, 2015, 05:08:17 PM #10 Quote from: knightdk on December 20, 2015, 05:00:39 PM The way I understood it was that it is supposed to be that people on the old chain can still use Bitcoin normally.

No, a hardfork requires everyone to upgrade to a new client. After a hardfork old clients will outright reject the new chain.



If that does not happen, and if a significant portion of the hashpower refuses to upgrade, then Bitcoin will split into two completing cryptocurrenies that can co-exist forever. This is the worst-case scenario. No, a hardfork requiresto upgrade to a new client. After a hardfork old clients will outright reject the new chain.If that does not happen, and if a significant portion of the hashpower refuses to upgrade, then Bitcoin will split into two completing cryptocurrenies that can co-exist forever. This is the worst-case scenario.

DannyHamilton



Offline



Activity: 2338

Merit: 1729









LegendaryActivity: 2338Merit: 1729 Re: Increasing the blocksize as a (generalized) softfork. December 20, 2015, 05:11:44 PM #11 Quote from: ZoomT on December 20, 2015, 05:08:17 PM Quote from: knightdk on December 20, 2015, 05:00:39 PM The way I understood it was that it is supposed to be that people on the old chain can still use Bitcoin normally.

No, a hardfork requires everyone to upgrade to a new client. After a hardfork old clients will outright reject the new chain.

No, a hardfork requiresto upgrade to a new client. After a hardfork old clients will outright reject the new chain.

Which is why this is a hard fork. Old clients will outright reject the new chain with the larger blocks.



They will accept the majority hash power attacks against their own chain, but that is a separate chain with separate rules. They would have to deal with this the same way they would deal with any majority hash power attack that refuses to confirm transactions.



Quote from: ZoomT on December 20, 2015, 05:08:17 PM If that does not happen, and if a significant portion of the hashpower refuses to upgrade, then Bitcoin will split into two completing cryptocurrenies that can co-exist forever. This is the worst-case scenario.



Correct, and this is what your proposal does.



If a "significant portion of the hashpower refuses to upgrade" to your proposal, then all they have to do is had code in a rejection of one of your blocks and "Bitcoin will split into two completing cryptocurrenies that can co-exist forever".



I'm curious, how does your intended solution expect to deal with the situation where the old format has a longer chain? This would mean that the old network would reject the transformed chain, but how would your system be aware that the transformed chain was rejected and what would it do with all those transactions that had been confirmed in it's big block chain? Which is why this is a hard fork. Old clients will outright reject the new chain with the larger blocks.They will accept the majority hash power attacks against their own chain, but that is a separate chain with separate rules. They would have to deal with this the same way they would deal with any majority hash power attack that refuses to confirm transactions.Correct, and this is what your proposal does.If a "significant portion of the hashpower refuses to upgrade" to your proposal, then all they have to do is had code in a rejection of one of your blocks and "Bitcoin will split into two completing cryptocurrenies that can co-exist forever".I'm curious, how does your intended solution expect to deal with the situation where the old format has a longer chain? This would mean that the old network would reject the transformed chain, but how would your system be aware that the transformed chain was rejected and what would it do with all those transactions that had been confirmed in it's big block chain? https://21.co/dannyhamilton/



My Merit sending policy: My Merit sending policy: https://bitcointalk.org/index.php?topic=2822212.0

ZoomT



Offline



Activity: 15

Merit: 0







NewbieActivity: 15Merit: 0 Re: Increasing the blocksize as a (generalized) softfork. December 20, 2015, 05:16:29 PM #12 Quote from: DannyHamilton on December 20, 2015, 04:50:30 PM Actually, using this proposal, it looks like the only way the old chain could survive is if the users that don't want the new chain create a hard fork to reject the blocks created by those that do want the new chain.

Technically this can be done via a standard softfork.



The same is true for any softfork. For example, if some portion of the hashpower were passionately against the OP_CLOCKTIMEVERIFY fork, they could create a competing softfork that makes any block including a OP_CLOCKTIMEVERIFY transaction invalid. If this occurred, then Bitcoin will split into two competing cryptocurrencies (both softforks of the original chain).



Quote If I'm understanding this proposal correctly, it could be described as a hard fork with a simultaneous majority hash power attack on the old fork.

Yes, in the same way a standard softfork uses the majority hash power to attack any chain under the old rules. Technically this can be done via a standard softfork.The same is true for any softfork. For example, if some portion of the hashpower were passionately against the OP_CLOCKTIMEVERIFY fork, they could create a competing softfork that makes any block including a OP_CLOCKTIMEVERIFY transaction invalid. If this occurred, then Bitcoin will split into two competing cryptocurrencies (both softforks of the original chain).Yes, in the same way a standard softfork uses the majority hash power to attack any chain under the old rules.

ZoomT



Offline



Activity: 15

Merit: 0







NewbieActivity: 15Merit: 0 Re: Increasing the blocksize as a (generalized) softfork. December 20, 2015, 05:37:00 PM #14 Quote from: DannyHamilton on December 20, 2015, 05:11:44 PM Which is why this is a hard fork. Old clients will outright reject the new chain with the larger blocks.



This is why I called it a "generalized" softfork, since it has properties of softforks but has the power of a hardfork (in this case). It is sort of an "in-between" kind of fork.



Quote If a "significant portion of the hashpower refuses to upgrade" to your proposal, then all they have to do is had code in a rejection of one of your blocks and "Bitcoin will split into two completing cryptocurrenies that can co-exist forever".

I do not disagree but the same it true for all softforks (e.g. OP_CLOCKTIMEVERIFY).



Quote I'm curious, how does your intended solution expect to deal with the situation where the old format has a longer chain? This would mean that the old network would reject the transformed chain, but how would your system be aware that the transformed chain was rejected and what would it do with all those transactions that had been confirmed in it's big block chain?

Since this is a (generalized) softfork, there is a very strong incentive for miners to upgrade to the new rules (orphaned blocks). So this should not happen provided the majority hash power are on board when the fork occurs.



However, if it *did* happen, then this is a disaster no matter how the fork is designed. Either the old (longer) chain is rejected as invalid, or there is a very large reorg undoing many multi-confirmation transactions. This is why I called it a "generalized" softfork, since it has properties of softforks but has the power of a hardfork (in this case). It is sort of an "in-between" kind of fork.I do not disagree but the same it true for all softforks (e.g. OP_CLOCKTIMEVERIFY).Since this is a (generalized) softfork, there is a very strong incentive for miners to upgrade to the new rules (orphaned blocks). So this should not happen provided the majority hash power are on board when the fork occurs.However, if it *did* happen, then this is a disaster no matter how the fork is designed. Either the old (longer) chain is rejected as invalid, or there is a very large reorg undoing many multi-confirmation transactions.