Gavin coding SPV mining into Classic

[trashman43]

https://github.com/bitcoinclassic/bitcoinclassic/pull/152

Implement "head first mining" : propagate new 80-byte block headers as quickly as possible across the network, and give miners the opportunity to start mining an empty block as soon as they hear about the block header.

it's disgusting. he used to care about what was good for the bitcoin network. now he backtracks on everything he said, so Classic can take over the bitcoin protocol.

even if we assume that most people want a block size increase, wtf is this? now slipping things into Classic that everyone knows is bad for the ecosystem, and which users dont want? he's trying to buy miner votes for Classic with this PR, against all of our interests as users!

this really endangers lite nodes that depend on miners fully validating! people always say full node counts drop because people are moving to lite nodes. and if blocks get bigger, even more. that just means all the more people are going to lose money when miners build on top of invalid chains.

if this gets adopted, and you run a lite/SPV/api node wallet (electrum, multibit, blockchain.info etc) make sure you wait for additional confirmations (6+)! 0-2+ confirmation transactions will be much less safe for anyone that does not run a full node.

[1714891567]

1714891567

[1714891567]

1714891567

[exstasie]

Not surprising. These are very, very dark days for Gavin. This move comes off as quite desperate. The community has been well aware of the dangers of SPV mining at least since early last summer. Hard coding it into the software so that harmful practices used by some miners are now participated in by all miners is just.....omg......especially when he has publicly stated that these are harmful practices.

[DannyHamilton]

- snip -
if this gets adopted, and you run a lite/SPV/api node wallet (electrum, multibit, blockchain.info etc) make sure you wait for additional confirmations (6+)! 0-2+ confirmation transactions will be much less safe for anyone that does not run a full node.

Absolutely true.  Assuming that those 0-2+ confirmations all come within 30 seconds...

https://github.com/bitcoinclassic/bitcoinclassic/pull/152

There is a hard-coded 30-second timeout; if the full block data takes longer than 30 seconds to get validated and propagated across the network, or is never sent, miners switch back to mining non-empty blocks on the last fully-validated block.

So, I definitely agree with trashman43. You should absolutely wait for more than your usual number of confirmations (unless 30 seconds have already passed since you received the payment, in which case it looks like it may be ok to just go with whatever your usual number of required confirmations is).

[Decoded]

Wow. I used to respect Classic, I thought they were a great alternative to Core if I ever was going to change. Because of this, I might as well move to electrum

[franky1]

you do realise that making "empty blocks" is not about making the average 10 minute block empty.
its about giving somthing to ASICS to work on during the minute or 2 that the pool server is validating a competitors previous block solution. and then when validated, the pool server sends the next cluster of unconfirmed transaction hash to the asics to fill the empty block with data.

its just by pure luck that some of the blocks are solved in a couple minutes and it has become visible.
which if blocks were solved in more then 2 minutes no one would know the difference..

the only issue is that sometimes the asics get lucky and have a solution in under 2 minutes before they get a chance to handle real data. which again is just luck. so chill out

atleast its better then making all the pools wait 2 minutes before doing anything, which would bring the average solution to more than 10 minutes and causing the difficulty to drop.

which if a pool server has to validate segwit+payment codes means pools are taking even longer to validate, causing again blocks to take longer until there is a viable solution. which again reduces the difficulty.

now imagine this:

if we had all pools waiting 4-8 minutes before actually hashing. with a lower difficulty. it only takes 1 pool with less hashpower to do an empty block to get a quick solution because they have a 4-8 minute headstart against the competitors.. which is another vector of the 51% attack theorum..

also add to the mix that a malicious pool sends out false blocks to waste competitors time making then validate a block for 2 minutes because they know by sending out false blocks delays the ethical competitors by 1-2 minutes per false block, ths a malicious pool can endlessly keep doing it for hours... sending  false blocks every 30 seconds so that competitors never even get to hash anything..  causing ethical miners to waste many many minutes validating and ultimately rejecting the false flag blocks, giving the malicious pool more of a head start.

its better that all pools follow the same rules where no one has an advantage by not leaving themselves open to abuse using delays... rather than hoping everyone delays their own efforts leaving a risk for abuse..on the pure hope and blind faith that no one malicious would try.

also remember.. hashing an empty block does NOT mean it will get solved in 1-2 minutes.. its just that sometimes they get lucky before they had a chance to fill blocks

id rather have 20 pools that occassionally got lucky then 20 pools that get delayed by 2minutes-2 hours due to a malicious attack vulnerability. and have only 1 pool solving blocks with malicious intent

[exstasie]

- snip -
if this gets adopted, and you run a lite/SPV/api node wallet (electrum, multibit, blockchain.info etc) make sure you wait for additional confirmations (6+)! 0-2+ confirmation transactions will be much less safe for anyone that does not run a full node.

Absolutely true.  Assuming that those 0-2+ confirmations all come within 30 seconds...

https://github.com/bitcoinclassic/bitcoinclassic/pull/152

There is a hard-coded 30-second timeout; if the full block data takes longer than 30 seconds to get validated and propagated across the network, or is never sent, miners switch back to mining non-empty blocks on the last fully-validated block.

So, I definitely agree with trashman43. You should absolutely wait for more than your usual number of confirmations (unless 30 seconds have already passed since you received the payment, in which case it looks like it may be ok to just go with whatever your usual number of required confirmations is).

A couple thoughts on that, since it sounds like you are possibly being sarcastic.

You may be underestimating this, mining is a poisson process; most blocks are found quite soon have the prior one-- the rare long blocks are what pull the average up to ten minutes. About 10% of all block are found within 60 seconds of the prior one. You probably also missed my point that many mining devices will not move off a longer chain, as I added it a moment after the initial post.

I'm not sure of the math when we change the time period from 60 seconds to 30 seconds, but you get my point, right? This is particularly problematic for automated systems (although one would be pretty foolish to build an automated transaction system that does not fully validate).

The trouble with assuming that everything is fine because of the 30-second window.... if this vulnerability is consistent then an attacker only needs to wait, mining with low hashrate, for a block to happen. Luke describes how attacks could be mounted:

The block would contain 2+ transactions. One would be the transaction to your light wallet, and the other one an invalid transaction. The block is invalid because of the second transaction, but your light wallet will gladly accept it for proof that the first transaction is 1-block confirmed. ("Head-first miners" will happily also make additional blocks on top of that invalid block, which your light client will accept as proof of even more blocks confirmed.) However, full nodes will reject that block in its entirety since it is invalid, and instead wait for and follow another, valid block, which in this case would have a double-spend of that transaction you just accepted as confirmed.

you do realise that making "empty blocks" is not about making the average 10 minute block empty.

That's not what the issue is, although I do think that Classic users find the practice upsetting when they realize it's happening.

[marky89]

- snip -
if this gets adopted, and you run a lite/SPV/api node wallet (electrum, multibit, blockchain.info etc) make sure you wait for additional confirmations (6+)! 0-2+ confirmation transactions will be much less safe for anyone that does not run a full node.

Absolutely true.  Assuming that those 0-2+ confirmations all come within 30 seconds...

https://github.com/bitcoinclassic/bitcoinclassic/pull/152

There is a hard-coded 30-second timeout; if the full block data takes longer than 30 seconds to get validated and propagated across the network, or is never sent, miners switch back to mining non-empty blocks on the last fully-validated block.

So, I definitely agree with trashman43. You should absolutely wait for more than your usual number of confirmations (unless 30 seconds have already passed since you received the payment, in which case it looks like it may be ok to just go with whatever your usual number of required confirmations is).

Hmm. Not sure about that.

https://www.reddit.com/r/Bitcoin/comments/4apl97/gavins_head_first_mining_thoughts/d13nv7p

In other words, the code changes do not do what the description claims they do. It may do everything possible to limit it to 30 seconds on the node end, but as already mentioned this is ineffective with current miners which will refuse to ever switch back to an old block.

https://www.reddit.com/r/Bitcoin/comments/4apl97/gavins_head_first_mining_thoughts/d12op9j

Mining code currently sees such an attempt as if it were a malicious pool trying to fork the blockchain, and will refuse to mine on the old block. It's a safety measure against a compromised or malicious pool.

Spread out over https://github.com/luke-jr/bfgminer/blob/bfgminer/miner.c#L7528 and https://github.com/luke-jr/bfgminer/blob/bfgminer/miner.c#L6612

Now, if miners stop using that code --- and nothing in the node software can force them to do that AFAIK --- what kind of trade-off are we making? What are the risks?

Theoretically this would make attacks by a malicious pool more likely, to make attacks based on SPV-mining vulnerability less likely. That trade-off is only necessary because SPV-mining would be hard-coded into the software that all miners run, rather than a bad practice used by some miners --- and making the practice ubiquitous simply exacerbates the dangers that SPV-mining already poses. In other words, Gavin is hard-coding changes that improve orphan risk for miners at the direct cost of user security.

Is that really the best choice? And if so, let's get some more numbers and risk simulations rather than the usual on bitcointalk/reddit, which is to take Gavin's word that every change is both warranted and safe.

Why, I remember something like a year ago, Gavin made it seem like the world would end if we didn't increase the block size immediately. That simple fact should make everyone weary of his judgment and expertise, particularly when hard-coding bad miner practices into the protocol.

Side note: Wasn't Classic being passed off as nothing but a bump to 2MB, because of the controversial changes that were coded into XT? What else is Gavin planning on slipping in?

[watashi-kokoto]

you do realise that making "empty blocks" is not about making the average 10 minute block empty.
its about giving soming to ASICS to work on during the minute or 2 that the pool server is validating a competitors previous block solution. and then when validated the pool server sends the next cluster of unconfirmed transaction hash to the asics to fill the empty block with data.

I agree with you, I don't blame Gavin, I see he realized how SPV mining actually is not that terrible for the network as evident from the start.

[franky1]

Side note: Wasn't Classic being passed off as nothing but a bump to 2MB, because of the controversial changes that were coded into XT? What else is Gavin planning on slipping in?

what else is luke Jr planning on slipping into core..
what else is Sipa planning on slipping into core..

its a bit of tit-for-tat

[marky89]

Side note: Wasn't Classic being passed off as nothing but a bump to 2MB, because of the controversial changes that were coded into XT? What else is Gavin planning on slipping in?

what else is luke Jr planning on slipping into core..
what else is Sipa planning on slipping into core..

its a bit of tit-for-tat

Luke and Sipa are not releasing a contentious hard fork. Gavin is.

And Classic is presenting that hard fork as "a one-feature patch to bitcoin-core that increases the blocksize limit to 2 MB." Is that really the case?

See https://bitcoinclassic.com/

Says it right on the front page. Further, Luke and Sipa can't just slip anything into Core anyway. Not at all. Core has a drawn-out code review process that prevents anything like that. Classic has only a few developers and no peer review. Big difference.

[franky1]

Side note: Wasn't Classic being passed off as nothing but a bump to 2MB, because of the controversial changes that were coded into XT? What else is Gavin planning on slipping in?

what else is luke Jr planning on slipping into core..
what else is Sipa planning on slipping into core..

its a bit of tit-for-tat

Luke and Sipa are not releasing a contentious hard fork. Gavin is.

And Classic is presenting that hard fork as "a one-feature patch to bitcoin-core that increases the blocksize limit to 2 MB." Is that really the case?

See https://bitcoinclassic.com/

Says it right on the front page. Further, Luke and Sipa can't just slip anything into Core anyway. Not at all. Core has a drawn-out code review process that prevents anything like that. Classic has only a few developers and no peer review. Big difference.

luke is proposing a hard fork.. to mess with the difficulty purely so his eligius pool can survive a few more weeks after the reward halving..
it might be worth to investigate blockstream just as much as any other bitcoin development group.

by the way there are 12 groups.. not two. so feel free to expand your mind, and to be less blindly faithful to one team

[marky89]

Side note: Wasn't Classic being passed off as nothing but a bump to 2MB, because of the controversial changes that were coded into XT? What else is Gavin planning on slipping in?

what else is luke Jr planning on slipping into core..
what else is Sipa planning on slipping into core..

its a bit of tit-for-tat

Luke and Sipa are not releasing a contentious hard fork. Gavin is.

And Classic is presenting that hard fork as "a one-feature patch to bitcoin-core that increases the blocksize limit to 2 MB." Is that really the case?

See https://bitcoinclassic.com/

Says it right on the front page. Further, Luke and Sipa can't just slip anything into Core anyway. Not at all. Core has a drawn-out code review process that prevents anything like that. Classic has only a few developers and no peer review. Big difference.

luke is proposing a hard fork.. to mess with the difficulty purely so his eligius pool can survive a few more weeks after the reward halving..
it might be worth to investigate blockstream just as much as any other bitcoin development group.

by the way there are 12 groups.. not two. so feel free to expand your mind, and to be less blindly faithful to one team

Don't confuse things: I am faithful to the protocol's consensus mechanism, NOT "a team." Core happens to be the only "team" that respects consensus in this debate.

Regarding this alleged hard fork, link to the BIP? I'm fairly sure you're mischaracterizing, as usual.

No comments on the fact that Classic is selling itself as "a one-feature patch to bitcoin-core that increases the blocksize limit to 2 MB"....when things like SPV mining are being coded into the software? Seems pretty shady.

[franky1]

Side note: Wasn't Classic being passed off as nothing but a bump to 2MB, because of the controversial changes that were coded into XT? What else is Gavin planning on slipping in?

what else is luke Jr planning on slipping into core..
what else is Sipa planning on slipping into core..

its a bit of tit-for-tat

Luke and Sipa are not releasing a contentious hard fork. Gavin is.

And Classic is presenting that hard fork as "a one-feature patch to bitcoin-core that increases the blocksize limit to 2 MB." Is that really the case?

See https://bitcoinclassic.com/

Says it right on the front page. Further, Luke and Sipa can't just slip anything into Core anyway. Not at all. Core has a drawn-out code review process that prevents anything like that. Classic has only a few developers and no peer review. Big difference.

luke is proposing a hard fork.. to mess with the difficulty purely so his eligius pool can survive a few more weeks after the reward halving..
it might be worth to investigate blockstream just as much as any other bitcoin development group.

by the way there are 12 groups.. not two. so feel free to expand your mind, and to be less blindly faithful to one team

Don't confuse things: I am faithful to the protocol's consensus mechanism, NOT "a team." Core happens to be the only "team" that respects consensus in this debate.

Regarding this alleged hard fork, link to the BIP? I'm fairly sure you're mischaracterizing, as usual.

No comments on the fact that Classic is selling itself as "a one-feature patch to bitcoin-core that increases the blocksize limit to 2 MB"....when things like SPV mining are being coded into the software? Seems pretty shady.

blockstream just as shady.
did you know that a segwit+confidential payment codes while sticking to the 1mb maxblocksize limit actually has a real data value of 2.85mb thanks to the twisting of data. and allows for only a potential 3800 transactions.
whilst a simple 2mb maxblocksize allows a potential 4000tx for 2mb.

oh and here is a link to luke Jr wanting to throw in a difficulty twisting hard for with only a 3 month grace period (#GracePeriodHypocracy)
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-March/012489.html

enjoy.
it seems instead of thinking of a community effort where blockstream adds in the 2mb buffer to protect the community against possible consensus. you believe that blindly following them that delaying any release of code is good. that is not consensus, that is causing contention.

basically by not supplying the code they are the cause of the contention that they scream would be the result of no consensus.. yet if they release the code then everyone can have it and then there is no contention.

stop blindly following blockstream. put on your unbiased hat and think about the community as a whole not your favouritism towards one corporation.

there is no 2mb classic vs segwit blockstream debate.
there is only "when will 2mb+segwit be active" debate. (both features working together)

[AlexGR]

Actually there is no 2mb anymore: If the 2mb is accepted then you automatically go for a ...dynamic blocksize. The 2mb is just to lure in the trojan horse of dynamic blocksizes.

https://github.com/bitcoinclassic/documentation/blob/master/roadmap/roadmap2016.md

Phase 3 (Q3-Q4)

Make the block size limit dynamic

Note: This phase will only happen when miners & companies confirm Phase 2 successfully addressed their blocksize concerns.

[Klestin]

And Classic is presenting that hard fork as "a one-feature patch to bitcoin-core that increases the blocksize limit to 2 MB." Is that really the case?

Hmm... why would the chosen quote begin mid-sentence.  You conveniently cut the "It starts with" from that sentence.  Could it be that the entire paragraph goes a bit differently?

We call our code repository Bitcoin Classic. It starts as a one-feature patch to bitcoin-core that increases the blocksize limit to 2 MB. We have ports for 0.11.2 and 0.12.0, so that miners and businesses can upgrade to 2 MB blocks from any recent bitcoin software version they run.

In the future we will continue to release updates that are in line with Satoshi’s whitepaper & vision, and are agreed upon by the community.

Gee. It sounds to me like they're doing exactly what they said they were going to do.

[marky89]

oh and here is a link to luke Jr wanting to throw in a difficulty twisting hard for with only a 3 month grace period (#GracePeriodHypocracy)
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-March/012489.html

That doesn't support anything you said.

I think it may be reasonable to push for at least code-readiness before July, and possibly roll it into any other hardfork proposed before or around that time.

Are you not aware of the Hardfork Wishlist? It's been around since at least January 2012. The premise is that if bitcoin ever needs to hard fork, these are desired improvements that can only be implemented with a hard fork and therefore should be included. Luke's proposal has been on the Wishlist since at least January 2012. It's always been considered a bug to be fixed when possible. And he speaks of including it in a future proposed hard fork -- not a hard fork for the sake of implementing that bug fix alone --  as would be expected. The concept isn't controversial in the slightest (assuming sufficient testing). But feel free to explain how it is.

Also, you misunderstood regarding 3 months. He said it could be rolled into anything proposed around that time, because the code should be ready by then. He says nothing about the time period between consensus on rule activation and fork in regards to this proposal, though he is known to be conservative in that regard.

Your assumptions about Luke's proposal were also shown to be false: https://bitcointalk.org/index.php?topic=1387549.0;all

[franky1]

oh and here is a link to luke Jr wanting to throw in a difficulty twisting hard for with only a 3 month grace period (#GracePeriodHypocracy)
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-March/012489.html

That doesn't support anything you said.

I think it may be reasonable to push for at least code-readiness before July, and possibly roll it into any other hardfork proposed before or around that time.

Are you not aware of the Hardfork Wishlist? It's been around since at least January 2012. The premise is that if bitcoin ever needs to hard fork, these are desired improvements that can only be implemented with a hard fork and therefore should be included. Luke's proposal has been on the Wishlist since at least January 2012. It's always been considered a bug to be fixed when possible. And he speaks of including it in a future proposed hard fork -- not a hard fork for the sake of implementing that bug fix alone --  as would be expected. The concept isn't controversial in the slightest (assuming sufficient testing). But feel free to explain how it is.

Also, you misunderstood regarding 3 months. He said it could be rolled into anything proposed around that time, because the code should be ready by then. He says nothing about the time period between consensus on rule activation and fork in regards to this proposal, though he is known to be conservative in that regard.

Your assumptions about Luke's proposal were also shown to be false: https://bitcointalk.org/index.php?topic=1387549.0;all

lol read more. he wants the code available in april. to be activated at the turn of the block 420,000 (when the reward halves) so that miners do not lose out instantly.

have a nice day

[marky89]

And Classic is presenting that hard fork as "a one-feature patch to bitcoin-core that increases the blocksize limit to 2 MB." Is that really the case?

Hmm... why would the chosen quote begin mid-sentence.  You conveniently cut the "It starts with" from that sentence.  Could it be that the entire paragraph goes a bit differently?

We call our code repository Bitcoin Classic. It starts as a one-feature patch to bitcoin-core that increases the blocksize limit to 2 MB. We have ports for 0.11.2 and 0.12.0, so that miners and businesses can upgrade to 2 MB blocks from any recent bitcoin software version they run.

In the future we will continue to release updates that are in line with Satoshi’s whitepaper & vision, and are agreed upon by the community.

Gee. It sounds to me like they're doing exactly what they said they were going to do.

I left it out because Classic hasn't increased the blocksize limit to 2 MB. If they had, it would have forked already.

So yes, it is dishonest to say "it starts with" when that isn't true. It actually "starts with" other "features" (like hard-coded SPV mining) that have absolutely nothing to do with increasing the block size.

More importantly, there is really no question that Classic has been marketed by everyone involved as increasing the block size -- there has been virtually no discussion of anything else at all. Just as Bitcoin XT was. Do you recall how XT similarly had "features" coded into it that the community did not support?

lol read more. he wants the code available in april. to be activated at the turn of the block 420,000 (when the reward halves) so that miners do not lose out instantly.

have a nice day

Um, source?

https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-March/012492.html

Depends on the hashrate drop, and tolerance for higher fees, both of which are largely unknown at this time. At least having code prepared for the negative scenarios in case of an emergency seems reasonable, even if we don't end up needing to deploy it.

He also clarified the very same day regarding the link you posted:

This probably isn't a practical timeframe for deployment, unless/until there's an emergency situation. So if the code were bundled with SegWit, it would need some way to avoid its early activation outside of such an emergency (which could possibly be detected in code, in this case).

So either you need to "read more" or you're just being dishonest here.

On that note, Paul Sztorc has some enlightening thoughts on why having such code ready is very important:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-March/012501.html

An emergency hard fork (as in 2013) is just that. There is no plan to activate this rule at halving, and Luke is not suggesting that. So stop spreading misinformation, please. And that fail of a quip you just made doesn't change the fact that your own thread shows that all of your assumptions about why the proposal is bad, were wrong.

Have a nice day

[DeathAngel]

Jeez how much longer until Classic is finally confined to the garbage bin? How & why are some of the community still pushing this crap & backing Gavin?

[franky1]

Jeez how much longer until Classic is finally confined to the garbage bin? How & why are some of the community still pushing this crap & backing Gavin?

most are not backing gavin. most see the bigger picture that there cannot be only one implementation and that all implementations should have the same basic rules and have enough buffer to allow for growth and be able to cope with change. no matter who its by or for what purpose without having to cry to a dev leader for more buffer space

its never been about a power grab of gavin vs back. nor should it.
bitcoins vision is no one is in power. yet the doomsday scenarios of trying to say any coder thats not on blockstream payroll is bad.. is ultimately on the power play that only blockstream should rule.

my personal opinion is that 2mb+segwit should be the goal. and pools not leave themselves vulnerable by not hashing solutions while they validate a possible competitor solution. because not hashing can leave them at risk of receiving an endless download of fake blocks to cause pools to never mine a block due to endlessly validating fake blocks