Re: [bitcoin-dev] Block size: It's economics & user preparation & moral hazard

2015-12-26 Thread Jorge Timón via bitcoin-dev
On Dec 26, 2015 5:45 PM, "Pieter Wuille via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org> wrote: > My opinion is that the role of Bitcoin Core maintainers is judging whether consensus for a hard fork exists, and is technically necessary and safe. We don't need a hashpower vote to decide

Re: [bitcoin-dev] We need to fix the block withholding attack

2015-12-26 Thread Eric Lombrozo via bitcoin-dev
For simplicity, assume total network hashpower is constant. Also, assume the soft fork activates at the beginning of a retarget period. At the moment the soft fork activates, the effective difficulty is increased (by adding a second independent PoW check that must also be satisfied) which

Re: [bitcoin-dev] We need to fix the block withholding attack

2015-12-26 Thread Jorge Timón via bitcoin-dev
On Dec 26, 2015 9:24 AM, "Eric Lombrozo via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org> wrote: > Unfortunately, this also means longer confirmation times, lower throughput, and lower miner revenue. Note, however, that confirmations would (on average) represent more PoW, so fewer

Re: [bitcoin-dev] We need to fix the block withholding attack

2015-12-26 Thread Eric Lombrozo via bitcoin-dev
I should have stated that we're assuming the actual total hashrate remains constant. Obviously this is not what would actually happen - the rest of the post discusses ways to counter the economic forces at play pushing total hashrate down using only soft forks. The increased variance is still

Re: [bitcoin-dev] We need to fix the block withholding attack

2015-12-26 Thread Multipool Admin via bitcoin-dev
Any attempt to 'fix' this problem, would most likely require changes to all mining software, why not just make mining more decentralized in general? For example, allow anyone to submit proofs of work to Bitcoind that are some fraction of the network difficulty and receive payment for them if

Re: [bitcoin-dev] We need to fix the block withholding attack

2015-12-26 Thread Eric Lombrozo via bitcoin-dev
Note: my stupid email client didn't indent Peter Todd's quote correctly. The first paragraph is his, the second is my response. -- Original Message -- From: "Eric Lombrozo" To: "Peter Todd" ; "Emin Gün Sirer" Cc:

Re: [bitcoin-dev] We need to fix the block withholding attack

2015-12-26 Thread Jonathan Toomim via bitcoin-dev
Another option for how to deal with block withholding attacks: Give the miner who finds the block a bonus. This could even be part of the coinbase transaction. Block withholding is effective because it costs the attacker 0% and costs the pool 100%. If the pool's coinbase tx was 95% to the

Re: [bitcoin-dev] Block size: It's economics & user preparation & moral hazard

2015-12-26 Thread Pieter Wuille via bitcoin-dev
On Dec 26, 2015 23:55, "Jonathan Toomim" wrote: > > On Dec 26, 2015, at 8:44 AM, Pieter Wuille via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: >> >> Furthermore, 75% is pretty terrible as a switchover point, as it guarantees that old nodes will still see a 25% forked

Re: [bitcoin-dev] Block size: It's economics & user preparation & moral hazard

2015-12-26 Thread Bryan Bishop via bitcoin-dev
On Sat, Dec 26, 2015 at 5:15 PM, Justus Ranvier via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > On 12/26/2015 05:01 PM, Pieter Wuille via bitcoin-dev wrote: > > I think the shortest reasonable timeframe for an uncontroversial > > hardfork is somewhere in the range between 6 and

Re: [bitcoin-dev] Block size: It's economics & user preparation & moral hazard

2015-12-26 Thread Jonathan Toomim via bitcoin-dev
On Dec 26, 2015, at 8:44 AM, Pieter Wuille via bitcoin-dev wrote: > Furthermore, 75% is pretty terrible as a switchover point, as it guarantees > that old nodes will still see a 25% forked off chain temporarily. > Yes, 75% plus a grace period is better. I

Re: [bitcoin-dev] Block size: It's economics & user preparation & moral hazard

2015-12-26 Thread Pieter Wuille via bitcoin-dev
On Dec 27, 2015 00:06, "Jonathan Toomim" wrote: > Given that a supermajority of users and miners have been asking for a hard fork to increase the blocksize for years, I do not think that mobilizing people to upgrade their nodes is going to be hard. > > When we do the hard fork, we

Re: [bitcoin-dev] Block size: It's economics & user preparation & moral hazard

2015-12-26 Thread Justus Ranvier via bitcoin-dev
On 12/26/2015 06:13 PM, Bryan Bishop wrote: > I think you'll find that there hasn't been stalling regarding an > uncontroversial hard-fork deployment. You might be confusing an > uncontroversial hard-fork decision instead with how developers have > brought up many issues about various

Re: [bitcoin-dev] We need to fix the block withholding attack

2015-12-26 Thread Geir Harald Hansen via bitcoin-dev
Last I heard it was believed the miner had made their own mining client and that the block withholding was a bug, not an intended feature. On 26.12.2015 09:12, Multipool Admin via bitcoin-dev wrote: > Any attempt to 'fix' this problem, would most likely require changes to > all mining software,