Announcement - Bitcoin project to full fork to flexible blocksizes

[jl777]

as a test release should be fine as there wont be any vendors accepting the new version and as long as there is no way to spend it, then it should present a target.

however for the actual launch having a fork seems to expose it to the tainted satoshi attack. not sure how to prevent it as once an incompatible block is created, the miner could make a million tainted satoshis which magically split all the original bitcoins into two coins.

kind of like ETC from ETH in miniature, but since it is on an tx by tx basis, many vendors will be unaware. Maybe by coordinating with exchanges it will prevent most abuse. still it is a pretty important issue to solve from a practical point

 

[satoshis_sockpuppet]

As long as you can't mix up transactions I think it's fine. (AFAIR this wasn't a big problem?)

If a test releases catches up and gets traded, that would be a luxury problem to have.

 

[molecular]

I just had some real life experience with splitting funds (ethereum classic / ethereum fork) between forks. No precautions were taken against replay attacks (this had been done in earlier ethereum forks, not sure why they didn't do it this time: just make tx incompatible).

It was rather hard to split the coins (move them to different addresses on each fork). Had to use multiple attempts... obviously automatic replay attacks were being done and I had to push 2 different transactions to the 2 networks and hope each would be mined before it was mined on the respective other chain by some "malicious cross-miner". Making things even harder the smaller classic chain was under attack and at one point a reorg took place and undid my successful (or so I thought) split.

All in all a rather unpleasant experience. Best to avoid it by somehow making transaction (or signatures?) incompatible.

 

[freetrader]

however for the actual launch having a fork seems to expose it to the tainted satoshi attack. not sure how to prevent it as once an incompatible block is created, the miner could make a million tainted satoshis which magically split all the original bitcoins into two coins.

I don't think I've heard of this attack. If anyone has a link with further details, can you please let me know, or describe very briefly how a miner performs this?

Thanks for your continued input btw!

 

[jl777]

the https://bitcointalk.org/index.php?topic=1157679.180 explains the concept, but the tl:dr is that if a tx has inputs that are illegal it will reject that tx

Which is not really any news, but consider two chains that start from the identical state and they fork such that one chain is happy with 2MB blocks, the other isnt. The moment there is a block > 1MB, the 1MB chain will reject any inputs from the 2MB block, since that block is illegal.

satoshis from this block can be used to split the bitcoins, even 1 satoshi input will work. Any tx that includes such a "tainted" input will only work on the 2MB chain.

Now toss in a vendor that accepts 2MB and send them a "contaminated" output, ie. will be accepted by 2MB chain, but not 1MB chain. This vendor (likely an exchange) accepts it and you get credit for it, maybe even withdraw and get back a pristine bitcoin that can be used again!

"So what?" you say. Well, the key is that you already got value for your tainted bitcoin, but the inputs that you used are still unspent on the 1MB chain! This is because your tx to the 2MB vendor was rejected as it contained a satoshi from impossible to the 1MB chain output. which means you still have your bitcoins in your 1MB wallet and can then send it to a different vendor that accepts 1MB chain, withdraw and get an un-split bitcoin and do it again.

The problem cannot be solved by the 2MB chain, it needs to be a coordinated thing with the 1MB chain and likely enough of a timegap to allow a clean separation of the two chains.

 

[freetrader]

Thanks. I'm going to read up further following your link, but it appears to me the major risk here is that some exchange accidentally (or purposefully) taints your coins. Or like you said, that an exchange received tainted coins and processed them in a way that ultimately negatively affects other users or themselves.

Having inputs that are still unspent on the other chain is exactly the goal of a clean fork, I suppose.

It looks to me like some exchanges might already be suffering problems such as these for the case of the ETH/ETC fork.

https://www.np.com/r/Bitcoin/comments/4us3r7/how_to_double_your_bitcoin_due_to_coinbase_idiocy/

NOTE: I think this thread possibly contains a lot of misinformation, but there seems to be a kernel of truth in it that is the ETH/ETC fork may not have been as clean as it ought to have been to avoid such issues.

 

[jl777]

yes. proper planning and hopefully coordination with core is needed to avoid such a mess. Hopefully they are open to an amicable divorce. The refusal to go to 2MB after all this time only creates a fee market at the expense of users and the network itself.

Nobody can be sure of the level of support, but ETC shows that there is a sizeable minority who has no voice and a classic fork would give them a way to have that voice.

 

[freetrader]

 

[freetrader]

Posting this here for those who follow this thread:

Announcement of an umbrella website for HF efforts:
https://bitco.in/forum/threads/gold-collapsing-bitcoin-up.16/page-770#post-26744

If you support the idea of a hard fork, please join the efforts if you can, in whatever way.

 

[jl777]

will it use a snapshot as of the hard fork height? if so and it follows the ETC precedent, it might trade more volume than BTC. that would be fun

 

[freetrader]

I haven't considered producing a snapshot at the fork height. Presumably you are talking snapshots in the sense mentioned in this paper:

https://arxiv.org/pdf/1501.01039v1.pdf

If you have any other concept in mind, or useful explanatory references, I'd appreciate a link.

The main benefit I can see from that paper would be a snapshot as an opportunity to clear away dust.
But I'd much rather avoid any immediate changes to the economic state by the fork code.

What are the benefits you see in taking a snapshot at fork time?

 

[jl777]

Imagine if ETH classic started with genesis and no balances...
What would the trading volume have been? The interest level?
It would basically be just a clone coin.

However, by starting off with existing balances it essentially gave everyone "free" ETC. Now there were three general types of people, the ones who supported ETC, ones against and ones who didnt care. The ones who were against sold most of their ETC right away to the ones who supported it. This churn of massive percentage of total ETC created a large trading volume, which made it a significant event.

The hashrate follows the market price so by establishing a market price, the hashrate will follow and since it is growing from zero, it has a positive trend, lower diff than market price warrants (2016 blocks diff adjust). which means it is very profitable for miners, which means more miners, which makes it more real, which boosts its price,....

So a positive feedback loop was created. I believe this can be recreated with BTC classic. Giveaway BTCC to all existing BTC holders in proportion, even the dust to minimize any code changes needed. This will recreate the ETC/ETH market conditions, ie. the core supporters will dump, classic supporters will buy. Massive volumes as long as you can get listed on any major exchange.

If you require a currently illegal transaction type for all post-fork transactions, I think that would eliminate any replay attacks and not require any cooperation from core. Another approach is to change the SIGHASH code so that all signatures for core are invalid in classic and vice versa, ie |= 0x20. Would be good to get gavin's feedback on these things to minimize the backward compatibility issues. I dont think there is a lot of infrastructure that is checking for specific SIGHASH types in the sigs.

Once we can make a fork that is immune from replay attack and recreate the market dynamics and sign up a major exchange, then the market can choose between an open development process that classic has vs. the <insert your phrase for the existing bitcoin development process>.

I would like to integrate iguana into a future version of the BTCC so that can be on the roadmap. We already have some html/js GUI that talks to existing bitcoin rpc, so that can be integrated sooner rather than later and I am working to get iguana into an easy to integrate lib with either localhost entrypoints or direct function calls.

Will it be LTC marketcap? Will it be 25% of BTC? Only one way to find out!

I say fork away.

James

We also need to provide a splitting tool, so anybody with pre-fork BTC can safely and easily split it into oldBTC and newBTC

 

[freetrader]

@jl777: what you have described is, imo, already covered by the plans I made for my fork. My intention for the transaction change is to simply use different nVersion numbers after the fork has triggered. That's always struck me as the simple way to do this, since nVersion should be covered by all the signature types. However there may be some niggles to watch out for, and I welcome any input - I've been discussing this a little already on this thread.

W.r.t the snapshot concept, I still fail to see the full implications of it, perhaps, and how it would bring significant benefits over what I have in mind already, which is to just fork off the blockchain (and separate from the existing p2p network) at a certain point without a formal snapshot of some kind.

 

[jl777]

65GB of space savings, but depending on the timeframes might not be enough time to start from a set of balances.other than that the effect is the same as what you proposed, but some sort of dust removal can also be achieved, but probably best not to do that as otherwise valid tx would then fail.

so I guess space savings is the only advantage

 

[freetrader]

Vitalik commenting on splitting:

 

[jl777]

If someone can confirm that existing bitcoind will reject a SIGHASH type of 0x21, then by making the classic require SIGHASH_CLASSICBIT (0x20) to be set, that will make new transactions beyond the forkheight invalid on existing bitcoind and existing bitcoind transactions invalid on the new network.

with a different network magic for each hardfork, the network level wont be having to deal with a lot of invalid packets and any and all fork specific characteristics can be linked to a specific network magic

So what would be needed for a hardfork is the hardfork height, SIGHASH bit, network magic and GUI text changes, with default port changes for convenient interop

If 3 bits of the SIGHASH type can be allocated, then up to 7 hardfork variants can be supported. That seems enough to me.

 

[Tsontar]

We also need to provide a splitting tool, so anybody with pre-fork BTC can safely and easily split it into oldBTC and newBTC

We need a couple of wallets to make it totally transparent and intuitive.

 

[Richy_T]

Any signs of an exchange getting on-board? If not, would it be an idea to create one? (Even if it were to be run by others)

 

[freetrader]

Do you think decentralized (bitsquare) wouldn't be enough to give the initial impetus?

I'm not saying any exchange has expressed interest, but they supported ETC pretty rapidly...

 

[Richy_T]

I think even only one exchange onboard would give an avenue for price discovery. None at all would be a difficult situation though.
[doublepost=1471289612][/doublepost]It's outside the scope of this but it would be interesting to have exchange capability built into the protocol itself. That's more the realm of smart contracts though (perhaps with a simpler, safer contract language). Possibly Ethereum should have looked at starting off with small stuff like that instead of jumping in at the deep end.