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
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
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
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
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
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:
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
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
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
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
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
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
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,
13 matches
Mail list logo