Bitcoin Forum

I could find none. Only political whimsical yadda yadda.
In order to exclude a cognitive BIAS, I hereby ask to be pointed to $SUBJECT.



Rico

anyone? no?

https://medium.com/the-publius-letters/segregated-witness-a-fork-too-far-87d6e57a4179#.mcr2xiqez


https://www.reddit.com/r/btc/comments/5vbofp/initially_i_liked_segwit_but_then_i_learned/

That first link looks very good and the sort of thing the OP is looking for. My quick take on it is that the risks he raises look manageable and defenses against the manipulation he illustrates can be implemented (such as Bob's client monitoring for just this sort of activtiy and giving warning dialogues if it sees anything suspicious).

The second link doesn't raise actual issues so much as rave about how "dangerous" Core's approach is - a complaint that appears ludicrous in light of yesterday's BU troubles. It wastes a lot of time on premature triumphalism and childish cheerleading, the sort that makes r/btc look like a propaganda effort rather than a serious discussion forum. It would also be much more readable if the author had stopped repeatedly declaring how "open minded" he is for first liking and then disliking SW.  ::)

My biggest objection is that by splitting the transaction it makes it very difficult to have meaninful block size increases.

If you do not increase the max block size, it makes it possible to spam the blockchain with traditional transactions so that not even SegWit transactions make it in.

But if you do increase the max block size to make that harder, then it is possible to spam the blockchain with SegWit transactions that are really heavy on the witness data causing blocks that take a lot more space. For example with the current 1MB blocks you could craft SegWit transactions that result in 4 MB of actual data, which is far greater than what most people are currently proposing.

If instead of segregating the witness data to become part of the coinbase, you use something like FlexTrans - then when you set a max block size, that is the actual max block size whether the transactions use FlexTrans or not.

Even if SegWit were technically perfect, it doesn't actually provide a meaningful scaling solution.  The notion that SegWit is for scaling is totally absurd.  That is the technical evidence against.  

What SegWit does is provide a means for Lightning to work with the blockchain.  Some patches for malebility.  Lightning - a very stupid scaling solution that is proprietary will radically change the network in favor of private ownership of a bulk of the traffic.  Blockstream.  Even if SegWit were without technical fault, it is not, its true function is to enable Lightning.  

Bitcoin/Lightning strategy omits a HUGE class of transactions.  Those transactions which are small in value and one-time only.  'Payment channels' are great when you want to do many microtransactions.  But Lightning does work well for those situations where you want to do a one time small payment - like buy a cup of coffee.  Then you are screwed and the network fails.  

Don't worry.  Many wonderful off chain solutions will come.  However, they should not come because one private company is intentionally limiting the transaction capacity so they can sell their private off chain scaling solution.  


The technical evidence against SegWit - it doesn't actually provide any appreciable scaling solution.  It is merely a needed patch for Lightning to work.  

One could do that using multi sig transactions today, and no-one does. It's an attack that costs alot of money compared to it's effectiveness, hence it doesn't happen in practice. Filling every single block with nothing but attack transactions would cost a fortune, the attacker would push the Bitcoin price to the moon all by themselves in order to pay the fees to do it. Only the ultra rich could do it, and it seems they're not interested to throw that amount of money away.


That attack is possible now. The ratio of signature to tx-data can be expanded massively in a regular 1MB block, DoS'ing block space from people who wnat to use it benignly. Segregating the signatures doesn't alter an attackers ability to do this at all. It falls into the same category as the attack in your first paragraph, far too expensive to do, except for the ultra rich.

You should try to understand Segwit better before you make such ill-considered assessments.


There are huge problems with FlexTrans that you've demonstrated already you prefer to ignore. Let's not forget that FlexTrans was designed by the same incompetent who gave us xThin block propagation, which carried not 1 but 2 fatal bugs, 1 of which was recently exploited to BU's demise.

Snake oil can be freely sold in the Marketplace sub-board, I hope your business goes well  ::)

No, not really.  You simply have to be a "customer" to a local LN bank ; that is, having opened a LN channel with them, under their commercial conditions, and send your transactions through them each time you want to spend your coins.   Like normal banking.

Are you referring to the assert bug? The FlexTrans developer had nothing to do with that.

FlexTrans is technology from BitCoin Classic, not Bitcoin Unlimited.

Both FlexTrans and xThin were written by the same member of the Classic team, that's correct. And in no way does that contradict what I said at all, you're confused

Literally all experts in the field are advocating for segwit and lightning network, the ones that don't always have BU-ties.

I would respect that someone finds segwit unsafe for some reason, but I can't when everytime someone claims segwit will be the end of the world, they are on the other hand supporting BUchina which is insane.

OP, maybe you are wasting your time. Segwit has been out for 6+ months and the masses aren't buying it - it's around 99.9% certain that it will not be adopted before the deadline. Even if repackaged with a blocksize increase compromise it's likely Segwit won't get adopted. In one sentence: It's just too radical a departure from Satoshi's orginal vision, gives too much clout to Blockstream, and creates too much technical debt.

I think he's just trying to prove a point. It's a political debate rather than a technological one. People are just dick measuring and want to make sure they win no matter what. It's been years. Just hard fork it ffs.

I think it is the "immutability consensus mechanism" at work: the protocol remains what it is, because people cannot agree upon a change that would give advantages to some, and disadvantages to others.  That's why the block chain is not unwound (it would give advantages to some, and disadvantages to others) ; it is why the block halving happens (advantages to coin holders, disadvantages to miners)... and why the number of transactions per second is not modified (advantages to users, disadvantage to fee collectors).

Of course, this appears like "political battles" between those that have advantages and disadvantages for each possible modification, but this is exactly what maintains status quo (immutability consensus).

Are you referring to this (http://www.mail-archive.com/bitcoin-dev@lists.linuxfoundation.org/msg04309.html)? As far as I understand, that are simple bugs which with some testing could be surely resolved. If there are fundamental problems with FlexTrans please share links to them.

(I am neutral, for now, I prefer Segwit; but if its easiear to achieve consensus with miners for FlexTrans as a malleability/quadratic hashing fix, I would have no problem with it).

Ad hominem won't help in finding a solution. If we stay on this discussion level, in one year we'll have still no LN (/Thunder/Rootstock etc.) neither a blocksize increase - and sub-500 Bitcoin prices again (and very probably, some kind of fork).

I very much think that this will be the case, but bitcoin's price will not be affected negatively by that.  Bitcoin's price is not determined by people doing on chain transactions, but by people gambling on exchanges, and that doesn't need a solution for on chain transactions.  You will never have problems getting your coins on or from an exchange, because these exchanges will have bought chain room with their preferred mining pools.  You simply won't be able to do anything else.  At that point, bitcoin became a reserve currency which is in any case its fate.  But it can hold a very high price.

https://bitcointalk.org/index.php?topic=1822954.msg18177918#msg18177918


There's nothing slanderous about stating facts. And what I stated was a fact; the programmer who devised FlexTrans and xThin produced poor designs with large quantities of bugs that are sufficiently bad that they span the broad codebase in the case of FlexTrans i.e. bugs that are essential aspects of the actual overall design, and so cannot be fixed without using a different design altogether.


designing incompetently is incompetent. Pointing that out is not impugning someone's reputation, it's an important part of what their true reputation actually is. But sure, keep shrieking about ad hominem attacks when you simply don't like the facts the other party presents, go right ahead

OK,  
Boyo you asked for it.  :D

https://bitcointalk.org/index.php?topic=1807251.msg18100392#msg18100392
https://bitcointalk.org/index.php?topic=1813712.msg18105140#msg18105140
https://bitcointalk.org/index.php?topic=1813712.msg18105140#msg18105140
https://bitcointalk.org/index.php?topic=1816236.msg18094064#msg18094064

Cliff Notes, for those not liking to read.
Segwit allows LN to steal transaction fees from the Onchain Miners.
(Common lie is that once LN is activated Miners will make more money.)
So lets test that,
If I tell you , you will make more money if you give me your Paycheck every 2 weeks , are you dumb enough to believe it?
If so , I can PM you a PO Box , where you can send me your paycheck.  :D
(that is why segwit is really deadwit.)  ;)

 8)

And now, the question is: why should one pay miners ?  Answer: in a PoW system, you HAVE TO pay miners a HUGE AMOUNT of money, because the security of the system depends on that ; but also, in a PoW system, it are the miners that have the vote over the protocol.  THIS is why segwit will not be activated: miners don't want this lucrative market be crippled.  And why they give enough lip service to BU or whatever alternative: not because they want that activated, but to stop segwit from being activated. 

However, there's no way in which a "banking layer" can be avoided on top of a crypto.  The only thing is, a crypto with a banking layer on top (like LN) has absolutely no advantage over a fiat banking system.  So the problem is simply that: a crypto with a banking layer is useless.  LN or something else.

In a PoW system,if a fee market is in place, nothing is going to change that, because it is now immutably a part of the consensus.

This is the worst argument against Segwit I've seen yet. The whole point of miner fees is to pay them for the work they do to confirm ON-CHAIN transactions. Why on earth should anyone pay them when they are not doing any work, for offchain TX???

The blockchain will by necessity remain the backbone of bitcoin in a segwit/LN ecosystem. It just won't be under the monopoly rule of the miners, giving people more options. That's why the miners are fighting it.

So let's repeat the question the OP stated: Where are the technical objections to Segwit? It's looking now like there is very little.

Thanks for the
https://medium.com/the-publius-letters/segregated-witness-a-fork-too-far-87d6e57a4179
it is very thorough in describing SW.

In fact so thorough, that for the "Problems with SW" only about 30% of the article remain.
Naturally I had a deeper look at these

as for 3.1 SW creates a financial incentive for bloating witness data


Unfortunately it's not elaborated what this financial incentive is or how it comes into play. Maybe I'm overlooking something evident, but as is in the article it is a simple statement without any proof or even explanation.

as for 3.2 SW fails to sufficiently address the problems it intends to solve

This section contains a very weak, almost no-argument against SW, namely

i.e. "The good properties of SW will not be available to non-SW UXTOs", which in itself is a homage to SW and similar to the argument like

"But Bitcoin will not fix the USD..."

On the other hand, it contains a very strong argument - the strongest I've seen so far - against a new UXTO class:


I followed the link to the reddit discussion and I didn't believe what I've read. If there are really people in the Bitcoin community who want to put an expiration date to Bitcoins, and some UXTO discrimination should help these f*cktards to achieve their wet fantasies. Then I have to agree: We cannot have that.

It doesn't seem like a genuine SW-UXTO problem though, more than SW-UXTO being a vehicle for discrimination according to hypothetical future bad politics. This seems like killing your newborn, because it might become Hitler.

=> Again, no technical argument, merely a political. But it surely scared the shit out of me.


as for 3.3 SW places complex requirements on developers to comply while failing to guarantee any benefits

It essentially says: "There is code change involved and that's dangerous, SW does not provide enough benefit to justify the risk of bugs in the new code."

Well - the question is, if BU or other proposals do provide enough benefit, because as is, this argument could be interpreted as "Never change a running system".

as for 3.4 Economic distortions and price fixing

purely non-technical and may be titled "I do not like soft-forks"

as for 3.5 Soft fork risks

reiteration of "I do not like soft-forks"

as for 3.6 Once activated, SW cannot be undone and must remain in Bitcoin codebase forever.

While not providing evidence for the claim there could be no roll-back, I give him that: Not having a plan B (roll-back) for the case of some catastrophic sideways fuggup is a bad thing. In general.


Executive Summary:

SW may give zealots the possibility to discriminate between SW-UXTOs and non-SW-UXTOs (a.k.a. our old good UXTOs) and as such might help foster some "interesting" novel Bitcoin policies, like destroying old coins etc.

Well - theoretically - it might. But I believe this is also a non-technical issue and more an educational one. Should such an issue arise, the bitcoin community should still be "man enough" to take a stick and beat the shit out of such zealots until they come to reason.

Executive executive Summary:

SW is like a knife: It can be useful in the kitchen, or you might slash your wrist with it. Should we ban knives?


Rico

Rico, good post.  i may look into some of this stuff.

almost feels like Nancy Pelosi saying "we need to pass obamacare so we can find out whats in the bill"

this thing is huge and messy.

and people think its a good idea to activate this BEFORE we simply increase the blocksize?  why??

That section also stood out to me, because I wasn't aware of this issue, I know that UTXO bloat is a big concern for everybody.  

I suppose the Core devs mean that, assuming Segwit activation plus some percentage, the old UTXO set SHOULD be near empty and could be retired?

To me this shows Core's level of arrogance in assuming that everyone would be running their code...
 

Segwit changed 5,000 lines of code in bitcoin core, and requires refactoring thousands of lines of code in exchange, wallet, and utility software. Statistically guaranteeing 100+ bugs.


No one is banning knives.

This oddly-shaped Segwit knife that requires everyone to build new knife racks is being put back in its packaging and returned to the vendor. We've still got a ton of cutting to do, and there is a Unlimited knife handy that claims to enable us to do that cutting. Many are using it simply because it's an alternative.

It sure would be nice to just have a knife that works and everyone can use.

There must be a typo there...For a second it looked like you said 50,000 lines of code.

Sorry it's 5.305 lines added, 571 lines removed, for a total of 5,876 changed lines, in EIGHTY files. https://github.com/bitcoin/bitcoin/pull/8149/files (https://github.com/bitcoin/bitcoin/pull/8149/files)

Industry average being 15-50 defects per thousand lines of code (source: Code Complete), would yield  87 - 290 bugs in Segwit. Most would be minor, but a few... Not to mention the implementation bugs in 3rd party wallet, exchange, and utility code. A nightmare. Or, maybe job security for a bunch of coders?

You forgot to subtract all the LoC that are adapted or new testing code :) They form most of the changes, i.e. the Bitcoin devs are being as assiduously diligent as possible.

You also forgot to mention how many bugs have been found and fixed (having not caused any incident, as you'd be shouting about it from the roof of your tower block) on the Bitcoin Testnet, which has been running live Segwit for over 6 months :)

That's... not how it works. I think that the core developers have been quite responsible, a lot of unit tests have been written for the code changes.

litecoin has been running for 6 years..
but i dare you to start throwing litecoin rules and keys into bitcoin on activation day.

there is a big bug known about since last year. instead of fixing it, they are doing work arounds.
such as the upstream downstream. not relaying segwit unconfirmed tx's to native nodes, banning native nodes from being upstream and preventing native blocks from being produced ontop of segwit...

yet you will remain adamant thats is all "compatible" LOL

I didn't say the devs weren't responsible. 15-50 defects per KLOC is a software industry average. Add in one defect per thousand lines for each covert NSA/CIA employee at the company. /s

Test code can have bugs in it, and when it does, they can obscure bugs in the main code.

Unit tests often miss higher-level bugs that require live interaction, timing, or edge case scenarios. Like, say protocol changes on a live running network with thousands of contentious and/or malicious actors?

Bugs in Segwit have been found and fixed. But you can never really certify code bug-free. That's why it's best to keep changes as simple as possible and keep the total lines changed to a minimum.  

Nobody shouting from any towers here, Carlton. Unless you are?

All software has bugs. The questions are: has anyone found them, what are their consequences, and how easily can they be fixed?

Sometimes the bug is in the dev's head - there seems to be an innate desire of the coder to over-complicate matters... known colloquially as "Error occurred between keyboard and seat".

Surely SegWit provides a lot more advantages than just a solution to the problems of transaction delays. SegWit increases the potential intelligence that can be built into transactions.

I understand the problems, but I still believe that it would be better to try to find ways to decrease the block generation time to keep Bitcoin fast and agile, rather than increasing the blocksize so that it is about as fast as a McDonalds customer.

In my experience, asynchronous issues that can occur on a live system are very difficult to replicate in a test environment. They can be very difficult to diagnose and fix.

The Segwit soft fork has the potential for a TON of these types of issues. As you say, they're very time-consuming to find and fix. At this point it's likely that Segwit will not move forward, and development will probably need to shift in some way. If Core tries to ram Segwit through with a UASF (User activated soft fork), the Bitcoin Unlimited folks will likely try to hard fork the blockchain. In this case there could be as many as 5 different bitcoin implementations fighting for the highest adoption for consensus. A crazy scenario, likely to be very contentious. If this does come to pass, it will forever be part of software development history! And you'd better believe that there will be some hard lessons on why you must test your code extensively and keep it simple...

But what is the alternative, to sit and do nothing beyond hoping endless blocksize increases can cope somehow with user adoption rates? I suppose an altcoin can be cajoled into doing SW first, but that should have been done a year ago if really needed.

The dilemma Bitcoin is now in runs as follows: Cryptocurrency is rapidly innovating, and coins that lack the feature set and capabilities of newer coins are likely to die out no matter how popular they once were. (That's why we no longer see Model T's on the road.) On the flip side, technical issues or exploits associated with changes can kill a coin real fast.

Core and Bitcoin Unlimited now exemplify the dichotomy in how Bitcoin approaches these two risks. On the one hand we have the "Go-too-slow" approach of Core, which has been patiently waiting for miners to adopt SW/LN while the rest of the crypto space keeps advancing. On the other hand we have the buggy development of hard-charging Bitcoin Unlimited and their "You have to fork it to find out what's in it" approach handing over protocol power to the miners in an unprecedented and risky manner.

You got it.  So a coin should remain itself, and when it is outdated, people should switch to other coins.  Simple as that.  The coin remaining itself can maybe still maintain a niche application.  And most probably what will happen in the long run.

I am also looking for evidence against SegWit but am having problems finding something substantial. Most of it is political, not technical...

What is the status of the "lets do nothing camp"?

On https://coin.dance/blocks#hashrate I noticed a few pools signal neither (SegWit/BU):

https://pool.btc.com/
https://bixin.com/
http://solo.ckpool.org/
http://btc.top/
https://xbtc.exx.com/

to name a few.

Do they even know all this debate is going on? :D

I guess you didn't even read this thread or the links posted in it? I count the word "code" 36 times on this page alone. If the thread still isnt technical enough for you after you're actually read it (and the articles linked), read the code. It's an attempt to rewrite the signature layer of bitcoin, and these changes are supposed to propagate on the live network without breaking anything.

Also, you implyiing that technical arguments are more "substantial" than political ones?

They already tried to ram Segwit down Litecoin users' throats:

https://www.litecoinpool.org/pools (https://www.litecoinpool.org/pools)
How much of the hashing power is signaling SegWit support? NEW!
    About 540 GH/s, or 22.0% of the network (110 out of the last 500 blocks).

Total fail. No one wants this!


I agree with this assessment. However, bitcoin has always had flaws other than the artificially constrained blocksize and the resultant high fees and slow confirmations. Difficulty re-targeting is broken. The currency emission rate is not optimal, etc.. But Bitcoin has the largest market cap and a huge lead in adoption, credibility, and investment.   That said, its first mover advantage is fading as we speak.



You present a false dichotomy - firstly they are not opposites, secondly they are not the only options on the table. Segwit is a wonky code fork that will be forgotten in 2 years. BU is a wacky attempt to challenge Core's status quo, and will also likely be forgotten in two years. Hard fork to 2MB blocks with no other changes from 0.12 is still possible at any time. A bitcoin hard fork was done in 2014 without issue.

Wise words.  Agree with everything in this post.
(apart from the hard fork in 2014 ?  Hard fork in the block chain protocol ??)

Segwit is good and I can say that it is much better than HF since HF is a danger to bitcoin. But even if segwit is safe there will be problems that will come later on. But let us just watch how segwit will perform since it is already  clear that segwit will use Lightning Network. As of this time it is hard to say if there are serious advantages.

Yes there was an emergency hard fork in March 2013 (not 2014, I stand corrected). 60% of mining hashpower was building on a broken blockchain due to an incompatibility introduced by the switch to LevelDB. The blockchain was rolled back and nodes quickly downgraded to the previous 0.7 version.
 
https://github.com/bitcoin/bips/blob/master/bip-0050.mediawiki (https://github.com/bitcoin/bips/blob/master/bip-0050.mediawiki)

New code with new rules for validation were rolled out on an emergency basis. Network and pool operators worked together and the issue was resolved in 3 days.


Of course devs don't like to admit that hard forking can work just fine, even on an emergency basis with no warning. They will tell you that "the network is too big now", "there are malicious actors", "you can't get consensus with this many people now", etc. And yet they claim that soft forking is "completely safe"...

Some have argued that every time a block gets orphaned there is a hard fork. Semantics.

It didn't occur to me that that was a block chain protocol hard fork, in the sense that the blocks made afterwards were incompatible with the valid protocol before (definition of a hard fork) ?

(and no, orphaned blocks are not a "hard fork" :) )

That said, what happened just before WAS strictly speaking a hard fork, when the block size limit of 500 KB was raised !  Funny how that was possible back then when it was a purely technical parameter, and causes so much troubles right now !

HAHA i got to the 1st line in the 1st link and it said, and i quote " instead, bitcoin unlimited is safe and simple" ... lol i gave up reading after that. The OP asked for no Bias. :)

All they have to do is Hard Code a Checkpoint into the Client code that corresponds to a Block Number.
No Reorganization can occur before that checkpoint , no matter even if you controlled 100% of the mining.

Here is a link to what happened on March 13th.
https://bitcoinmagazine.com/articles/bitcoin-network-shaken-by-blockchain-fork-1363144448/

 8)

FYI:
What happen on March 13 was more of a history rewrite by overwriting the shorter chain, by a collusion of ~70% of the miners (requested by BTC core Devs.)

But you start from the idea that people are using a centrally designed code.  The idea of a decentralized system is that there are hundreds or thousands of different client codes in principle, in other words, that ideally, everybody writes his own code.

Putting a hard coded check point is a bit like thinking that one can ban certain web sites from being visited by putting a hard coded ban in the official, centralized, unique web browser software, no ?  A priori everybody can recompile his version of web browser, with is preferred check points.

It seems that people attach a lot of importance to the rules in the code, but that is because most crypto currencies are totally centralized in their coding, and only one entity is writing the code.  Core had that centralized power until recently in bitcoin, and in most other coins the "dev team" is the centralized decision force ; usually about the *protocol*.  However, if they start putting block chain check points in the code, they are also doing transaction consensus centralization.

Whether you agree of disagree with Hard coded checkpoints, they are used in BTC , LTC, and every other Altcoin.
Whether or not someone coding their own wallet disable the hard coded checkpoint is up to them.
But if the Majority of Users leave them, the network will follow the hard coded checkpoints.

 8)

FYI:
Some coins use Rolling Checkpoints, where after 12 hours no reorgs are allowed.
Some coins use checkpoint servers , that is very centralized, compared to the other ways.

Strictly theoretically, these things don't make sense in a consensus finding algorithm.  In practice, they do, because crypto is much, much much more centralized than people want to admit.  But in perfect decentralization, there's no way in which check points can be used, because once you have disagreeing check points, there's no way to come to consensus.

In fact, if there are check points, there's not even a reason to keep the block chain before that check point.  You can keep a hard-signed list of all UTXO by the software editor at that point too, as a big genesis block at that point.  A hard coded check point is in fact nothing else but a new genesis block.  No need to keep the old chain before that.

And if consensus diverged at that point, you simply have two new genesis blocks and two chains that can never merge again.

Actually you do have to keep the old chain, Checkpoint stop any reorgs before them, but they don't have the transaction data.
If you figure out a way to add a checkpoint and have it truly be the new genesis block while keeping everyone correct amount in their wallets.
Then you have something very valuable, as their would be Buyers that would pay a lot for a running genesis block technology.
It would solve the issue of blockchain bloat almost overnight.  :)

 8)

That is really not difficult on a transparent chain you know !

The miner that makes the block that is going to be the check point, simply includes also a public key of which he only has the secret key, makes a new "Genesis block" and signs it cryptographically with his secret key.  That new block is a big genesis block, with "premine UTXO" as a very big coinbase, such that the "New coin" gives coinbase coins to all previously existing UTXO.  When he has both the normal block that is going to be the checkpoint (a small, normal block that lets him compete normally with other miners, but with his public key inside) and somewhat later, he publishes his new genesis block (signed with his secret key), all nodes and miners can CHECK that he didn't cheat in making this genesis block (in other words, that all the UTXO are correctly attributed to all UTXO in the previous chain up to that point).  He will get a bigger reward in that genesis block.  The same mechanism that secures the check point, then validates the new genesis block.

From that point onward, you can forget the old chain.  Well, you can keep it a while if you want to check the validity of the genesis block for yourself. But if the check point was hard, that's in any case equivalent to accepting the chain up to that point: one can just as well accept the new genesis block.

Hup, 150 GB liberated.  

Note that this genesis block is huge.  But much smaller than the old chain.  The miner winning the "check point block" is also the sole guy being able to publish a genesis block (and a special reward for that miner) with his secret key signature.  If he makes a wrong genesis block, with his signature, he lost his "turn" and the next block is then the "check point" block.  So in fact, from the check point onward, all blocks have public keys of the corresponding miners.  The miner publishing the correct genesis block that was signed with the earliest key is the winner.  It can take a few block periods to publish this block because it is big, but there is no hurry. Normally, it will be the first miner if he's not an idiot publishing a wrong genesis block.

When you say "block chain protocol hard fork", you likely mean "bitcoin consensus protocol changes". Which is exactly what happened in 2013, on an emergency basis. The errant code (due to levelDB vs. BerkeleyDB locking differences) validated malformed transactions and blocks, using 60% of the global hashpower. The 60% was overwhelming the correct blocks, and people noticed a large deviation in broadcasted blocks.  As a fix, the blockchain was voluntarily rolled back in time by 12 hours, new blocks were built on top of it with a patched miner, and a ton of broken blocks were discarded and invalidated. (These blocks incidentally could be considered orphaned)

Also interesting as you point out, that the block size was limited to 512K during this bugfix.

I'm interested in this topic.
How does this differ from simply launching a new coin with a monetary base that is pre-loaded with a previous currency's balance sheet?

Also, pruning works since 0.12, how is this different? I suppose that pruned nodes are not fully trusted.

My question is: was any aspect of the block chain itself modified ?  I have the impression (didn't look into the details) that this was an internal bug to core code not respecting the correct construction of BLOCKS and accepting them as valid *while in fact they weren't*.  So one just found out somewhat late that one had been building *an invalid chain*, but discarding (even late) an invalid chain is not the same thing as *modifying how a chain should be build* (THAT is a hard fork in protocol).

For instance, suppose that because of a bug in core software, the coinbase of a block jumps to 200 coins per block, and that this goes on for a month.  During this month, in fact, these blocks are simply *wrong* but are nevertheless, erroneously, accepted.  In fact, the error made a hard fork.  When the bug is *repaired*, suddenly, all these blocks are correctly seen as invalid, and the chain is seen as stalled a month ago.  So now, people can start building blocks upon the stalled, correct chain.   If that happens, I don't call it a hard fork, because the true protocol is still valid on the rebuilt chain. (while in fact it wasn't on the erroneous chain for more than a month).

the block structure and chain was fine. non of the bitcoin consensus rules were broken.

the bug was how the blocks got saved to peoples hard drives in their local databases.
people using (at the time) leveldb could save the blockchain.. but if using berekly by not upgrading they were having issues saving the blockchain because it was using up all the locks of their berkelydb as the blocks grew beyond 500k (even when consensus had 1mb limit)..

so it was not about consensus rules. but bad database issues

devs didnt peer review what would happen in such cases because.


coinbase jumping to 200 coins for a month??

well if everyone (your utopia) was running the exact same core software.. then it would go on for months.
but if nodes were diverse. then they would orphan off the block because it breaks the real consensus rule of 12.5btc right now. and so if the network was diverse enough to not have a majority running the buggy core. those blocks would get orphaned

and the pools running non core wont be making 200coin blocks. so the network wont be running for a month of 200 coins.

but in your utopia of everyone running core then yea expect more issues where after a month, those 4032 blocks of 200coins each block would eventually get orphaned and anyone making transactions during that month will see their transactions of that month disappear. causing merchants who accepted them 4032 blocks and thought they got paid, find out they no longer got paid because their customers transactions of the month no longer exist.

this is why diversity matters

They are still running the original Satoshi client from January 3, 2009.  ;D ;D ;D

Well, it is of course pruning, but with a "clean new genesis block", that can be taken as a new chain start, or as a "summary" of the previous chain.

The pruning in bitcoin is about the internal data structure of the running node, not about the distributed block chain.  I don't think the bitcoin block chain has "big pruning blocks".  You can simply chose to not download the whole of the chain if you want to, but the actual block chain is still the big and growing one.

With a new genesis block, you can simply throw away the old block chain as if it were a new coin, it is part of the block chain protocol by itself.

Note that it can be designed such that the blocks that followed upon the "check point block" are also the first valid blocks that follow upon the genesis block (same "previous hash" : the genesis block is defined that way), so that in fact you can choose to continue using the old chain, or you can choose starting from the new genesis block.

You could program such an official "check point" every year, or every week.   If you do it every week, you have a kind of "account updates", and the actual chain never needs to be longer than a week.  Although, for your comfort, you can hold a few weeks' worth of block chain.

The nice thing about the *synchronized* version of pruning (every week, at a specific block) is that everybody is using the same "account basis". 

Whether it has to be every week or every year depends on the ratio between the number of transactions per week, and the number of accounts "live". 

Hell, you could even put a lower limit on account contents, and clean out "dust".  It would mean that accounts containing less than a certain amount (say, less than the minimum fee) are NOT taken in the new genesis block, eliminating dust and the burden that goes with it.

This is already a much more scalable system than the full block chain (it puts a somewhat bigger burden on network capacity, although there is no hurry in getting the genesis block ; you can jump a few genesis blocks if you want to).

In fact, it is a transition from a "only transactions" system to an "account" system.

That's what I thought too.  So it doesn't matter, it is internal business of core code, has nothing to do with the block chain protocol.  Someone having written his own version of bitcoin code, implementing the bitcoin rules, would already have stalled from the first bad block onwards, just to resume when core got his software in agreement with the protocol again, under the assumption that all miners are running core.


Point is, if all the miners were running that code, then there wouldn't be any other block chain around.  So all those diverse nodes wouild simply come to a halt, until the miners started making correct blocks again on the last one that was correct.  All the time they were making an erroneous block chain, no good one was around, and those diverse nodes would simply stop for that time, not finding one correct block on the network.


The POOLS, yes.  If they were not running core, they would make good blocks, but not many, because they would have very low hash rate if the majority was wasting their hash rate on erroneous blocks, and difficulty can only adjust after 2000 blocks, so there would then be a good block every few hours or so.  I made the assumption that all miners (say, the 20 of them) were running core.  


Indeed.  The joys of non-bilateral hard forks :)

What's interesting is that Gavin stated at the time:


I guess it boils down to semantics... nonetheless it's very interesting to think about what would've happened if not everybody agreed on the solution to the fork. For example, the 0.7 fork could've been sustained. I suppose in that case the 0.8 nodes would've lost coins, or bitcoin could've split. Also interesting to note that bitcoin switched back to BerkeleyDB after bugs in LevelDB were found and peoples' databases were getting corrupted...

impoosible (sarcasm)
core are immortal and indestructible gods.
they are needed or bitcoin would die

core never make mistakes. and everyone should(sarcasm again) run core, get rid of diversity, give core their Tier network and then bow down to the overlord of perfection.

P.S sipa was involved in the 2013 transistion from berkely to leveldb and didnt spot the lock bug. hmm. sipa, oh yea the head honcho of segwit..