Bitcoin 1 and Bitcoin 2: A solution to the block size problem

[calian]

Bitcoin is at a decision point. Do we want to stick with the 1 MB block size limit and become merely a reserve currency or the equivalent of gold in the present day system? Or have we become used to the convenience of cheap, rapid, world-wide money transfers and would we prefer to become a commerce platform to supplant Visa, PayPal, etc.?

So far it seems we can't have both. Increase the block size to handle millions of transactions per hour and the hardware requirements to run the system will rapidly preclude anyone running the program from home and having a say in being their own bank.

On the other hand if we either hold the present cap or go with some scheme to only allow it to grow very slowly we'll soon start seeing the pinch on transactions. Eventually it may only make sense to send bitcoins in excess of $1000 or more due to fee levels. Commerce would be impossible except for using third party providers such as MTGOX codes that stay off the blockchain.

My proposal would allow us to have our cake and eat it too. It enables low cost world-wide decentralized transactions and store of value as we've come to expect with bitcoin. It also allows the network to expand to handle the massive volumes we'd like to see ourselves grow into.

Bitcoin 1 is what we have today. Quite convenient that the addresses start with a 1 actually. This chain would continue with the 1 MB per block hard cap. This is the store-of value chain that people can run nodes for on consumer hardware at home. It doesn't handle every satoshi for every losing bet on the entire internet. When someone wants to use this network for a transaction they can eventually expect to pay $5 or more in transaction fees.

Bitcoin 2 is the transactional blockchain. This one will quickly get to the point where it will require special hardware most likely in colocation centers to handle the deluge of transactions. Now what makes this different than an alt chain? The answer is how you get Bitcoin 2 coins. The way to get these coins is by proof of burn of your Bitcoin 1 coins. I propose setting minimum size limits for conversions between the two chains such as to go from Bitcoin 1 to Bitcoin 2 you have to send at least 1 coin. To go from Bitcoin 2 to Bitcoin 1 you have to send at least 50 coins.

Merged mining of both chains would obviously be simple for anyone capable of mining on the Bitcoin 2 network. One concern I have is if Bitcoin 2 could launch without a block subsidy existing solely on fees since we want to keep the original 21 million cap feature intrinsic to the bitcoin idea. Miners might also initially resist it as it would provide a lower fee area for users to transact. Another idea that could be pulled from previous alt chains would be setting a shorter block time. The prices would be identical between the chains avoiding any confusion on the part of users. Addresses starting with a 1 or a 2 would help differentiate which protocol was being used.

[killerstorm]

I've been thinking about this for quite some time (IIRC I posted a message about use of multiple chains for scalability ~2 years ago), and I think there is somewhat better solution: split blocks into two parts, permanent and temporary.

People can move their normal Bitcoins into temporary chain via a special transaction, and they can move it back too. That's the difference from your approach.

Obviously, we can expect temporary part to be more microtransaction-friendly as keeping transactions forever no longer bothers miners.

Some miners can choose to follow only permanent Bitcoins. It is possible because they can see that transfers is balanced.

Say, you send your 1 Bitcoin into temporary chain by sending it to yourself with SPLIT flag. Now you cannot spend it on the permanent chain without doing MERGE transaction.

Only miners who follow both permanent and temporary parts can check whether MERGE transaction was valid. However, miners who follow only permanent chain do not care about it because they can confirm that transaction does not increase number of Bitcoins in existence without following both parts.

Frankly, this is too radical for Bitcoin, perhaps some alt-chain will try it first.

[solex]

calian, it just isn't necessary to do what your OP describes as Bitcoin is very scalable. It just needs a reasonable amount of dev work.

consider:
https://bitcointalk.org/index.php?topic=150306.msg1597695#msg1597695

[BlackBison]

Note that the market has been somewhat preparing for such a possibility with Litecoin as your Bitcoin 2. In addition it has 4x the block rate which makes it more useful for a transactions network, with btc remaining as a core gold standard for savings.

Now dont get me wrong the ltc devs are not planning this right now, but i am sure they would take it in that direction if needed (they do describe ltc as 'silver to bitcoins gold' after all)- this is one of the reasons ltc has performed so well: we need more options as well as redundancy to cope with the various unforseen problems that will no doubt crop up on our long and perilous crypto journey ahead.

[behindtext]

Bitcoin is at a decision point. Do we want to stick with the 1 MB block size limit and become merely a reserve currency or the equivalent of gold in the present day system? Or have we become used to the convenience of cheap, rapid, world-wide money transfers and would we prefer to become a commerce platform to supplant Visa, PayPal, etc.?

So far it seems we can't have both. Increase the block size to handle millions of transactions per hour and the hardware requirements to run the system will rapidly preclude anyone running the program from home and having a say in being their own bank.

On the other hand if we either hold the present cap or go with some scheme to only allow it to grow very slowly we'll soon start seeing the pinch on transactions. Eventually it may only make sense to send bitcoins in excess of $1000 or more due to fee levels. Commerce would be impossible except for using third party providers such as MTGOX codes that stay off the blockchain.

i think you're being a bit dramatic.  there is some merit to what you say since many countries have crappy broadband access speeds, like the US, which puts a big constraint on operating a full bitcoind node.

in places where there are better network links, it's not so unreasonable to expect that a modern machine with a good uplink can keep up with the demand for tx.  steady progress in link speed seems to be the largest constraint.

[killerstorm]

calian, it just isn't necessary to do what your OP describes as Bitcoin is very scalable. It just needs a reasonable amount of dev work.

Unless I'm missing something UTXO tree can be used by miners only if it is mined in the main chain, not merged-mined.

And we want it to be used by miners because otherwise miners have to download whole blockchain at start.

If UTXO tree is maintained via merged mining which has only 1/1000 of hashing power, attack on such lightweight miners will cost only 1/1000 of hashing power. And it has potential to ruin SPV.

UTXO tree has a great potential, but it needs to be implemented properly.

[justusranvier]

Bitcoin is at a decision point. Do we want to stick with the 1 MB block size limit and become merely a reserve currency or the equivalent of gold in the present day system? Or have we become used to the convenience of cheap, rapid, world-wide money transfers and would we prefer to become a commerce platform to supplant Visa, PayPal, etc.?

So far it seems we can't have both. Increase the block size to handle millions of transactions per hour and the hardware requirements to run the system will rapidly preclude anyone running the program from home and having a say in being their own bank.

On the other hand if we either hold the present cap or go with some scheme to only allow it to grow very slowly we'll soon start seeing the pinch on transactions. Eventually it may only make sense to send bitcoins in excess of $1000 or more due to fee levels. Commerce would be impossible except for using third party providers such as MTGOX codes that stay off the blockchain.

My proposal would allow us to have our cake and eat it too. It enables low cost world-wide decentralized transactions and store of value as we've come to expect with bitcoin. It also allows the network to expand to handle the massive volumes we'd like to see ourselves grow into.

Bitcoin 1 is what we have today. Quite convenient that the addresses start with a 1 actually. This chain would continue with the 1 MB per block hard cap. This is the store-of value chain that people can run nodes for on consumer hardware at home. It doesn't handle every satoshi for every losing bet on the entire internet. When someone wants to use this network for a transaction they can eventually expect to pay $5 or more in transaction fees.

Bitcoin 2 is the transactional blockchain. This one will quickly get to the point where it will require special hardware most likely in colocation centers to handle the deluge of transactions. Now what makes this different than an alt chain? The answer is how you get Bitcoin 2 coins. The way to get these coins is by proof of burn of your Bitcoin 1 coins. I propose setting minimum size limits for conversions between the two chains such as to go from Bitcoin 1 to Bitcoin 2 you have to send at least 1 coin. To go from Bitcoin 2 to Bitcoin 1 you have to send at least 50 coins.

Merged mining of both chains would obviously be simple for anyone capable of mining on the Bitcoin 2 network. One concern I have is if Bitcoin 2 could launch without a block subsidy existing solely on fees since we want to keep the original 21 million cap feature intrinsic to the bitcoin idea. Miners might also initially resist it as it would provide a lower fee area for users to transact. Another idea that could be pulled from previous alt chains would be setting a shorter block time. The prices would be identical between the chains avoiding any confusion on the part of users. Addresses starting with a 1 or a 2 would help differentiate which protocol was being used.

Have you see this?

https://bitcointalk.org/index.php?topic=88208.0

[gmaxwell]

If UTXO tree is maintained via merged mining which has only 1/1000 of hashing power, attack on such lightweight miners will cost only 1/1000 of hashing power. And it has potential to ruin SPV.
UTXO tree has a great potential, but it needs to be implemented properly.

"Merged mined" UTXO is worthless except as a development tool. If a committed UTXO is useful it would have to be as a block validity rule.  Such a rule could be implemented easily, and so it's not that huge a deal.

The bigger question though is the complexity.  A non-committed UXTO set can be implemented as a hashtable with O(1) operators for storage and retrieval. Any kind of committed UXTO will have only log(n) scaling.  Because n can never be that large we're only talking about making it some small factor worse... but it's still somewhat suspect to talk about improving scalability by starting with a "lets make the complexity a factor of X worse".  Then you add in the complexity of making another complicated algorithm a normative bit-exact addition to the system's rules.

I think the rewards will be clear enough, but its something that is hard to even discuss absent some example implementations.
 

[Evan]

Bitcoin is at a decision point. Do we want to stick with the 1 MB block size limit and become merely a reserve currency or the equivalent of gold in the present day system? Or have we become used to the convenience of cheap, rapid, world-wide money transfers and would we prefer to become a commerce platform to supplant Visa, PayPal, etc.?

So far it seems we can't have both. Increase the block size to handle millions of transactions per hour and the hardware requirements to run the system will rapidly preclude anyone running the program from home and having a say in being their own bank.

On the other hand if we either hold the present cap or go with some scheme to only allow it to grow very slowly we'll soon start seeing the pinch on transactions. Eventually it may only make sense to send bitcoins in excess of $1000 or more due to fee levels. Commerce would be impossible except for using third party providers such as MTGOX codes that stay off the blockchain.

My proposal would allow us to have our cake and eat it too. It enables low cost world-wide decentralized transactions and store of value as we've come to expect with bitcoin. It also allows the network to expand to handle the massive volumes we'd like to see ourselves grow into.

Bitcoin 1 is what we have today. Quite convenient that the addresses start with a 1 actually. This chain would continue with the 1 MB per block hard cap. This is the store-of value chain that people can run nodes for on consumer hardware at home. It doesn't handle every satoshi for every losing bet on the entire internet. When someone wants to use this network for a transaction they can eventually expect to pay $5 or more in transaction fees.

Bitcoin 2 is the transactional blockchain. This one will quickly get to the point where it will require special hardware most likely in colocation centers to handle the deluge of transactions. Now what makes this different than an alt chain? The answer is how you get Bitcoin 2 coins. The way to get these coins is by proof of burn of your Bitcoin 1 coins. I propose setting minimum size limits for conversions between the two chains such as to go from Bitcoin 1 to Bitcoin 2 you have to send at least 1 coin. To go from Bitcoin 2 to Bitcoin 1 you have to send at least 50 coins.

Merged mining of both chains would obviously be simple for anyone capable of mining on the Bitcoin 2 network. One concern I have is if Bitcoin 2 could launch without a block subsidy existing solely on fees since we want to keep the original 21 million cap feature intrinsic to the bitcoin idea. Miners might also initially resist it as it would provide a lower fee area for users to transact. Another idea that could be pulled from previous alt chains would be setting a shorter block time. The prices would be identical between the chains avoiding any confusion on the part of users. Addresses starting with a 1 or a 2 would help differentiate which protocol was being used.

have you seen my thread?

https://bitcointalk.org/index.php?topic=194471.0;topicseen

[TierNolan]

I've been thinking about this for quite some time (IIRC I posted a message about use of multiple chains for scalability ~2 years ago), and I think there is somewhat better solution: split blocks into two parts, permanent and temporary.

People can move their normal Bitcoins into temporary chain via a special transaction, and they can move it back too. That's the difference from your approach.

What is the move back purpose? 

I assume there is a delay.  You send back your coins and have to wait 100 blocks.  The rule is therefore that return payments are valid if they are buried at least 100 deep in the alt-chain.

If a fork or something breaks things, then coins in the temp chain would all be deweighted together.  You could add a rule that the chain must be solid for the 100 blocks.

I suggested something similar where the number of chains increases by a factor of 2 each time.

Moving money downward gets you cheaper tx fees and probably faster confirms.  However, it makes it harder to spend.  Merchants could have addresses on all the leaf chains.  Markets would allow fast movement of money between leaves.

[killerstorm]

What is the move back purpose? 

To make sure that coins have more-or-less the same purchasing power. If coin1->coin2 conversion is possibe, but coin2->coin1 is not possible, then it is possible for coin2 to become significantly less valuable, and thus dead.

Obviously, implementing one-way conversion is much easier, but not that much interesting.

I assume there is a delay.  You send back your coins and have to wait 100 blocks.  The rule is therefore that return payments are valid if they are buried at least 100 deep in the alt-chain.

Yep, but it looks  quite a bit fragile.

Moving money downward gets you cheaper tx fees and probably faster confirms.  However, it makes it harder to spend.  Merchants could have addresses on all the leaf chains.  Markets would allow fast movement of money between leaves.

Well, you can use same private key on all chains, but you need to negotiate whether merchant accepts coins from a particular chain.

[solex]

Well, you can use same private key on all chains, but you need to negotiate whether merchant accepts coins from a particular chain.

This is the problem: "a particular chain"

Cryptocurrency experiments don't automatically translate to mainstream business. All that businesses want is a reliable, fast, secure and simple Bitcoin. They have no stomach for multiple variations, alt-chains or alt-coins. Think Sony/Betamax BluRay/HDDVD. Competing standards or variations are a total pain in the backside for merchants and consumers.

Occam's Razor has the fastest road to success though scaling what already exists (bug-fixes and add-ons are still welcome of course!)

[Etlase2]

I've been thinking about this for quite some time (IIRC I posted a message about use of multiple chains for scalability ~2 years ago), and I think there is somewhat better solution: split blocks into two parts, permanent and temporary.

People can move their normal Bitcoins into temporary chain via a special transaction, and they can move it back too. That's the difference from your approach.

Obviously, we can expect temporary part to be more microtransaction-friendly as keeping transactions forever no longer bothers miners.

Some miners can choose to follow only permanent Bitcoins. It is possible because they can see that transfers is balanced.

Say, you send your 1 Bitcoin into temporary chain by sending it to yourself with SPLIT flag. Now you cannot spend it on the permanent chain without doing MERGE transaction.

Only miners who follow both permanent and temporary parts can check whether MERGE transaction was valid. However, miners who follow only permanent chain do not care about it because they can confirm that transaction does not increase number of Bitcoins in existence without following both parts.

Frankly, this is too radical for Bitcoin, perhaps some alt-chain will try it first.

This is an interesting idea. But presumably the person who initially made the tx on the main chain would have to be the one that signs the tx that another person can redeem on the main chain. But that person cannot then transfer it to someone else because his signature won't meet the main chain's script requirement. In this respect, no data is really saved anywhere. But I could very easily be missing something.

I was thinking about a similar idea for an account based ledger where coins could be transferred to an account that uses a threshold key that is updated for each new incoming tx (or some other similar mechanism), then within that account a subnetwork could run that approves txes back to the main ledger without any one person having control. In theory anyway, there would be a lot of complexities and such, but it wouldn't need to be handled by the network, and this subnetwork could potentially be used to perform zerocoin type transactions that make it difficult for those participating to know who is moving what, and to the main network, any coins coming out are completely anonymized.

Only the very inkling of an idea though, I have not thought through much of it. And this idea wouldn't lower bandwidth usage of the network except in the case of anonymizing money and making it less expensive to do so.

[TierNolan]

What is the move back purpose? 

To make sure that coins have more-or-less the same purchasing power. If coin1->coin2 conversion is possibe, but coin2->coin1 is not possible, then it is possible for coin2 to become significantly less valuable, and thus dead.

Sorry I meant process not purpose. 

I assume there is a delay.  You send back your coins and have to wait 100 blocks.  The rule is therefore that return payments are valid if they are buried at least 100 deep in the alt-chain.

Yep, but it looks  quite a bit fragile.

I think you would have to build into the spec debasing of the alt chain coins.

If a 100 block chain reversal happens, then money lost from the alt chain is gone and everyone on the alt chain should take an equal hit.  Otherwise, you get a bank run like effect on the alt chain.

I think the main chain could stamp the secondary chain every so often.  There could be 2 hashes, the current alt chain end block and the hash of the block 100 from the end.  All blocks on the alt chain up to the earlier hash would then be deemed valid until the next stamp. 

The next stamp would likely just representing extending the alt chain, so it would just add more valid blocks.  However, after a 100 deep fork, it would invalidate previously valid transactions in the alt chain.  If those transactions were send to main chain, then the can't be cancelled by the alt chain.

Non double spends could be included again.  The rule would require them being re-added.  However, double spends would have to debase the alt chain coins.

[killerstorm]

This is an interesting idea. But presumably the person who initially made the tx on the main chain would have to be the one that signs the tx that another person can redeem on the main chain. But that person cannot then transfer it to someone else because his signature won't meet the main chain's script requirement. In this respect, no data is really saved anywhere. But I could very easily be missing something.

Well, I'll try again...

Suppose we have two separate chains: Bitcoin and Fastcoin. Bitcoin is more secure, but isn't friendly to microtransactions.

Suppose a market maker John notices that a unit of Fastcoin is more valuable than unit of Bitcoin, so he sees a profit opportunity in converting Bitcoins to Fastcoins and selling Fastcoins.

He creates SPLIT transaction with 100 Bitcoins he has. Now he gets 100 Fastcoins, and he can then sell (or spend) them...

Later he finds that Fastcoin drops in value: 1 Fastcoin = 0.95 Bitcoins. He now wants to convert Fastcoins back to Bitcoins.

To do that, he first buys Fastcoins on market. Then he creates DESTROY transaction on Fastcoin chain. And then he creates a MERGE transaction on Bitcoin blockchain.

MERGE transaction uses output of a previous SPLIT transaction, so on Bitcoin side it follows same conservation rules as a normal Bitcoin transaction. It is like sending 100 Bitcoins to yourself with additional condition.

MERGE transaction needs to reference DESTROY transaction.

Miners can check whether referenced DESTROY transaction was included into Fastcoin chain via SPV.

However, note that Bitcoin strictly follows its own conservation rules, so you have same guarantees as before. It does not mean that we are using SPV for Bitcoin.

What happens if there is a deep reorg on Fastcoin chain?

When miners include MERGE transaction into Bitcoin blockchain, they will stamp Fastcoin blockchain at the same time. Miners who mine subsequent blocks will have to take this into account, i.e. if there is a fork they should be stamped chain as valid. So there is never a disagreement about what Fastcoin chain is valid among Bitcoin miners.

This means that stamps-from-Bitcoin-chain can override Fastcoin's own PoW.

On surface it seems to make Fastcoin less secure, but as TierNolan have noted, a delay can make attack-via-Bitcoin infeasible.

I'm not 100% sure, but there might be a way to match PoW so that attack-from-Bitcoin costs no less than usual 51% attack.

So here's what we get in the end:

1. Bitcoin is exactly as secure as before if MERGE transaction can never produce Bitcoin blockchain forks or orphans.
2. Fastcoin is just as secure as a merged-mined chain.
3. Fastcoin can use UTXO-based security if necessary, however it might be just an offload.
4. Overhead in Bitcoin chain is minimal.

[TierNolan]

This means that stamps-from-Bitcoin-chain can override Fastcoin's own PoW.

For clarity here, these stamps would be without checking fastcoin. 

So, the ordered rules for fastcoin would be

A) Valid fastcoin blocks beat invalid fastcoin blocks
B) Earlier stamped fastcoin blocks beat later / unstamped fastcoin blocks
C) Fastcoin blocks with more POW beats fastcoins with less POW

So, to compare 2 chains

- discard any invalid blocks on either chain
- find the fork point
- scan forward on each fork until you hit a stamped block
- The fork with the earliest stamped block wins
- If neither have a stamped block, then the fork with the most POW wins

On surface it seems to make Fastcoin less secure, but as TierNolan have noted, a delay can make attack-via-Bitcoin infeasible.

Right, the longer the delay, the more expensive the attack.

However, if a large number of bitcoins are moved to fastcoin, then it could be worth it.  If fastcoin is getting 1% of the hashing of the main chain, then each block is getting 0.25 BTCs worth of hashing (assuming 25 block rewards).  If you need to do 100 blocks worth of hashes to spend fastcoins, then if more than 25 BTC of fastcoins are available, then it is worth directly buying the hashing power to perform a multi-spend.

The issue is that the alt-chain must be able to spend any of the merged transactions somehow.

[Cryddit]

bump.

Just a note folks.  The debate's been here for a while. 

We do something, or we keep kicking the can down the road?

[ebliever]

Sounds like the time is coming to do something now, or bitcoin starts spewing steam and overheating as the 1 MB limit is hit. That doesn't help anything in the long run.

Seems to me that an altcoin can fulfill the role of 1-MB limit Bitcoin; I'll let the market decide which one. Just take bitcoin to 20 MB or whatever is decided, and people who favored the 1 MB limit for good reasons can start casting about for which altcoin to raise up. Maybe Litecoin, or maybe Blackcoin (has the cache/image that I associate with the 1-MB limit), or Bitshares or Nxt or something.

[NxtChg]

Bitcoin 1 is ...

Bitcoin 2 is ...

You had one problem. Now you have two

So what you're basically proposing is to add a side-chain to Bitcoin. Where's novelty?