>Another option for how to deal with block withholding attacks: Give the
miner who finds the block a bonus.
...
>This must have been proposed before, right? Anyone know of a good analysis
of the game theory math?
Yes, Section 8.D. in Ittay's paper discusses this countermeasure, as well
as a few ot
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, wh
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 (hard-forking
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 1
On Dec 26, 2015, at 3:16 PM, Pieter Wuille wrote:
> I am generally not interested in a system where we rely on miners to make
> that judgement call to fork off nodes that don't pay attention and/or
> disagree with the change. This is not because I don't trust them, but because
> I believe one
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 will need to en
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 12 months.
This argument would hold more weight if it didn't looks like a stalling
tactic in context.
6 months ago, th
On Dec 26, 2015, at 3:01 PM, Pieter Wuille wrote:
> I think that's extremely short, even assuming there is no controversy about
> changing the rules at all. Things like BIP65 and BIP66 already took
> significantly longer than that, were uncontroversial, and only need miner
> adoption. Full nod
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 off chain temp
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 prefer a grace period of about 4000
to
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 pool,
On Dec 26, 2015 7:30 PM, "Eric Lombrozo via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> I should have stated that we're assuming the actual total hashrate
remains constant.
But that's not reasonable if you are assuming that the total reward per
unit of time drops, that's what
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
u
The hashpower is a function of the block reward (subsidy + fees): it's
economically irrational to have costs greater than the reward (better just
turn off your miners) and in a perfect competition (a theoretical model)
profits tend to zero. That is, the costs tend to equal revenue (block
reward).
O
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
means
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 whe
That's exactly the point: a hard fork does not just affect miners, and
cannot just get decided by miners. All full nodes must have accepted the
new rules, or they will be forked off when the hashrate percentage triggers.
Furthermore, 75% is pretty terrible as a switchover point, as it guarantees
t
On Sat, Dec 26, 2015 at 8:23 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 fewe
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 confirma
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: nbvf...@gmail.com; "Bitcoin Dev"
Sent: 12/26/2015 12:23:38 AM
Subject
Peter Todd wrote:
Fixing block withholding is relatively simple, but (so far) requires a
SPV-visible hardfork. (Luke-Jr's two-stage target mechanism) We should
do this hard-fork in conjunction with any blocksize increase, which will
have the desirable side effect of clearly show consent by the en
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
they'
22 matches
Mail list logo
