<unnamed>

Public Key

npub1wu8nl4rek0s38jw0p5tx4h8a0vu75f33v5ucc0ndj2fza5yav05q36fwsk

Profile Code

nprofile1qqs8wrel63um8cgne88s69n2mn7hkw02ycck2wvv8eke9y3w6zwk86qpzemhxue69uhhyetvv9ujuurjd9kkzmpwdejhgqgdwaehxw309ahx7uewd3hkcqg5waehxw309aex2mrp0yhxgctdw4eju6t0gqzm0t

Publishing to

relay.primal.net

nos.lol

relay.damus.io

Last Notes

2023-06-07 17:46:58 UTC

- reply

📅 Original date posted:2015-12-28
📝 Original message:On Mon, Dec 28, 2015 at 11:12 AM, Peter Todd <pete at petertodd.org> wrote:
> On Sat, Dec 26, 2015 at 12:12:13AM -0800, Multipool Admin wrote:
> > 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're valid. This would also encourage the proliferation of full nodes
> > since anyone could solo mine again. Then, the next coinbase transaction
> > could be split among, say, the top 100 proofs of work.
>
> That's certainly be a good place to be, but the design of Bitcoin
> currently makes achieving that goal fundementally difficult.
>
Agreed, however I don't think it would be impossible or even really that
difficult, and would be a great way to increase decentralization while
simultaneously fixing other issues with mining.
Proofs of work would be valid if they're built on top of the current block
hash, and we could require (difficulty/N) proofs of work that are >=
(difficulty/N) to assemble a valid block. Same as mining shares work.
The block assembler who finds the final diff/N 'share' could get a small
bonus as an incentive to complete the block as quickly as possible. Or
alternatively, a checksum could be computed of all the current diff/N
shares in the mempool and that way only the final share would need to be
broadcasted to the entire network, and clients with the correct checksum
could assemble the block themselves without having to download the entire
block. This would drastically decrease data usage on the network.
> Eligius already does their miner payouts like this.
> >
> > If you want to fix an issue with mining, fix the selfish mining issue
> first
> > as it's a much larger and more dangerous potential issue.
>
> Do you specifically mean selfish mining as defined in Emin Gün
> Sirer/Ittay Eyal's paper? Keep in mind that attack is only a significant
> issue in a scenario - one malicious miner with >30% hashing power -
> where you're already very close to the margins anyway; the difference
> between a 50% attack threshold and a 30% attack threshold isn't very
> significant.
>
Yes, that's what I'm talking about.
> Far more concerning is network propagation effects between large and
> small miners. For that class of issues, if you are in an environemnt
> where selfish mining is possible - a fairly flat, easily DoS/sybil
> attacked network topology - the profitability difference between small
> and large miners even *without* attacks going on is a hugely worrying
> problem. OTOH, if you're blocksize is small enough that propagation time
> is negligable to profitability, then selfish mining attacks with <30%
> hashing power aren't much of a concern - they'll be naturally defeated
> by anti-DoS/anti-sybil measures.
>
The possibility that a previously 'good' actor with 30% of the hashpower
going 'rogue' becomes more and more of a concern as the block subsidy
decreases.
> > I don't believe it was ever clearly established whether Eligius suffered
> a
> > block withholding attack or was just the victim of a miner with (what
> was,
> > at the time) a large amount of faulty hardware, however, from the
> > Bitcointalk threads at the time I believe it was assumed to be the
> latter.
>
> I think the latter was assumed as well, although ruling out of the
> former is impossible.
>
> Note though that Eligius is *not* the only pool to have had problems
> with block withholding, though AFAIK Eligius is the only one who has
> gone on record so far. (as I said in my original post, I'm relaying
> information given to me under condition of confidentiality)
>
What is the incentive not to go on record about this?
--Adam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151228/46d76db5/attachment.html>

2023-06-07 17:46:58 UTC

- reply

📅 Original date posted:2015-12-28
📝 Original message:On Mon, Dec 28, 2015 at 11:30 AM, Emin Gün Sirer <
bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>
> On Mon, Dec 28, 2015 at 2:12 PM, Peter Todd via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> Do you specifically mean selfish mining as defined in Emin Gün
>> Sirer/Ittay Eyal's paper? Keep in mind that attack is only a significant
>> issue in a scenario - one malicious miner with >30% hashing power -
>> where you're already very close to the margins anyway; the difference
>> between a 50% attack threshold and a 30% attack threshold isn't very
>> significant.
>>
>
> This is not quite right: we know that selfish mining is a guaranteed win
> at 34%. We do not know when exactly it begins to pay off. The more
> consolidated and centralized the other mining pools, the less of a threat
> it is below 34%; the more decentralized, the more likely it is to pay off
> at lower thresholds.
>
Exactly.
> Far more concerning is network propagation effects between large and
>> small miners.
>
>
> On a related note, the Bitcoin-NG paper took a big step towards moving
> these kinds of concerns out of the realm of gut-feelings and wavy hands
> into science. In particular, it introduced metrics for fairness (i.e.
> differential
> rate in orphans experienced by small and large miners), hash power
> efficiency, as well as consensus delay.
>
>
>> For that class of issues, if you are in an environemnt
>> where selfish mining is possible - a fairly flat, easily DoS/sybil
>> attacked network topology - the profitability difference between small
>> and large miners even *without* attacks going on is a hugely worrying
>> problem.
>
>
> Indeed, there is a slight, quantifiable benefit to larger pools. Which is
> why
> we need to be diligent about not letting pools get too big.
>
>
>> Note though that Eligius is *not* the only pool to have had problems
>>
> with block withholding, though AFAIK Eligius is the only one who has
>> gone on record so far. (as I said in my original post, I'm relaying
>> information given to me under condition of confidentiality)
>>
>
> I can see why they don't want to go public with this: it means that they
> are less profitable than other pools.
>
This I disagree with -- if they know that they have been attacked, then
there is every reason to come forward with this information.
First of all, it offers an explanation for poor profits (this is better
than unexplained poor profits).
Second of all, if one pool can be attacked then any pool can be attacked --
this is not a reason not to mine on a particular pool. If anything, it's a
reason to diversify hashrate among many pools.
--Adam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151228/8c25dd48/attachment-0001.html>

2023-06-07 17:46:57 UTC

- reply

📅 Original date posted:2015-12-26
📝 Original message: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're valid. This would also encourage the proliferation of full nodes
since anyone could solo mine again. Then, the next coinbase transaction
could be split among, say, the top 100 proofs of work.
Eligius already does their miner payouts like this.
If you want to fix an issue with mining, fix the selfish mining issue first
as it's a much larger and more dangerous potential issue.
I don't believe it was ever clearly established whether Eligius suffered a
block withholding attack or was just the victim of a miner with (what was,
at the time) a large amount of faulty hardware, however, from the
Bitcointalk threads at the time I believe it was assumed to be the latter.
--Adam
On Sat, Dec 19, 2015 at 8:44 PM, Peter Todd via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Sat, Dec 19, 2015 at 07:43:59PM -0800, Chris Priest via bitcoin-dev
> wrote:
> > Then shouldn't this be something the pool deals with, not the bitcoin
> protocol?
>
> There is no known way for pools - especially ones that allow anonymous
> hashers - to effectively prevent block withholding attacks without
> changing the Bitcoin protocol.
>
> --
> 'peter'[:-1]@petertodd.org
> 00000000000000000188b6321da7feae60d74c7b0becbdab3b1a0bd57f10947d
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151226/d35657ba/attachment.html>