Bitcoin Forum
December 05, 2016, 04:29:22 AM *
News: To be able to use the next phase of the beta forum software, please ensure that your email address is correct/functional.
 
   Home   Help Search Donate Login Register  
Pages: « 1 2 [3]  All
  Print  
Author Topic: Unfreezable blockchain  (Read 4360 times)
Maged
Legendary
*
Offline Offline

Activity: 1260


View Profile
January 14, 2012, 01:26:34 AM
 #41

If you aren't preserving the proof-of-work, then what are you preserving?

I was just saying that either we preserve conflicting blocks like this:

So, would there be an issue with having otherwise valid blocks referencing additional parents considered as a valid proof-of-work if one or more of their additional parents are invalid? I'd have to think through that...

Or we don't link them like this:

Thus, the thing that miners should do in this situation is, until they believe that they have enough orphans stored up, don't have them link with the other orphans. Make them all have completely different transactions. Then, when you're ready to take back the chain, merge them all in a single block.

But for the latter to be possible, miners would need to be able to keep unmerged blocks days/weeks behind in the chain.
Sorry, I'm still not understanding this. Even if I did, I fear that it'd make my head hurt...

I also just realized something. This chain-strengthening system is a little too powerful, and it took that example about "soft limits" for me to see it. Anything that can be "gracefully upgraded" today on Bitcoin by making the blockchain more restrictive in some way would be consumed by this, causing a chain fork. The people who upgrade would be fine, but the people who don't - miners and users alike - could be easily scammed because the upgraded chain is mergeable to them, but the reverse isn't true. They'll always have the longer chain.

That's true. But, is it really that big of a problem? Have such protocol restrictions been made so far?

I think I'd trade the benefit of not "fearing" a chain freeze over this restriction... That's actually the only >50% attack I think we should worry about, the for-profit double-spend isn't nearly as dangerous.
That's really the big philosophical question, isn't it? There's no right answer to it.

Thus, we're forced into the trust model. If we want the network to be upgradable, we'd have to allow certain people to hold a kill switch (it'd likely be something that several pre-defined trusted people would have to sign) that would revert the old clients back to the old rules for calculating total PoW. Luckily, when you really think about it, even if someone fires off this kill switch with malicious intent, they'd still require over 50% of the network's hashing power to cause any damage.

No, that sounds bad... even if it isn't dangerous, I don't think it would be received well.
I know, but I can't think of any other way to do it...

I don't think it is such of a drawback to have every "chain rules change" being a backward incompatible change (specially when you compare with the potential benefits of what's being discussed here). These changes would need to be scheduled months in advance, intensively communicated to the main pool operators, developers of p2p pools etc.
Would your opinion about this change if I were to tell you that this very change that we're describing is, itself, one of those backwards compatible changes? It could be implemented in Bitcoin today with just 50% miner support. Do we want to force such innovation to wait until the next backward incompatible change?
Such a thing will inevitably have to happen for the block size limit one day anyway. We should be prepared for more backward incompatible changes, if they are really needed.
Which is a blessing and a curse. On the plus side, Satoshi left us the perfect reason to go back and fix our mistakes. If PayToScriptHash ends up being something we regret, we can undo it then.

On the downside, we will wait as long as possible before we do such changes. You need to have a VERY, VERY good reason to do a backward incompatible change. The system in this very thread would not qualify if it required that. Also, did you know that Bitcoin calculates the next difficulty level incorrectly, and that it can be exploited to reduce the difficulty? Did you also know that it isn't scheduled to be fixed until we hit the block size limit? That's why I consider this to be a difficult issue.

We really only have two logical choices here:
1) We shelve this idea for at least 20 years so that Bitcoin can finish maturing.
2) We add a kill switch that allows the network the benefit of this additional protection, but without the downside of making everything a backwards incompatible change. If necessary, the kill switch itself could have a permanent kill switch that requires fewer people to activate.

Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1480912162
Hero Member
*
Offline Offline

Posts: 1480912162

View Profile Personal Message (Offline)

Ignore
1480912162
Reply with quote  #2

1480912162
Report to moderator
EhVedadoOAnonimato
Hero Member
*****
Offline Offline

Activity: 616



View Profile
January 14, 2012, 08:57:02 PM
 #42

Would your opinion about this change if I were to tell you that this very change that we're describing is, itself, one of those backwards compatible changes? It could be implemented in Bitcoin today with just 50% miner support.

Well, it'd require a few hacks to be backward compatible, wouldn't it? You'd need to use transactions somehow to express the links between blocks, instead of the header themselves... And miners which do not update would not know how to identify and react to the attack, they would not recognize the strong PoW of the tree in comparison to the attacker's chain etc. It would be complicated and messy.

I wasn't hoping such change to be done in bitcoin in a backward compatible way, actually.

Also, did you know that Bitcoin calculates the next difficulty level incorrectly, and that it can be exploited to reduce the difficulty? Did you also know that it isn't scheduled to be fixed until we hit the block size limit? That's why I consider this to be a difficult issue.

I didn't know about this. How serious is this bug? Would a serious deviation from the correct value be possible?

We really only have two logical choices here:
1) We shelve this idea for at least 20 years so that Bitcoin can finish maturing.
2) We add a kill switch that allows the network the benefit of this additional protection, but without the downside of making everything a backwards incompatible change. If necessary, the kill switch itself could have a permanent kill switch that requires fewer people to activate.

May I add a third?
3) "We"* try to make an alternative coin which implements this from scratch (links on the header, clean), and with it we may even test other things like fast confirmations for example. We make this alt coin support merged mining. We tell Luke-Jr about the new coin, and see how well it resists his attack. If it survives, it will be living proof that this works, and that cryptocurrencies need no more to fear the "freezing attack". From this point on, bitcoin developers may or may not add the technique to bitcoin. I'm sure that if such an attack ever happens on bitcoin, and there's an alt coin out there which has proven to be immune against it, then people would react quite quickly to adapt bitcoin to this scheme. Actually, I'd expect "emergency patches" to be already written and tested, only waiting to be included.

* I quoted "We" because I don't believe I'm qualified for the task.
Maged
Legendary
*
Offline Offline

Activity: 1260


View Profile
January 16, 2012, 01:17:10 AM
 #43

Would your opinion about this change if I were to tell you that this very change that we're describing is, itself, one of those backwards compatible changes? It could be implemented in Bitcoin today with just 50% miner support.

Well, it'd require a few hacks to be backward compatible, wouldn't it? You'd need to use transactions somehow to express the links between blocks, instead of the header themselves... And miners which do not update would not know how to identify and react to the attack, they would not recognize the strong PoW of the tree in comparison to the attacker's chain etc. It would be complicated and messy.
It would be no more of a hack than merged mining. The data could be stored in the coinbase.

Also, did you know that Bitcoin calculates the next difficulty level incorrectly, and that it can be exploited to reduce the difficulty? Did you also know that it isn't scheduled to be fixed until we hit the block size limit? That's why I consider this to be a difficult issue.

I didn't know about this. How serious is this bug? Would a serious deviation from the correct value be possible?
Not too serious. Someone can just make the 2016 blocks appear to have taken up to two hours less than they actually did.

We really only have two logical choices here:
1) We shelve this idea for at least 20 years so that Bitcoin can finish maturing.
2) We add a kill switch that allows the network the benefit of this additional protection, but without the downside of making everything a backwards incompatible change. If necessary, the kill switch itself could have a permanent kill switch that requires fewer people to activate.

May I add a third?
3) "We"* try to make an alternative coin which implements this from scratch (links on the header, clean), and with it we may even test other things like fast confirmations for example. We make this alt coin support merged mining. We tell Luke-Jr about the new coin, and see how well it resists his attack. If it survives, it will be living proof that this works, and that cryptocurrencies need no more to fear the "freezing attack". From this point on, bitcoin developers may or may not add the technique to bitcoin. I'm sure that if such an attack ever happens on bitcoin, and there's an alt coin out there which has proven to be immune against it, then people would react quite quickly to adapt bitcoin to this scheme. Actually, I'd expect "emergency patches" to be already written and tested, only waiting to be included.

* I quoted "We" because I don't believe I'm qualified for the task.
Oh, I fully intended this to be used by an alt coin, at least at first. It'd be cooler if it could be added to Bitcoin someday, though, especially when we have a colony on Mars. That's what I feel is the real endgame for this proposal.

EhVedadoOAnonimato
Hero Member
*****
Offline Offline

Activity: 616



View Profile
January 16, 2012, 08:34:34 AM
 #44

It'd be cooler if it could be added to Bitcoin someday, though, especially when we have a colony on Mars. That's what I feel is the real endgame for this proposal.

LOL, you don't need to get that "science-fiction" to imagine a good use case for this.
Imagine the Chinese government decides to get offensive against bitcoin. First, they would likely have the resources to try to freeze it. But even if they just use their great firewall, they could try to isolate Chinese miners from those outside. Granted, there will always be a few clever hackers able to get through, but if for a couple hours the great firewall cuts all links with the outside world, such a system could prove very useful to allow things to keep going on each side of the wall and then get everything merged whenever someone finds a hole.
Maged
Legendary
*
Offline Offline

Activity: 1260


View Profile
January 16, 2012, 04:29:00 PM
 #45

It'd be cooler if it could be added to Bitcoin someday, though, especially when we have a colony on Mars. That's what I feel is the real endgame for this proposal.

LOL, you don't need to get that "science-fiction" to imagine a good use case for this.
Imagine the Chinese government decides to get offensive against bitcoin. First, they would likely have the resources to try to freeze it. But even if they just use their great firewall, they could try to isolate Chinese miners from those outside. Granted, there will always be a few clever hackers able to get through, but if for a couple hours the great firewall cuts all links with the outside world, such a system could prove very useful to allow things to keep going on each side of the wall and then get everything merged whenever someone finds a hole.
Unless you can think of a good double-spend protection system for both sides of the split, that won't work. The only one that I can think of only works the following is true:

1) You know the maximum latency between you and the true tip of the chain.
2) (optional if you want faster transaction processing) You know which side of the chain "owns" each input.

Again, I haven't thought this through completely, so I'm not ready to publish it. But, that's the gist of how I'd solve the Mars problem.

EhVedadoOAnonimato
Hero Member
*****
Offline Offline

Activity: 616



View Profile
January 16, 2012, 07:24:07 PM
 #46

Imagine the Chinese government decides to get offensive against bitcoin. First, they would likely have the resources to try to freeze it. But even if they just use their great firewall, they could try to isolate Chinese miners from those outside. Granted, there will always be a few clever hackers able to get through, but if for a couple hours the great firewall cuts all links with the outside world, such a system could prove very useful to allow things to keep going on each side of the wall and then get everything merged whenever someone finds a hole.
Unless you can think of a good double-spend protection system for both sides of the split, that won't work.

True. I was imagining that, as nothing would pass through, that would be valid for transactions as well. But I naively forgot that the Chinese government itself could be the one sending the double-spends to both sides. Plus, the bitcoin protocol isn't the only way transactions can travel.
Pages: « 1 2 [3]  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!