Topic: Wondering out loud: Which should Chinese miners support - Core, Classic or another? - page 3. (Read 38050 times)

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?

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.

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

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.   

@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.

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?

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.

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?

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.

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.

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.

Peter Todd has not discredited the plan as fraud. 

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

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

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.

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

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.

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.

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

"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.

Bitcoin Classic hasn't been released yet.

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.

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.

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.

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.

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.

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://bitcointalksearch.org/topic/forgetting-the-forgetful-68396 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..

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/

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. ↩

Of course not, but hope springs eternal.

Is there any possibility, has there been any suggestion, that this could actually happen?