trashman43



Offline



Activity: 298

Merit: 100









Full MemberActivity: 298Merit: 100 Gavin coding SPV mining into Classic March 17, 2016, 07:07:26 PM #1 https://github.com/bitcoinclassic/bitcoinclassic/pull/152



Quote from: gavinandresen 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. 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?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)0-2+ confirmation transactions will be much less safe for anyone that does not run a full node. veil ///// PRIVACY WITHOUT COMPROMISE. /////

THE FIRST ZEROCOIN-BASED CRYPTOCURRENCY WITH ALWAYS ON PRIVACY.

Telegram | Facebook | Twitter | Discord

DannyHamilton



Offline



Activity: 2338

Merit: 1729









LegendaryActivity: 2338Merit: 1729 Re: Gavin coding SPV mining into Classic March 17, 2016, 07:29:12 PM #3 Quote from: trashman43 on March 17, 2016, 07:07:26 PM - 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

Quote from: gavinandresen 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). Absolutely true. Assuming that those 0-2+ confirmations all come within 30 seconds...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). https://21.co/dannyhamilton/



My Merit sending policy: My Merit sending policy: https://bitcointalk.org/index.php?topic=2822212.0

Decoded



Offline



Activity: 1232

Merit: 1024





give me your cryptos







LegendaryActivity: 1232Merit: 1024give me your cryptos Re: Gavin coding SPV mining into Classic March 17, 2016, 07:33:00 PM #4 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 looking for a signature campaign, dm me for that

franky1



Offline



Activity: 2884

Merit: 1751









LegendaryActivity: 2884Merit: 1751 Re: Gavin coding SPV mining into Classic March 17, 2016, 07:39:50 PM

Last edit: March 17, 2016, 09:16:36 PM by franky1 #5 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

I DO NOT TRADE OR ACT AS ESCROW ON THIS FORUM EVER.

Please do your own research & respect what is written here as both opinion & information gleaned from experience. many people replying with insults but no on-topic content substance, automatically are 'facepalmed' and yawned at

watashi-kokoto



Offline



Activity: 350

Merit: 258









Sr. MemberActivity: 350Merit: 258 Re: Gavin coding SPV mining into Classic March 17, 2016, 08:38:35 PM #8 Quote from: franky1 on March 17, 2016, 07:39:50 PM 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. 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



Offline



Activity: 2884

Merit: 1751









LegendaryActivity: 2884Merit: 1751 Re: Gavin coding SPV mining into Classic March 17, 2016, 09:15:30 PM #9 Quote from: marky89 on March 17, 2016, 08:26:57 PM 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 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 I DO NOT TRADE OR ACT AS ESCROW ON THIS FORUM EVER.

Please do your own research & respect what is written here as both opinion & information gleaned from experience. many people replying with insults but no on-topic content substance, automatically are 'facepalmed' and yawned at

franky1



Offline



Activity: 2884

Merit: 1751









LegendaryActivity: 2884Merit: 1751 Re: Gavin coding SPV mining into Classic March 17, 2016, 09:33:13 PM #11 Quote from: marky89 on March 17, 2016, 09:24:33 PM Quote from: franky1 on March 17, 2016, 09:15:30 PM Quote from: marky89 on March 17, 2016, 08:26:57 PM 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

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



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 and Sipa are not releasing a contentious hard fork. Gavin is.And Classic is presenting that hard fork asIs 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 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 I DO NOT TRADE OR ACT AS ESCROW ON THIS FORUM EVER.

Please do your own research & respect what is written here as both opinion & information gleaned from experience. many people replying with insults but no on-topic content substance, automatically are 'facepalmed' and yawned at

franky1



Offline



Activity: 2884

Merit: 1751









LegendaryActivity: 2884Merit: 1751 Re: Gavin coding SPV mining into Classic March 17, 2016, 09:54:41 PM #13 Quote from: marky89 on March 17, 2016, 09:39:29 PM Quote from: franky1 on March 17, 2016, 09:33:13 PM Quote from: marky89 on March 17, 2016, 09:24:33 PM Quote from: franky1 on March 17, 2016, 09:15:30 PM Quote from: marky89 on March 17, 2016, 08:26:57 PM 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

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



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 and Sipa are not releasing a contentious hard fork. Gavin is.And Classic is presenting that hard fork asIs 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

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.

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) 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)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) I DO NOT TRADE OR ACT AS ESCROW ON THIS FORUM EVER.

Please do your own research & respect what is written here as both opinion & information gleaned from experience. many people replying with insults but no on-topic content substance, automatically are 'facepalmed' and yawned at

AlexGR



Offline



Activity: 1708

Merit: 1030









LegendaryActivity: 1708Merit: 1030 Re: Gavin coding SPV mining into Classic March 17, 2016, 09:57:29 PM #14



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.

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.

Klestin



Offline



Activity: 493

Merit: 500







Hero MemberActivity: 493Merit: 500 Re: Gavin coding SPV mining into Classic March 17, 2016, 10:16:18 PM #15 Quote from: marky89 on March 17, 2016, 09:24:33 PM 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?



Quote 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. 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?Gee. It sounds to me like they're doing exactly what they said they were going to do.

franky1



Offline



Activity: 2884

Merit: 1751









LegendaryActivity: 2884Merit: 1751 Re: Gavin coding SPV mining into Classic March 17, 2016, 10:21:37 PM #17 Quote from: marky89 on March 17, 2016, 10:16:32 PM Quote from: franky1 on March 17, 2016, 09:54:41 PM

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

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)

That doesn't support anything you said.



Quote 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 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:

That doesn't support anything you said.Are you not aware of the Hardfork Wishlist ? It's been around since at least January 2012. The premise is that. 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 anythingaround 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 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 I DO NOT TRADE OR ACT AS ESCROW ON THIS FORUM EVER.

Please do your own research & respect what is written here as both opinion & information gleaned from experience. many people replying with insults but no on-topic content substance, automatically are 'facepalmed' and yawned at

franky1



Offline



Activity: 2884

Merit: 1751









LegendaryActivity: 2884Merit: 1751 Re: Gavin coding SPV mining into Classic March 17, 2016, 11:07:18 PM #20 Quote from: DeathAngel on March 17, 2016, 10:37:31 PM 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 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 spaceits 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 I DO NOT TRADE OR ACT AS ESCROW ON THIS FORUM EVER.

Please do your own research & respect what is written here as both opinion & information gleaned from experience. many people replying with insults but no on-topic content substance, automatically are 'facepalmed' and yawned at

AliceWonderMiscreations



Offline



Activity: 182

Merit: 100







Full MemberActivity: 182Merit: 100 Re: Gavin coding SPV mining into Classic March 17, 2016, 11:21:20 PM #21 This is precisely why we need *viable* altcoins. They would bring balance of power.



Users like us would use the coins that are in our best interest and miners would mine those coins because they would be the only coins with a block reward worth mining. I hereby reserve the right to sometimes be wrong

kano



Offline



Activity: 3262

Merit: 1294





Linux since 1997 RedHat 4







LegendaryActivity: 3262Merit: 1294Linux since 1997 RedHat 4 Re: Gavin coding SPV mining into Classic March 17, 2016, 11:24:32 PM #22 Validating a block takes around 300ms on my pool.

My pool has the 2nd highest average block size.



The highest is solo.ckpool.org that also has this tiny time to validate blocks.



So anyone using some argument about why empty blocks are required clearly has no idea about the facts and about coding.



The pro empty block argument is FUD to cover crappy pool software and low quality coders. lowest fee PPL N S 3 Days Here on Bitcointalk:

Discord support invite at Majority developer of the c k pool code - k for k ano

Help keep Bitcoin secure by mining on pools with full block verification on all blocks - and NO empty blocks! Pool: https://kano.is Here on Bitcointalk: Forum support invite at https://kano.is/ developer of the cpool code -foranoHelp keep Bitcoin secure by mining on pools with full block verification on all blocks - andempty blocks!

franky1



Offline



Activity: 2884

Merit: 1751









LegendaryActivity: 2884Merit: 1751 Re: Gavin coding SPV mining into Classic March 17, 2016, 11:47:43 PM #24 Quote from: kano on March 17, 2016, 11:24:32 PM Validating a block takes around 300ms on my pool.

My pool has the 2nd highest average block size.



The highest is solo.ckpool.org that also has this tiny time to validate blocks.



So anyone using some argument about why empty blocks are required clearly has no idea about the facts and about coding.



The pro empty block argument is FUD to cover crappy pool software and low quality coders.



maybe worth you telling that to Lauda, to debunk his validation time doomsday scenario of larger blocks maybe worth you telling that to Lauda, to debunk his validation time doomsday scenario of larger blocks I DO NOT TRADE OR ACT AS ESCROW ON THIS FORUM EVER.

Please do your own research & respect what is written here as both opinion & information gleaned from experience. many people replying with insults but no on-topic content substance, automatically are 'facepalmed' and yawned at

HostFat

Legendary



Offline



Activity: 3402

Merit: 1105





I support freedom of choice







StaffLegendaryActivity: 3402Merit: 1105I support freedom of choice Re: Gavin coding SPV mining into Classic March 17, 2016, 11:52:24 PM #25



Head first mining (that it isn't SPV mining), will work great with this too:

https://github.com/bitcoinclassic/bitcoinclassic/pull/147 I think that the problem for china pools/miners is related to "download blocks", and not validate them.Head first mining (that it isn't SPV mining), will work great with this too: NON DO ASSISTENZA PRIVATA

franky1



Offline



Activity: 2884

Merit: 1751









LegendaryActivity: 2884Merit: 1751 Re: Gavin coding SPV mining into Classic March 18, 2016, 12:42:54 AM #27 Quote from: HostFat on March 17, 2016, 11:52:24 PM I think that the problem for china pools/miners is related to "download blocks", and not validate them.



mining POOL servers do not need to be in the same physical location as the ASIC warehouse..



antpool for instance is in sanfransisco. while the warehouse of ASICS that just does the hashing element is in china, a short distance from the manufacturer. this avoids any delay in time for delivery and costs.



remember the pools processes the transactions/validates blocks. and the ASICS just hash away a small clump of data. the asics do not relay transactions (they are not nodes) they do not receive competitors blocks(syncing the chain). basically they have no hard drive and only have one job.. to hash.



so an asic behind the china firewall does not care, and the pool owner can have the pool server anywhere in the world, still connected to his asics in china mining POOL servers do not need to be in the same physical location as the ASIC warehouse..antpool for instance is in sanfransisco. while the warehouse of ASICS that just does the hashing element is in china, a short distance from the manufacturer. this avoids any delay in time for delivery and costs.remember the pools processes the transactions/validates blocks. and the ASICS just hash away a small clump of data. the asics do not relay transactions (they are not nodes) they do not receive competitors blocks(syncing the chain). basically they have no hard drive and only have one job.. to hash.so an asic behind the china firewall does not care, and the pool owner can have the pool server anywhere in the world, still connected to his asics in china I DO NOT TRADE OR ACT AS ESCROW ON THIS FORUM EVER.

Please do your own research & respect what is written here as both opinion & information gleaned from experience. many people replying with insults but no on-topic content substance, automatically are 'facepalmed' and yawned at

kano



Offline



Activity: 3262

Merit: 1294





Linux since 1997 RedHat 4







LegendaryActivity: 3262Merit: 1294Linux since 1997 RedHat 4 Re: Gavin coding SPV mining into Classic March 18, 2016, 01:56:57 AM #28 Quote from: HostFat on March 17, 2016, 11:52:24 PM I think that the problem for china pools/miners is related to "download blocks", and not validate them.

Everyone has to download blocks to mine ... unless they are SPV mining.



Quote

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

Head first mining (that it isn't SPV mining), will work great with this too:



SPV mining means mining off the header without validating the transactions the header confirms.

You can't just use the header to mine unless you are SPV mining.



Thus the term "Head first mining" makes no sense at all since it is simply SPV mining -

and thus no need to create a new name to hide that fact. Everyone has to download blocks to mine ... unless they are SPV mining.The term "Head first" has nothing to do with mining, unless you are SPV mining.SPV mining means mining off the header without validating the transactions the header confirms.You can't just use the header to mine unless you are SPV mining.Thus the term "Head first mining" makes no sense at all since it is simply SPV mining -and thus no need to create a new name to hide that fact. lowest fee PPL N S 3 Days Here on Bitcointalk:

Discord support invite at Majority developer of the c k pool code - k for k ano

Help keep Bitcoin secure by mining on pools with full block verification on all blocks - and NO empty blocks! Pool: https://kano.is Here on Bitcointalk: Forum support invite at https://kano.is/ developer of the cpool code -foranoHelp keep Bitcoin secure by mining on pools with full block verification on all blocks - andempty blocks!

HostFat

Legendary



Offline



Activity: 3402

Merit: 1105





I support freedom of choice







StaffLegendaryActivity: 3402Merit: 1105I support freedom of choice Re: Gavin coding SPV mining into Classic March 18, 2016, 02:13:24 AM #29 "SPV mining" was that the miner/pool was starting mining on the header without knowing if it was already validated.



Miners/pools were just guessing/hoping that it was right only because the interrogated pool was changing to a new header.



With "Head first mining" nodes spread validated header (because they validate the block after fully downloaded it) NON DO ASSISTENZA PRIVATA

WestHarrison



Offline



Activity: 188

Merit: 100









Full MemberActivity: 188Merit: 100 Re: Gavin coding SPV mining into Classic March 18, 2016, 05:50:07 AM #31 To be honest I was way more bearish last year about Bitcoin but seeing it successfully defend itself against the Gavinistas has given me hope. The community sees through these attacks now, including spv mining is such an obviously bad idea that I hope some of the Gavinistas finally see the light.

kano



Offline



Activity: 3262

Merit: 1294





Linux since 1997 RedHat 4







LegendaryActivity: 3262Merit: 1294Linux since 1997 RedHat 4 Re: Gavin coding SPV mining into Classic March 18, 2016, 01:49:41 PM #34 Quote from: HostFat on March 18, 2016, 02:13:24 AM "SPV mining" was that the miner/pool was starting mining on the header without knowing if it was already validated.



Miners/pools were just guessing/hoping that it was right only because the interrogated pool was changing to a new header.



With "Head first mining" nodes spread validated header (because they validate the block after fully downloaded it)

I guess you are trying to imply that someone else has validated the transactions.



Well, that makes no difference since someone somewhere along the way has to validate it, and unless you control what validates it, you are SPV mining.



If you control what validates it, well, you are still having to wait for it to be validated, so yeah there's no sense in implying there's a performance gain unless you really are SPV mining and not validating it somewhere.



What I proposed to the devs was to allow a trust relationship to pass SPV headers to other btcd - to fully validate the header, excluding the contents of the merkle tree, is only nanoseconds.

Since all btcd SHOULD be validating the transactions (and core does this) it means of course you still need to validate them, but you don't have to wait for everyone you are connected to, to validate them also, i.e. allowing to choose to remove the largest repeated work before forwarding the block.



This is called "Black Magic" by gmaxwell:

"In general our experience suggests that trust settings are black magic that cannot be configured correctly even by experts"

https://github.com/bitcoin/bitcoin/issues/7049 I guess you are trying to imply that someone else has validated the transactions.Well, that makes no difference since someone somewhere along the way has to validate it, and unless you control what validates it, you are SPV mining.If you control what validates it, well, you are still having to wait for it to be validated, so yeah there's no sense in implying there's a performance gain unless you really are SPV mining and not validating it somewhere.What I proposed to the devs was to allow a trust relationship to pass SPV headers to other btcd - to fully validate the header, excluding the contents of the merkle tree, is only nanoseconds.Since all btcd SHOULD be validating the transactions (and core does this) it means of course you still need to validate them, but you don't have to wait for everyone you are connected to, to validate them also, i.e. allowing to choose to remove the largest repeated work before forwarding the block.This is called "Black Magic" by gmaxwell:"In general our experience suggests that trust settings are black magic that cannot be configured correctly even by experts" lowest fee PPL N S 3 Days Here on Bitcointalk:

Discord support invite at Majority developer of the c k pool code - k for k ano

Help keep Bitcoin secure by mining on pools with full block verification on all blocks - and NO empty blocks! Pool: https://kano.is Here on Bitcointalk: Forum support invite at https://kano.is/ developer of the cpool code -foranoHelp keep Bitcoin secure by mining on pools with full block verification on all blocks - andempty blocks!

HostFat

Legendary



Offline



Activity: 3402

Merit: 1105





I support freedom of choice







StaffLegendaryActivity: 3402Merit: 1105I support freedom of choice Re: Gavin coding SPV mining into Classic March 18, 2016, 02:37:54 PM #35

Both header and POW are shared on the network (on



In SPV mining the miner/pool only receive the header and NOT the POW.



There can be a situation where a miner/pool can create an invalid block (with invalid tx), but to make it, he will still need to make a valid POW.

It means that the miner/pool will have to pay the same costs to find an invalid block as finding a valid one.



And ... the invalid block will live only for 30 seconds at best.



The core rule of Bitcoin is more economic than technical, better financial results comes from working on the long interest of the network. (making invalid blocks is useless and uneconomic) @exstasie @kanoBoth header and POW are shared on the network (on head first mining ), so the miner/pool can check if it's valid or not, in few ms.In SPV mining the miner/poolThere can be a situation where a miner/pool can create an invalid block (with invalid tx), but to make it,It means that the miner/pool will have to pay the same costs to find an invalid block as finding a valid one.And ... the invalid block will live only for 30 seconds at best.The core rule of Bitcoin is more economic than technical, better financial results comes from working on the long interest of the network. (making invalid blocks is useless and uneconomic) NON DO ASSISTENZA PRIVATA

AliceWonderMiscreations



Offline



Activity: 182

Merit: 100







Full MemberActivity: 182Merit: 100 Re: Gavin coding SPV mining into Classic March 18, 2016, 08:33:58 PM #37 Quote from: Kakmakr on March 18, 2016, 06:28:35 AM Well, did Gavin and Mike Hearn not try something similar with the XT implimentation? Sneaking in code to spy on people and blacklisting IP's was just one of the things they tried. This is one of the reason I am not supporting the Classic/Gavin fanboys. They hook you in the beginning by providing all the features people think they need and once they are in control, they will sneak in more things you do not want. A small tweak here and there. Do not give these guys the foot in the door, they will destroy Bitcoin.



Gavin I believe is doing what he thinks is best for Bitcoin. I just think he is wrong.



Hearn I have no respect for whatsoever. Gavin I believe is doing what he thinks is best for Bitcoin. I just think he is wrong.Hearn I have no respect for whatsoever. I hereby reserve the right to sometimes be wrong

paulh691



Offline



Activity: 134

Merit: 100







Full MemberActivity: 134Merit: 100 Re: Gavin coding SPV mining into Classic March 19, 2016, 02:02:01 AM #42

or orphaned later



but it's good enough for now headers only mining is dangerous and could result in loss of many blocks, if any one of the "headers only" blocks turns out to be fake null headersor orphaned laterbut it's good enough for now

theymos

Legendary



Offline



Activity: 3878

Merit: 7917







AdministratorLegendaryActivity: 3878Merit: 7917 Re: Gavin coding SPV mining into Classic March 19, 2016, 02:04:13 AM

Last edit: March 19, 2016, 02:14:25 AM by theymos #43 Quote from: marky89 on March 17, 2016, 08:26:57 PM 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?



The thing Luke pointed out is an extremely major issue, so it'd be crazy for anyone to use this until that behavior of mining software has been changed.



If that's addressed, then something like this change would make confirmations somewhat less reliable for lightweight wallets. You'd probably want several (3-6) extra confirmations to get the same level of security as before. However, the benefit is that it might be less of a problem for blocks to propagate slowly across the network. (Currently, if blocks take too long to propagate then it can cause orphan blocks for miners, and in severe cases protracted chain forks can result.) I'm not sure exactly how much benefit headers-first would actually bring, though. I guess maybe the benefit could be large enough to safely allow for larger block sizes, but my instinct is that the maximum benefit wouldn't actually be very large. More thought and measurements would be necessary.



If this was rolled out generally, several precautions would be necessary to ensure that a whole bunch of miners don't accidentally mine many blocks on top of an invalid chain. Furthermore, there's a nightmare scenario where the majority of miners mine on an invalid chain and never stop mining on it until manually fixed. Something like headers-first mining would have to ensure that these things are impossible, or that they could cause only small, limited damage.



Headers-first seems to me like mainly an improvement over the headers-only or validationless mining that some miners seem to be doing now, but not something ideal. I think that IBLT / weak blocks will be the real eventual solution to this problem. The thing Luke pointed out is an extremely major issue, so it'd be crazy for anyone to use this until that behavior of mining software has been changed.If that's addressed, then something like this change would make confirmations somewhat less reliable for lightweight wallets. You'd probably want several (3-6) extra confirmations to get the same level of security as before. However, the benefit is that it might be less of a problem for blocks to propagate slowly across the network. (Currently, if blocks take too long to propagate then it can cause orphan blocks for miners, and in severe cases protracted chain forks can result.) I'm not sure exactly how much benefit headers-first would actually bring, though. I guess maybe the benefit could be large enough to safely allow for larger block sizes, but my instinct is that the maximum benefit wouldn't actually be very large. More thought and measurements would be necessary.If this was rolled out generally, several precautions would be necessary to ensure that a whole bunch of miners don't accidentally mine many blocks on top of an invalid chain. Furthermore, there's a nightmare scenario where the majority of miners mine on an invalid chain and never stop mining on it until manually fixed. Something like headers-first mining would have to ensure that these things are impossible, or that they could cause only small, limited damage.Headers-first seems to me like mainly an improvement over the headers-only or validationless mining that some miners seem to be doing now, but not something ideal. I think that IBLT / weak blocks will be the real eventual solution to this problem. 1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD