Wondering out loud: Which should Chinese miners support - Core, Classic or another?

[BlindMayorBitcorn]

I was thinking about LA-602 today. 6 months before the Manhatten Project scientists took out their new toy for the first time they prepared a comprehensive study of the possibility that it could have a runaway effect and destroy the Earth by burning up the atmosphere.

Please! Be careful, people.

[1714805262]

1714805262

[2112]

the sugar daddy of bitcoin: http://qntra.net/2016/02/popescu-offers-condition-for-accepting-future-hard-forks/

http://trilema.com/2016/the-necessary-prerequisite-for-any-change-to-the-bitcoin-protocol/

This proposal is actually worth quoting in full before its get deleted or changed. If one takes the claim that this proposal was discussed at length in Mircea Popescu's group, then the conclusion is that his group doesn't have even a single student of cryptology, not to mention an amateur or professional cryptologist.

I'm going to discount to zero the possibility of intentional weakening or intentional misrepresentation; the mistakes are too elementary. Certainly there wasn't a proof-of-concept implementation done.

The following quote was slightly reformatted to conform to the markup limitations of this forum's software.

The necessary prerequisite for any change to the Bitcoin protocol

Monday, 01 February, Year 8 d.Tr. | Author: Mircea Popescu   

Summary :

All blocks must include a SHA3(I)-512 digest calculated over a bitfield composed out of the nonce-th byte out of every preceding block, wrapped.(ii)

Rationale :

The issues being resolved have been discussed at length in #bitcoin-assets, whose logs you are invited to read - right now, and in integrum.(iii)

This notwithstanding, an unbinding summary is that the miner-node division(iv) is both an unintended consequence of the poor design and inept implementation of Bitcoin by its original author as well as the single known possible threat to its continued survival. This measure heals that rift, by making it impossible for miners to mine without nodes(v)) ; and by giving nodes a directly valuable piece of information they can sell.(vi)

The Vatican's Armored Divisions(vii) :

I won't bother with parading for your benefit, nor will I recount the sad story of "what happens when you don't do what MP says". If you've done any reading worth the mention you should know all that by now ; if you need any explanation as to why my pronouncements are binding, you necessarily have no clue about Bitcoin-anything. See here instead.

I will however say that details(viii) are negotiable, on one hand, and that I am open to considering other changes be bundled with this change, possibly including an increase of the blocksize. I will however, attack and sink any other change whatsoever, without regard to who proposes it, who supports it, or what it contains. The only way to make any alteration whatsoever is to make an alteration that includes this one.

And now that we understand each other, back to your regularly scheduled program.
———
(i).The principal consideration is that unlike the rest of the SHA "family", the keccak function takes unlimited input. Bitcoin is forever after all.

The political importance of not using NSA/NIST crapolade is a secondary concern, even if it makes a very valid, muchly needed statement, namely that the United States has no future in technology just like it has no future in political geography. ↩

(ii).Exempli gratia :  if the fourth block is added to a blockchain consisting of
i.60 bd e7 67 77 70 20 b2 e6 7c 46 c3 (12 bytes)
ii.75 80 d2 b0 6e 6c 6d a9 5d 12 98 fe bf (13 bytes)
iii.df fc 22 5f 2a 4d 50 d6 f3 fc c3 (11 bytes)

Then should that block use a nonce of 17, it must include a field equal to sha3-512(70 6e 50), whereas should that block use a nonce of 11, it must include a field equal to sha3-512(c3 fe df). ↩

(iii).The notion that you might be participating in Bitcoin in any capacity or to any degree without keeping up with the logs is not unlike the notion that you're participating in the political process through "reading newspapers" or whatever it is you do. ↩

(iv).There's multiple aspects to the issue.

One aspect is that while nodes - no, not "full" nodes, simply nodes ; everything else is not a node at all - do provide useful service, they have no way to extract payment in exchange. This takes us to the present, sad situation where the network barely consists of a few hundred nodes, and on the strength of that alone could be toppled by a fart. (Yes, supposedly significant reserve capacity exists. Let's just hope nobody actually gives this a run for its money.)

Another aspect is that new blocks are mined by one group (miners) but have to be stored in perpetuity by another group (nodes). This creates a situation where X (users) pay Y (miners) to inconvenience Z (nodes), which is unsustainable not to mention sheer nonsense.

It is true that so called "solutions" to this fundamental problem have been pluriously presented by Bitcoin's enemies in sheep's clothing. Nevertheless, they all reduce to attempts, more or less blatant, to leverage this weakness of the protocol into further damage - not a single one of them is to any degree an actual solution or even vaguely addresses the problem at all. ↩

(v).For reasons that I think obvious, mining will continue on ASICs, even if this change will require new ASICs be baked. Nevertheless, for technological reasons it will be impossible to include the generation of this bitfield in the ASICS in question - instead, they will have to depend on importing it from outside.

Whether miners will run their own nodes or allow a decentralized market of "subscription information services" to spawn up will remain to be seen, but if you do believe in the economic superiority of decentralization then you're stuck believing this will happen necessarily.

In any case, a word to the wise : if you are designing ASIC chips, and you are not including the possibility of feeding a bitfield like this in blocks, you are deliberately ensuring failure not just for yourself, but for your customers as well. This change WILL eventually come in, start planning accordingly, today. ↩

(vi).Logically what you'd do as a node operator is create KNBs (known nonce blocks) every time a new block is found. Depending how fast your machine goes, you should be able to output thousands of these per second. A miner that has to feed its rigs something will then buy these blocks from you and proceed to use them (and possibly announce them afterwards too, to protect other miners from being scammed with the same nonce block).

This forces a minimum population of nodes to exist in order for mining to even be possible - what use is more hashing if there's nothing to hash ? ↩

(vii).Is there any cтaлин in the house ? ↩

(viii).Probably the most important of which, shifting the nonce before taking the nonce-th element. Taking the nonce as-is requires strict parity between each hash and the calculated digest, which would require 64 MB of information be available to the miner for each Mhash. This is perhaps not practical - although it does have the marked advantage of making ASICs altogether impractical for mining, and returning that process to more traditional computers. A rather generous eight bit shift would mean the miner needs 64 bytes every Mhash, meaning that each Phash chip must have 64 GB/s worth of data to work its magic. ↩

[BitUsher]

This proposal is actually worth quoting in full before its get deleted or changed. If one takes the claim that this proposal was discussed at length in Mircea Popescu's group, then the conclusion is that his group doesn't have even a single student of cryptology, not to mention an amateur or professional cryptologist.

Salient Point. For those of intrest in why -

https://www.reddit.com/r/Bitcoin/comments/43qisj/paul_sztorc_on_twitter_it_seems_that_mircea/czka9we

So far, I've polled four Bitcoin Core engineers--I showed them the proposal and the median time until completely breaking the scheme is about 20 seconds. ... I'm not sure how much of that was just reading the page.

There are several different ways to achieve a total break of the scheme. One is that you simply fix your nonce to zero-- so you'll only hash the first byte (which also always happens to be a constant), and roll time and other fields instead.

Another is that you just soft-fork require (remember: we're constraining miners here) all blocks to be the same size... then you just pre-compute and incrementally update the million hashes. (This can also be combined with the one above, e.g. only scan nonces where nonce % 1e6 is less than 100 and compute 100 hashes). Even the full million midstates takes about 128 megabytes, more than a tad smaller than the whole blockchain.

The goal here isn't a new one, it often goes under the name of "Throughput proof of storage" or "storage throughput proof of work". You can see a far more reasonable version of it described on my alt ideas page from a few years ago, under "POW which involves queries against the UTXO set (set of spendable coins)".

Ignoring the cryptographic flaw in the approach; this requires the user have the whole historical blockchain to verify it. Eliminating the potential for pruning. There is no reason any Bitcoin node needs to be non-pruned except to help bootstrap new nodes onto the network. It also prevents any kind of lite node-- they can't verify this proof, so an attacker could mine without providing it enormously faster than an honest miner and deceive all the lite nodes. Talk about cutting off your nose to spite your face.

Amusingly, I suggested a much narrower idea in this space (not a throughput proof, but a knowledge proof) in early 2012, https://bitcointalk.org/index.php?topic=68396.0 to stop that year's version of verification-less mining... The author of this idea is the first response.

It would be interesting to find out how things would fare for a Bitcoin without the people who spot flaws in these cryptographic proposals in seconds flat. Interesting, but I suspect not so good for the market price for my Bitcoins.

That said, perhaps it is time to discuss some of the actually viable schemes which have been previously proposed for this. It's quiet easy to construct ones that aren't so obviously broken and which don't have terrible costs like breaking pruning, lite-nodes, etc..

My guess is that MP ego far exceeds his ability and it wasn't widely discussed ... although the lack of comments correcting MP is of concern.

[2112]

Salient Point. For those of intrest in why -

https://www.reddit.com/r/Bitcoin/comments/43qisj/paul_sztorc_on_twitter_it_seems_that_mircea/czka9we

My guess is that MP ego far exceeds his ability and it wasn't widely discussed ... although the lack of comments correcting MP is of concern.

I need to preserve more of the resultant chatter on Twitter. This is developing like one of those "The Onion mistaken for a news site" stories.

Paul Sztorc
‏@Truthcoin   It seems that MP has internalized Bitcoin's full node externality. http://trilema.com/2016/the-necessary-prerequisite-for-any-change-to-the-bitcoin-protocol/ … Initial reaction: "Wow."
Retweets
18
 
Likes
19
 
Pierre Rochard  Andrea Castillo  Beautyon  Daniel P. Barron  CRYPTOSYSTEM  BitcoinUncoilVen  Cosmic Hemorroid  David Francois 

Paul Sztorc ‏@Truthcoin  · 4h4 hours ago 
@Truthcoin Greg Maxwell, smartest man in Bitcoin, has responded with some technical vetos: https://www.reddit.com/r/Bitcoin/comments/43qisj/paul_sztorc_on_twitter_it_seems_that_mircea/czka9we …

View summary   
 3 retweets   4 likes   

 Evan Daniel ‏@evanbd  · 3h3 hours ago 
@Truthcoin Fair to conclude from this that MP's confidence is grossly miscalibrated, then?

 Paul Sztorc ‏@Truthcoin  · 3h3 hours ago 
@evanbd Of course, but don't believe for a second that MP isn't aware of where he's set the calibration dial.

 Evan Daniel ‏@evanbd  · 3h3 hours ago 
@Truthcoin Somewhere between "wrong" and "politician"?

 Paul Sztorc ‏@Truthcoin  · 3h3 hours ago 
@evanbd Somewhere between "Stephen Colbert" and "Bill O'Reilly", perhaps.

 mdotfallon ‏@mdotfallon  · 6h6 hours ago 
@Truthcoin I'm not sure if that's more surprising or the fact that he said he's open to a block size limit increase if node code made it in

 Paul Sztorc ‏@Truthcoin  · 6h6 hours ago 
@mdotfallon What is not surprising is that this article is immediately preceded by one which describes a type of inherently-elitist kink.

 Immanuel Chaiseman ‏@IChaiseman  · 5h5 hours ago 
@Truthcoin

Implement this ASAP. The eccentric, weird dichotomy between node & miner resolved, will make arguments more easier to solve.

 Immanuel Chaiseman ‏@IChaiseman  · 5h5 hours ago 
@Truthcoin Relevant reference on this topic, describing the original tweet in succinct laymanesque detail: http://pastebin.com/ksV2n9y9

David Harrison ‏@tradewithdave  · 3h3 hours ago 

@Truthcoin @junseth self-proclaimed "dumbest man in #Bitcoin" has responded with FREE baseball caps in the crevice of a tree. #DropZone

 Paul Sztorc ‏@Truthcoin  · 3h3 hours ago 
@tradewithdave @junseth Only the SCAMMIES will decide who is truly the dumbest.

 Daniel P. Barron ‏@danielpbarron  · 1h1 hour ago 
@Truthcoin If he has criticism, he should take it to #bitcoin-assets where bitcoin policy is set; not keep pretending like it doesn't exist.

 Daniel P. Barron ‏@danielpbarron  · 1h1 hour ago 
@Truthcoin What's more, he claims Mircea's idea is like his own from 2013, implying that the entire chain of blocks is like the last two.

[sturle]

When the source code is out, it is released.  You don't need binaries for that.

This is getting beyond stupid. But I used to respect you so I'll play along.

The entire quote:

"#Bitcoin Classic tree tagged for the first beta ("classic-0.11.2.b1")
Source code is out there. Binaries/release soon."

Most people will wait until the final binaries are released.

So what?  Bitcoin Core is in beta as well.  People still run it.

I hope they are going to upgrade to 0.12 before they release.  0.12 has lots of improvements, e.g. much faster IBD, data usage limiting, the long awaited RBF feature, etc.  It will be hard to convince people to downgrade.

Except the people on this issue are mostly unnamed shills, not named identifiable people.

Ok, now we're back to the "quality" of the backers. Then show me the heavy hitters!

I already showed Localbitcoins.  Perhaps the exchange with the most users in the world.

My points are: Most people don't sign petitions unless they want change.  And a petition which is supposed to be taken seriously better contain names.

Standard bitcoin is well defined in Satoshi's paper.  Diversion from consensus is not allowed.  Only bugfixes and more restrictions have been allowed, and Satoshi did many of those himself.

"They vote with their CPU power, expressing their acceptance of
valid blocks by working on extending them and rejecting invalid blocks by refusing to work on
them. Any needed rules and incentives can be enforced with this consensus mechanism."

I am glad we agree.

You are quoting the wrong paragraph.

Bitcoin Classic hasn't been released yet.

By the measure you are using, Bitcoin Core hasn't been released yet.  It is in beta.

I do make it very clear that I sell Bitcoin and no altcoins.  I always did.  I link to bitcoin.org in my FAQ.

I'm sure there'll be plenty of time to argue semantics when you're in front of the judge if a fork should happen. It's not obvious that everyone will agree with your terminology.

Don't be silly.  Altcoin is the generic term for Bitcoin forks.  It been since the first Bitcoin forks/altcoins started to show up years ago, using alternative consensus rules.  It can easily be shown in court.

When Core is done with their roadmap, the SPV problem will at least be solved by the fraud proofs included in the segwit proposal.  This makes the world a bit safer for SPV wallets.  Segwit has a testnet, and works, btw.  Many wallets have it implemented already.  You are welcome to test it.  Join #segwit-dev on Freenode to discuss.

I hope Core replies with a 2MB/Segwit hard fork. It seems like a clever piece of technology. But I wasn't talking about Segwit. Segwit will only get us so far.

Segwit has the potential to get us much further, and scale dynamically.  Just increasing the blocksize doesn't scale at all.

[sturle]

Huh?  The bitcoin blocks are still valid bitcoin blocks when segwit is deployed.  Transactions with a segregated witness will have the signature in a separate chain, but this does not change the validity of the block. The blocks and the transactions in the blocks are perfectly valid to all nodes.

This is completely wrong. The segregated tx's are absolutely invalid to present nodes. A nasty hack to make them appear as "I dont know what to do with this, so I will assume its valid" does not mean a tx is valid. They will remain UNVALIDATED by nodes that are not upgraded.

No, it is correct.  Transactions with a segregated witness will be completely valid to present nodes.  They will look like a normal "anyonecanpay" transaction.  

Are they "anyonecanpay" transactions?  Yes or No? Of course they are not.

Of course they are.  They are standard bitcoin transactions, and there are many of them in the blockchain.  They do exactly the same as standard P2PKH transactions, just that the output is spendable by anyone.  There are many of them in the blockchain already.

If they are not, then how can you say "they have been validated"?  The transaction has been misrepresented, it is something completely different to what the node thinks it is, yet you maintain that as correct.   Nodes will essentially be SPV clients with respect to segwit transactions. That is the fraud of this so-called "soft-fork" plan. Which, of course, has already been discredited by Peter Todd.

First of all; segwit, like all soft forks, will only be activated when 95% of the hashrate support it.  Peter Todd has not discredited the plan as fraud.  Exploiting this requires roughly the same hashrate as a 51% attack, and will only apply to segwit transactions.  Someone who invest that much will probably go for the entire cake.  After segwit has been deployed, SPV clients will be much safer to use due to the fraud proof.

[sturle]

the sugar daddy of bitcoin: http://qntra.net/2016/02/popescu-offers-condition-for-accepting-future-hard-forks/

http://trilema.com/2016/the-necessary-prerequisite-for-any-change-to-the-bitcoin-protocol/

This proposal is actually worth quoting in full before its get deleted or changed. If one takes the claim that this proposal was discussed at length in Mircea Popescu's group, then the conclusion is that his group doesn't have even a single student of cryptology, not to mention an amateur or professional cryptologist.

If you are afraid of that getting deleted, you can still read gmawell's very similar proposal from 2012 here.

[Fatman3001]

When the source code is out, it is released.  You don't need binaries for that.

This is getting beyond stupid. But I used to respect you so I'll play along.

The entire quote:

"#Bitcoin Classic tree tagged for the first beta ("classic-0.11.2.b1")
Source code is out there. Binaries/release soon."

Most people will wait until the final binaries are released.

So what?  Bitcoin Core is in beta as well.  People still run it.

Ok... try to stay with me: The files the devs expect most people to download are not released yet. Thus it is premature to conclude that Bitcoin Classic is a failure based on node count.

Can you at least agree to that?

I hope they are going to upgrade to 0.12 before they release.  0.12 has lots of improvements, e.g. much faster IBD, data usage limiting, the long awaited RBF feature, etc.  It will be hard to convince people to downgrade.

The first version will be 0.11.2 with a 2MB block size. It may very well be the final version if Core decides to wise up.

Except the people on this issue are mostly unnamed shills, not named identifiable people.

Ok, now we're back to the "quality" of the backers. Then show me the heavy hitters!

I already showed Localbitcoins.  Perhaps the exchange with the most users in the world.

My points are: Most people don't sign petitions unless they want change.  And a petition which is supposed to be taken seriously better contain names.

I sort of agree with your last statement inasmuch as the proof is in the pudding. We'll see.

Standard bitcoin is well defined in Satoshi's paper.  Diversion from consensus is not allowed.  Only bugfixes and more restrictions have been allowed, and Satoshi did many of those himself.

"They vote with their CPU power, expressing their acceptance of
valid blocks by working on extending them and rejecting invalid blocks by refusing to work on
them. Any needed rules and incentives can be enforced with this consensus mechanism."

I am glad we agree.

You are quoting the wrong paragraph.

Bitcoin Classic hasn't been released yet.

By the measure you are using, Bitcoin Core hasn't been released yet.  It is in beta.

I do make it very clear that I sell Bitcoin and no altcoins.  I always did.  I link to bitcoin.org in my FAQ.

I'm sure there'll be plenty of time to argue semantics when you're in front of the judge if a fork should happen. It's not obvious that everyone will agree with your terminology.

Don't be silly.  Altcoin is the generic term for Bitcoin forks.  It been since the first Bitcoin forks/altcoins started to show up years ago, using alternative consensus rules.  It can easily be shown in court.

You might be surprised. You may very well be right in some way, but if all the exchanges, businesses, miners and the rest of the community runs Classic and they call it Bitcoin, the courts may agree with them. This is not complicated stuff.
 

When Core is done with their roadmap, the SPV problem will at least be solved by the fraud proofs included in the segwit proposal.  This makes the world a bit safer for SPV wallets.  Segwit has a testnet, and works, btw.  Many wallets have it implemented already.  You are welcome to test it.  Join #segwit-dev on Freenode to discuss.

I hope Core replies with a 2MB/Segwit hard fork. It seems like a clever piece of technology. But I wasn't talking about Segwit. Segwit will only get us so far.

Segwit has the potential to get us much further, and scale dynamically.  Just increasing the blocksize doesn't scale at all.

Of course it does. I agree that there needs to be more focus on efficiency, but my view (and that of quite a few others as well) is that we can't let the cow starve while the grass is growing. And this seems to be the main point of contention.
 

[sAt0sHiFanClub]

Of course they are.  They are standard bitcoin transactions, and there are many of them in the blockchain.  They do exactly the same as standard P2PKH transactions, just that the output is spendable by anyone.  There are many of them in the blockchain already.

Except they are not. Its a different transaction, that does something differently when interpreted by a particular version of the code. It has extension data ( segregated witnesses in an unvalidated block extension) that the client knows nothing about. Add to that the explicit intent for HAVEWITNESS nodes to disconnect from non upgraded peers - effectively forking them off the network. Why - if as you suggest they are handling 'valid' data?

Code:

On Thu, Jan 28, 2016 at 01:51:24PM -0500, Peter Todd via bitcoin-dev wrote:
> While Pieter Wuille's segwit branch(1) doesn't yet implement a fix for
> the above problem, the obvious thing to do is to add a new service bit
> such as NODE_SEGWIT, and/or bump the protocol version, and for outgoing
> peers only connect to peers with segwit support.

Peter Todd has not discredited the plan as fraud. 

I didnt say that - you conflated 2 different statements.  Peter discredited the notion that SW could be a safe soft fork as it stands.
The idea of it being a fraud is my own - a fraud from the perspective that it it being spun as a harmless soft-fork to users, when it is anything but. The fraud that you spin a HF as this evil, to-be-avoided-at-all-costs event, when in fact it is the more straight forward solution, involving infinitely less risk than a rushed segwit deployment. I mean, just look at the mailing list the last few days. There are still huge issues with how it is to be deployed - there are still more questions than answers at this stage.

And I'm not against segwit per se - I think its a great solution, but it should wait its turn and be deployed when it is ready. Currently it is being misrepresented as a scaling solution, when it is anything but. 

And by the way, the existence of code in a github repository does not equal the existence of a "release". That is a complete nonsense.

[sturle]

So what?  Bitcoin Core is in beta as well.  People still run it.

Ok... try to stay with me: The files the devs expect most people to download are not released yet. Thus it is premature to conclude that Bitcoin Classic is a failure based on node count.

Can you at least agree to that?

I have no idea what the devs expect, but based on the steady decline of altcoin nodes on the p2p network, I doubt the release of binaries will have much effect on anything.  There are plenty other altcoin nodes to run, which have the binaries ready for download.

I hope they are going to upgrade to 0.12 before they release.  0.12 has lots of improvements, e.g. much faster IBD, data usage limiting, the long awaited RBF feature, etc.  It will be hard to convince people to downgrade.

The first version will be 0.11.2 with a 2MB block size. It may very well be the final version if Core decides to wise up.

Doesn't seem to be a serious attempt then.  Are the Toomins too incompetent to merge the improvements from 0.12?

I do make it very clear that I sell Bitcoin and no altcoins.  I always did.  I link to bitcoin.org in my FAQ.

I'm sure there'll be plenty of time to argue semantics when you're in front of the judge if a fork should happen. It's not obvious that everyone will agree with your terminology.

Don't be silly.  Altcoin is the generic term for Bitcoin forks.  It been since the first Bitcoin forks/altcoins started to show up years ago, using alternative consensus rules.  It can easily be shown in court.

You might be surprised. You may very well be right in some way, but if all the exchanges, businesses, miners and the rest of the community runs Classic and they call it Bitcoin, the courts may agree with them. This is not complicated stuff.

I am a miner as well, and I am not going to start mining any altcoins.  I doubt you will get many miners to switch.  For a given hashrate the miners will produce exactly as much as before the fork, until the first difficulty adjustment.  No matter which fork you are on.  After that your return will increase a lot.

If everyone switches, including me, consensus have changed.  So far nothing indicates that the altcoins have more than a meager support among users, merchants, exchanges and miners.  There was a pull request on requiring 90% miner support for hardfork activation in "Classic", by request of some Chinese miners, but the dictator of the project, Oliver Janssen, closed it.  He is only aiming for the destruction and control of Bitcoin, and has no regards for the wishes of the miners, users, merchants or exchanges, or sanity.

I wonder how long it takes until a miner do a 51% attack on "Classic" using only 25% of the hashrate (after already scaling off a lot of the competition due to the fork) using the 10 minute block trick.  With 2 MB blocks, you can design a transaction which takes 10 minutes to validate.  In the mean time the malicious miner has a 10 minute head start on the next block.  Victory!  "Classic" hasn't been given much thought.  In the mean time Bitcoin solves the O(n²) problem in segwit, allowing for large transactions which don't take forever to validate.  (XT had a "solution" to this problem, by limiting transactions to 100 kB, a limit which would require another hard fork to remove in the future.  Where the other developers look for elegant, efficient and flexible solutions, Gavin prefers using a mallet.  (In his own words.))
 

I hope Core replies with a 2MB/Segwit hard fork. It seems like a clever piece of technology. But I wasn't talking about Segwit. Segwit will only get us so far.

Segwit has the potential to get us much further, and scale dynamically.  Just increasing the blocksize doesn't scale at all.

Of course it does. I agree that there needs to be more focus on efficiency, but my view (and that of quite a few others as well) is that we can't let the cow starve while the grass is growing. And this seems to be the main point of contention.

Letting the cow die in a civil war isn't much better.

[sturle]

Of course they are.  They are standard bitcoin transactions, and there are many of them in the blockchain.  They do exactly the same as standard P2PKH transactions, just that the output is spendable by anyone.  There are many of them in the blockchain already.

Except they are not.

Yes, they are.   SIGHASH_ANYONECANPAY is a standard script operation which has existed since the beginning.  They are an important part of many types of smart contracts and colored coins.  You are totaly confused.  Have you been taking the Reddit pill or something?

Its a different transaction, that does something differently when interpreted by a particular version of the code. It has extension data (segregated witnesses in an unvalidated block extension) that the client knows nothing about.

The client doesn't have to know anything about it.  If it hasn't produced any P2WSH or P2WPKH addresses, it won't receive any payments using segregated witness.  It can validate everything it needs to the way it always did.

Add to that the explicit intent for HAVEWITNESS nodes to disconnect from non upgraded peers - effectively forking them off the network. Why - if as you suggest they are handling 'valid' data?

Code:

On Thu, Jan 28, 2016 at 01:51:24PM -0500, Peter Todd via bitcoin-dev wrote:
> While Pieter Wuille's segwit branch(1) doesn't yet implement a fix for
> the above problem, the obvious thing to do is to add a new service bit
> such as NODE_SEGWIT, and/or bump the protocol version, and for *outgoing*
> *peers* only connect to peers with segwit support.

I emphasized two important words you didn't read.  An old node can still connect to peers, but will not receive incoming connections from new nodes.  It will receive incoming connections from old nodes, however.  New nodes will only make outgoing connections to segwit nodes, to make sure they can sync with segwit data.

A node will only make 8 outgoing connections.  If most of them are to non-segwit nodes, it will be much harder to get the segwit data.  Peter Todd suggest a solution to this potential problem.

Peter Todd has not discredited the plan as fraud. 

I didnt say that - you conflated 2 different statements.  Peter discredited the notion that SW could be a safe soft fork as it stands.

He also suggested a way to make it safe.  You quoted form the solution, but didn't understand it.

The idea of it being a fraud is my own - a fraud from the perspective that it it being spun as a harmless soft-fork to users, when it is anything but. The fraud that you spin a HF as this evil, to-be-avoided-at-all-costs event, when in fact it is the more straight forward solution, involving infinitely less risk than a rushed segwit deployment. I mean, just look at the mailing list the last few days. There are still huge issues with how it is to be deployed - there are still more questions than answers at this stage.

Please list the remaining issues, and explain why the issues are more difficult to solve than getting all bitcoin users to switch to a different software maintained by two incompetent brothers and a dictator.

[iCEBREAKER]

@eric@haobtc

You should really try to communicate with core devs over skype or better yet in person before making a decision.

Too be honest I am surprised you thought Icebreaker was a dev. It suggests you do not even know who the core devs are. There must be a pretty big disconnect between the Chinese community and what is happening in Bitcoin.

Please don't presume to generalize about the Chinese Bitcoin community on the basis of what one guy posts here.  You might hurt yourself jumping to such a distant conclusion!   

Many Bitcoiners in China work closely with the core devs, and even more of them are too wise and well informed to fall for the Classic attempt to drive a wedge between Core and China by spreading rumors/memes about how 'Core doesn't respect China.'

EG, https://bitcoinzh.com/has-anyone-upgraded-to-bitcoin-classic/

I don't have the stack-of-books forum flair, so it's unlikely anyone mistook me for a core dev.

It was just one of my fan club that felt it necessary to use that (obvious, undisputed) fact to try and invalidate my posts.

[iCEBREAKER]

some part of core stands against pretty much everyone else in the bitcoin universe.   

miners are in favor of 2MB.

community/users are in favor of 2MB. (i would estimate 80/20 in favor of 2MB)

bitcoin services are in favor of 2MB. that means stamp, coinbase, blockchain.org, bitpay, etc etc

so its basically a minor group of devs against everyone else. 

so its basically 20% of the community plus maybe 5 devs that try to force their will on everyone else.   

If those unsupported, evidence-free assumptions (pulled hot and fresh out of your own ass) are actually true, it's a good thing Bitcoin is not and never will be a democracy.

Have fun trying to impose moral hazards like majoritarianism on Honey Badger.  Watch out for the claws.  And the teeth.  And the bees, cobra, etc.

[BitUsher]

Interesting perspective from our brothers in the east.

Miners aren't that critical

https://bitcoinzh.com/miners-are-not-that-critical

Miners aren't that critical, original Chinese text from Bikeji.com

Are we sure we want to increase to 2MB right now?

I remember when XT was being pushed out, Gavin was saying if we don’t expand block sizes there’ll be all kinds problems. We haven’t expanded, have any problems appeared after all? It reminds me of an expression, I forget who said it, but most of the things you worry about just won’t happen. So even if we don’t increase, I don’t think anything major will happen to Bitcoin. At worst maybe the price won’t go up as you’d like, but that’s nothing really. We’re all 10-year, loyal holders.

Actually, the reason I suggest not increasing to 2MB now is, I want to see just what is caused by blocks being full. This hasn’t happened before, so it’s a chance for us to experience whether or not it’s as critical as Gavin says. I don’t think it will be. Last time, to win support for XT, Gavin was sensationalizing and nothing more. If Bitcoin could die just like that, well then it wouldn’t be much loss.

Rights & responsibilities

The most frequent refrain in the block size debate has been centralization of the Bitcoin code. In fact, whatever the issue, rights and responsibilities are intrinsically linked. It’s just like with mining, CPU gives you rights, but it also gives you responsibility - to protect the network. In the same way, protecting Bitcoin’s code may appear as power, but it’s actually a responsibility.

Even if the code were being centralized, this would be a result of people’s inactions at normal times. We don’t usually assume any greater responsibility, so at these critical junctures, we don’t have greater rights to a voice. This would apply in any domain. So if anyone has something to say, any suggestions, you can closely follow how the code is looked after and make contributions to the Core developers. If everyone just acts in their corporate interests, then we won’t have anything worth saying and I for one won’t be complaining.

Of course, I still have my vote and can leave at any time. Although I don’t currently think there’s any problem with Core. As far as I can see, their’s is a long-sighted proposal.

Who are our allies?

Who are our allies in this affair? It’s often hard to tell. Like Mike releasing XT then making a run for it. I still don’t get why someone who’d sold all their coins would care so much about making a hard fork.

As a bitcoin holder, I can only confirm that miners are our allies. They’ve invested real dollars. We’ve all witnessed their hashing power, there’s no faking that. But what about developers? We don’t really know whether they hold any coins or not. I couldn’t trust anyone who could support a fork at 75% consensus without regard for the miners’ interests. For the very simple reason that I don’t know whether you have skin in the game whereas with miners it’s out in the open. So if someone isn’t looking out for the interests of miners, then they aren’t an ally. That’s why Gavin fell sharply in my estimation when he released XT.

Who’s the weak one?

Actually Bitcoin does have a way of controlling the situation when blocks are full. If a serious bug appears, achieving consensus and implementing a hard fork is simple because everyone has an economic interest. Why is it that we’ve been arguing about block size expansion for so long but haven’t reached consensus? Because there’s no rush!

If the consequence of having blocks at capacity were network paralysis, I’m sure within 24 hours the hard fork would be implemented and successfully so. But clearly, if blocks are full then blocks are just full and it’s not the end of the world. During the spam attack stress-test and over the few days when there are price bubbles, blocks are basically at capacity.

What’s that you say? The user experience is terrible? New users can’t join the network? The price is depressed? Lol, don’t you want the cheap coins? Whatever way you look at this, the weak point isn’t Bitcoin, it’s us. Maybe the price will rise too slowly, if so we’ll speed up. Maybe some people are plotting to profit from the price fall, deliberately creating panic.

Whatever you do or don’t do then, don’t stop hodling!

[sAt0sHiFanClub]

Yes, they are.   SIGHASH_ANYONECANPAY is a standard script operation which has existed since the beginning.  They are an important part of many types of smart contracts and colored coins.  You are totaly confused.  Have you been taking the Reddit pill or something?

You have deliberately avoided the point I made - these 'appear' to be anyonecanpay, but they are not. The substantive feature of the tx lies in the segreagated winess data, which non-upgrading nodes will not have access to. Instead of making the change explicit by way of HF, you make it underhand in such a way that nodes, through no fault of their own, can no longer process certain tx's. Just because they are not aware of it, does not make it any more palatable.

I emphasized two important words you didn't read.  An old node can still connect to peers, but will not receive incoming connections from [SW] nodes.  It will receive incoming connections from old nodes, however.  New nodes will only make outgoing connections to segwit nodes, to make sure they can sync with segwit data.

A node will only make 8 outgoing connections.  If most of them are to non-segwit nodes, it will be much harder to get the segwit data.  Peter Todd suggest a solution to this potential problem.

Dont play silly games.. And dont presume what I read or didnt read into it. Since when does an outgoing connection from one peer not equal an incoming connection to another?  How does your statement above say anything different to mine - this is effectively splitting the network in two.

users to switch to a different software maintained by two incompetent brothers and a dictator.

You know, you could have just said this at the start and saved me the time of trying to argue with a tin-hat conspiracy-theorist.  Looking back at your efforts to respond (apart from quoting verbatim from /r/bitcoin reddit posts) I can see that you are more adept at turning your points  into ad-homs than saying anything substantial.

[Fatman3001]

So what?  Bitcoin Core is in beta as well.  People still run it.

Ok... try to stay with me: The files the devs expect most people to download are not released yet. Thus it is premature to conclude that Bitcoin Classic is a failure based on node count.

Can you at least agree to that?

I have no idea what the devs expect, but based on the steady decline of altcoin nodes on the p2p network, I doubt the release of binaries will have much effect on anything.  There are plenty other altcoin nodes to run, which have the binaries ready for download.

I hope they are going to upgrade to 0.12 before they release.  0.12 has lots of improvements, e.g. much faster IBD, data usage limiting, the long awaited RBF feature, etc.  It will be hard to convince people to downgrade.

The first version will be 0.11.2 with a 2MB block size. It may very well be the final version if Core decides to wise up.

Doesn't seem to be a serious attempt then.  Are the Toomins too incompetent to merge the improvements from 0.12?

The choice of 0.11.2 was a conscious decision in order to make it perfectly clear what this release of Classic is about.

I do make it very clear that I sell Bitcoin and no altcoins.  I always did.  I link to bitcoin.org in my FAQ.

I'm sure there'll be plenty of time to argue semantics when you're in front of the judge if a fork should happen. It's not obvious that everyone will agree with your terminology.

Don't be silly.  Altcoin is the generic term for Bitcoin forks.  It been since the first Bitcoin forks/altcoins started to show up years ago, using alternative consensus rules.  It can easily be shown in court.

You might be surprised. You may very well be right in some way, but if all the exchanges, businesses, miners and the rest of the community runs Classic and they call it Bitcoin, the courts may agree with them. This is not complicated stuff.

I am a miner as well, and I am not going to start mining any altcoins.  I doubt you will get many miners to switch.  For a given hashrate the miners will produce exactly as much as before the fork, until the first difficulty adjustment.  No matter which fork you are on.  After that your return will increase a lot.

If everyone switches, including me, consensus have changed.  So far nothing indicates that the altcoins have more than a meager support among users, merchants, exchanges and miners.  There was a pull request on requiring 90% miner support for hardfork activation in "Classic", by request of some Chinese miners, but the dictator of the project, Oliver Janssen, closed it.  He is only aiming for the destruction and control of Bitcoin, and has no regards for the wishes of the miners, users, merchants or exchanges, or sanity.

I wonder how long it takes until a miner do a 51% attack on "Classic" using only 25% of the hashrate (after already scaling off a lot of the competition due to the fork) using the 10 minute block trick.  With 2 MB blocks, you can design a transaction which takes 10 minutes to validate.  In the mean time the malicious miner has a 10 minute head start on the next block.  Victory!  "Classic" hasn't been given much thought.  In the mean time Bitcoin solves the O(n²) problem in segwit, allowing for large transactions which don't take forever to validate.  (XT had a "solution" to this problem, by limiting transactions to 100 kB, a limit which would require another hard fork to remove in the future.  Where the other developers look for elegant, efficient and flexible solutions, Gavin prefers using a mallet.  (In his own words.))

[my bold and biden]

With regards to the attack: you're working with probabilities, so at best you'll have a more efficient way of carrying out a 51% attack with roughly 51% of the hashing power. But let's forget that and assume this is a way of confidently launching a 51% attack with 25% of the hashing power. That hashing power still costs 200 million USD. There are much cheaper ways to destroy Bitcoin.

I hope Core replies with a 2MB/Segwit hard fork. It seems like a clever piece of technology. But I wasn't talking about Segwit. Segwit will only get us so far.

Segwit has the potential to get us much further, and scale dynamically.  Just increasing the blocksize doesn't scale at all.

Of course it does. I agree that there needs to be more focus on efficiency, but my view (and that of quite a few others as well) is that we can't let the cow starve while the grass is growing. And this seems to be the main point of contention.

Letting the cow die in a civil war isn't much better.

... the civil war which was started in order to save the cow from starving?



Looking at your posts I get the feeling you think I'm an obnoxious little piece of shit and that you refuse to accept anything I say.

That, at least, is something I can respect.

[sturle]

Yes, they are.   SIGHASH_ANYONECANPAY is a standard script operation which has existed since the beginning.  They are an important part of many types of smart contracts and colored coins.  You are totaly confused.  Have you been taking the Reddit pill or something?

You have deliberately avoided the point I made - these 'appear' to be anyonecanpay, but they are not. The substantive feature of the tx lies in the segreagated winess data, which non-upgrading nodes will not have access to. Instead of making the change explicit by way of HF, you make it underhand in such a way that nodes, through no fault of their own, can no longer process certain tx's. Just because they are not aware of it, does not make it any more palatable.

Again: Non-upgraded nodes don't need to process any more information in those transactions than what will be available to them.  They need to know the complete UTXO set, and if transactions to themselves are valid or not.  And they will know that.

I emphasized two important words you didn't read.  An old node can still connect to peers, but will not receive incoming connections from [SW] nodes.  It will receive incoming connections from old nodes, however.  New nodes will only make outgoing connections to segwit nodes, to make sure they can sync with segwit data.

A node will only make 8 outgoing connections.  If most of them are to non-segwit nodes, it will be much harder to get the segwit data.  Peter Todd suggest a solution to this potential problem.

Dont play silly games.. And dont presume what I read or didnt read into it. Since when does an outgoing connection from one peer not equal an incoming connection to another?  How does your statement above say anything different to mine - this is effectively splitting the network in two.

Bitcoin has been designed to work fine without incoming connections.  A non-upgraded node can make outgoing connections to anyone.  All nodes.  Upgraded or not.  Upgraded nodes will accept incoming connections from anyone.  Upgraded or not.  The only change he is suggesting, is to make sure upgraded nodes only make outgoing connections to other upgrading nodes.  My own node currently has 8 outgoing and 104 incoming connections.  Even if my node is upgraded, and all my outgoing connections are to segwit nodes, there is nothing whatsoever stopping non-upgraded nodes to connect to my node, and nothing is splitting the network in any way imaginable.

You are presenting Peter Todds solution to the problem as the problem, which is beyond my imagination that anyone could think of, but that's Reddit..

users to switch to a different software maintained by two incompetent brothers and a dictator.

You know, you could have just said this at the start and saved me the time of trying to argue with a tin-hat conspiracy-theorist.  Looking back at your efforts to respond (apart from quoting verbatim from /r/bitcoin reddit posts) I can see that you are more adept at turning your points  into ad-homs than saying anything substantial.

So how do you explain how they have failed to keep up with the latest improvements in Bitcoin Core, or address obvious bugs in their code, and Oliver Janssen closing a pull request without accepting any discussion about it?

[sturle]

I hope they are going to upgrade to 0.12 before they release.  0.12 has lots of improvements, e.g. much faster IBD, data usage limiting, the long awaited RBF feature, etc.  It will be hard to convince people to downgrade.

The first version will be 0.11.2 with a 2MB block size. It may very well be the final version if Core decides to wise up.

Doesn't seem to be a serious attempt then.  Are the Toomins too incompetent to merge the improvements from 0.12?

The choice of 0.11.2 was a conscious decision in order to make it perfectly clear what this release of Classic is about.

WTF?  But why?  Finally there is RBF and all the other improvements in 0.12, which are important to users, merchants and exchanges, and Oliver Janssen decides to not support it? Again: WTF is Classic about?  I thought is was a fork to 2 MB block size, not a retardation.

They are clearly just spooking.  Noone in their right mind will run it.  When 90% of nodes use RBF, and 0.12 doesn't even inform about RBF transactions, it would be outright dangerous to use.  I can send a 0-fee transaction to a "Classic" user, insist on getting my money now, and then RBF it.  Even easier than it is now.  With RBF support, I can instead ask the sender to replace it by a non-RBF transaction paying a fee.

I intend to use RBF a lot myself.  I exchange bitcoins all the time, and as long as I have an unconfirmed transaction in the queue, I can just replace it and add outputs as I sell more.  Saving transactions on the blockchain, ensuring faster confirmations for my customers, and not having to use unconfirmed inputs.

And the speed improvements important for IBD?  Why don't they want them?  Or the data limits, etc?  All of those must be essential for a large block fork.

I wonder how long it takes until a miner do a 51% attack on "Classic" using only 25% of the hashrate (after already scaling off a lot of the competition due to the fork) using the 10 minute block trick.  With 2 MB blocks, you can design a transaction which takes 10 minutes to validate.  In the mean time the malicious miner has a 10 minute head start on the next block.  Victory!  "Classic" hasn't been given much thought.  In the mean time Bitcoin solves the O(n²) problem in segwit, allowing for large transactions which don't take forever to validate.  (XT had a "solution" to this problem, by limiting transactions to 100 kB, a limit which would require another hard fork to remove in the future.  Where the other developers look for elegant, efficient and flexible solutions, Gavin prefers using a mallet.  (In his own words.))

With regards to the attack: you're working with probabilities, so at best you'll have a more efficient way of carrying out a 51% attack with roughly 51% of the hashing power. But let's forget that and assume this is a way of confidently launching a 51% attack with 25% of the hashing power. That hashing power still costs 200 million USD. There are much cheaper ways to destroy Bitcoin.

Aqually it should be doable by a lot less than 25%, since you can generate every block a 10 minute to validate block, and it will be very hard for the rest to catch up.  If the fork happens, Bitcoin will already be destroyed, so the investment is already lost.  The only cost is power.

Segwit has the potential to get us much further, and scale dynamically.  Just increasing the blocksize doesn't scale at all.

Of course it does. I agree that there needs to be more focus on efficiency, but my view (and that of quite a few others as well) is that we can't let the cow starve while the grass is growing. And this seems to be the main point of contention.

Letting the cow die in a civil war isn't much better.

... the civil war which was started in order to save the cow from starving?

The cow isn't starving.  The blocks aren't full, except during spam attacks which would have filled blocks of any size.  Not even then, since most miners don't produce full blocks under any circumstance.  Normally, e.g. now, it is far between full blocks.  Some miners are quite good at filtering the spam, and confirm even 0-fee transactions in the first block they make even during the worst spam storms.  Doubling the size of the corn field won't help a bit, when you don't do sh*t about the real problem.  Swarm of grasshoppers and birds eating everyting they get.

[Fatman3001]

I hope they are going to upgrade to 0.12 before they release.  0.12 has lots of improvements, e.g. much faster IBD, data usage limiting, the long awaited RBF feature, etc.  It will be hard to convince people to downgrade.

The first version will be 0.11.2 with a 2MB block size. It may very well be the final version if Core decides to wise up.

Doesn't seem to be a serious attempt then.  Are the Toomins too incompetent to merge the improvements from 0.12?

The choice of 0.11.2 was a conscious decision in order to make it perfectly clear what this release of Classic is about.

WTF?  But why?  Finally there is RBF and all the other improvements in 0.12, which are important to users, merchants and exchanges, and Oliver Janssen decides to not support it? Again: WTF is Classic about?  I thought is was a fork to 2 MB block size, not a retardation.

They are clearly just spooking.  Noone in their right mind will run it.  When 90% of nodes use RBF, and 0.12 doesn't even inform about RBF transactions, it would be outright dangerous to use.  I can send a 0-fee transaction to a "Classic" user, insist on getting my money now, and then RBF it.  Even easier than it is now.  With RBF support, I can instead ask the sender to replace it by a non-RBF transaction paying a fee.

I intend to use RBF a lot myself.  I exchange bitcoins all the time, and as long as I have an unconfirmed transaction in the queue, I can just replace it and add outputs as I sell more.  Saving transactions on the blockchain, ensuring faster confirmations for my customers, and not having to use unconfirmed inputs.

And the speed improvements important for IBD?  Why don't they want them?  Or the data limits, etc?  All of those must be essential for a large block fork.

Because Core hasn't paid enough attention to solving the block size problem. We shouldn't be where we are now.

Or because it's all a big evil conspiracy. Take your pick.

I wonder how long it takes until a miner do a 51% attack on "Classic" using only 25% of the hashrate (after already scaling off a lot of the competition due to the fork) using the 10 minute block trick.  With 2 MB blocks, you can design a transaction which takes 10 minutes to validate.  In the mean time the malicious miner has a 10 minute head start on the next block.  Victory!  "Classic" hasn't been given much thought.  In the mean time Bitcoin solves the O(n²) problem in segwit, allowing for large transactions which don't take forever to validate.  (XT had a "solution" to this problem, by limiting transactions to 100 kB, a limit which would require another hard fork to remove in the future.  Where the other developers look for elegant, efficient and flexible solutions, Gavin prefers using a mallet.  (In his own words.))

With regards to the attack: you're working with probabilities, so at best you'll have a more efficient way of carrying out a 51% attack with roughly 51% of the hashing power. But let's forget that and assume this is a way of confidently launching a 51% attack with 25% of the hashing power. That hashing power still costs 200 million USD. There are much cheaper ways to destroy Bitcoin.

Swarm of grasshoppers and birds eating everyting they get.
Aqually it should be doable by a lot less than 25%, since you can generate every block a 10 minute to validate block, and it will be very hard for the rest to catch up.  If the fork happens, Bitcoin will already be destroyed, so the investment is already lost.  The only cost is power.

So if Bitcoin is already destroyed someone will stay behind to savage the corpse? I am speechless...

Segwit has the potential to get us much further, and scale dynamically.  Just increasing the blocksize doesn't scale at all.

Of course it does. I agree that there needs to be more focus on efficiency, but my view (and that of quite a few others as well) is that we can't let the cow starve while the grass is growing. And this seems to be the main point of contention.

Letting the cow die in a civil war isn't much better.

... the civil war which was started in order to save the cow from starving?

The cow isn't starving.  The blocks aren't full, except during spam attacks which would have filled blocks of any size.  Not even then, since most miners don't produce full blocks under any circumstance.  Normally, e.g. now, it is far between full blocks.  Some miners are quite good at filtering the spam, and confirm even 0-fee transactions in the first block they make even during the worst spam storms.  Doubling the size of the what field won't help a bit, when you don't do sh*t about the real problem.  Swarm of grasshoppers and birds eating everyting they get.

Are we going to have an equally fruitful debate about the word "full" as we had about "released"?

Scroll around and look at the recent blocks:

https://tradeblock.com/bitcoin/

https://blockchain.info/

There's not a lot of room for growth.

By the way, nice metaphor for adoption: "Swarm of grasshoppers and birds eating everyting they get."

[iCEBREAKER]

the sugar daddy of bitcoin: http://qntra.net/2016/02/popescu-offers-condition-for-accepting-future-hard-forks/

http://trilema.com/2016/the-necessary-prerequisite-for-any-change-to-the-bitcoin-protocol/

Summary :

All blocks must include a SHA3i-512 digest calculated over a bitfield composed out of the nonce-th byte out of every preceding block, wrapped.

Rationale :

The issues being resolved have been discussed at length in #bitcoin-assets, whose logs you are invited to read - right now, and in integrum.

This notwithstanding, an unbinding summary is that the miner-node divisioniv is both an unintended consequence of the poor design and inept implementation of Bitcoin by its original author as well as the single known possible threat to its continued survival. This measure heals that rift, by making it impossible for miners to mine without nodesv) ; and by giving nodes a directly valuable piece of information they can sell.vi

Excellent suggestion.

It fixes the glaring problems with the current reward structure, which is producing malallocation of resources (centralized ASIC farms sucking up all the block subsidies) and perverse incentives (externalized node costs, hacky SPV mining).

IIRC, this PoW is called Wild Keccak and has been used successfully by Boolberry for over a year.

Now who is going to code it up and get it into the BIP process/hard fork wishlist?