<unnamed>

Public Key

npub1kpxa282a99fc93xx30ru3sfmqnyqk3r8aurz3znzxyslhd7felfsg7e3fd

Profile Code

nprofile1qqstqnw4r4wjj5uzcnrgh37gcyasfjqtg3n77p3g3f3rzg0mklyul5cpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0dscwmaqe

Publishing to

relay.snort.social

nos.lol

relay.damus.io

Last Notes

2023-06-07 17:47:06 UTC

- reply

📅 Original date posted:2015-12-25
📝 Original message:On 20.12.2015 18:00, Emin Gün Sirer via bitcoin-dev wrote:
> Instead, we will have the bigger
> pools become more suspicious of signing up new hash power, which is a
> good thing.
Block withholding attacks do not differentiate between small and large
pools. When Eligius and BTCGuild got hit with this, they were far from
the biggest pools at the time.
When my pool, Bitminter, got a new large miner who found 1 block where
average luck would have had them find 3, one of the other miners claimed
they must be withholding blocks. Even if there is no logic or evidence
behind it, after one person cries wolf the others get nervous. This way
even the possibility of block withholding can keep smaller pools from
growing. It takes more hashpower to put a dent in a bigger pool, so you
will see less such panic.
> And we will have small groups of people who have some reason
> for trusting each other (e.g. they know each other from IRC, conferences,
> etc) band together into small pools. These are fantastic outcomes for
> decentralization.
Three guys with 1 TH/s, 2 TH/s and 100 GH/s meet at a conference and
decide to start a private pool? Obviously that doesn't work. Maybe three
people with huge warehouses of miners would work together if they knew
and trusted each other.
Those small miners need to mine with people they don't know to get an
acceptable variance.
If you kill off mining pools then small miners have no way to achieve
acceptable variance and they will disappear. There will only be big
warehouse miners left, the ones who are big enough to solo mine.
That's not helping decentralization.
> Right, it's not clear at all that yelling at people has much effect. As much
> fun as I had going to that meeting with GHash in London to ask them to
> back down off of the 51% boundary, I am pretty sure that yelling at large
> open pools will not scale. We needed better mechanisms for keeping pools
> in check.
I agree. It's very disappointing how most miners and pools handle this
(BTCGuild being the exception). But I do not think block withholding is
a good tool. It can easily destroy small pools, but it won't put a dent
in a pool that goes over 50%.
Block withholding is a tool big pools can use to put smaller competitors
out of business.
And even if it was effective I would not use block withholding to attack
other pools.
> And Miner's Dilemma (MD) attacks are clearly quite effective. This is a
> time when we should count our blessings, not work actively to render
> them inoperable.
Is it? Is there any example of block withholding leading to more
decentralized mining?
If I remember right, GHash being too big ended with BitFury moving some
of their hashpower out of the pool. I don't know where that hashpower
went and whether the problem was solved or merely hidden.
GHash profitability being very low for some time wasn't due to block
withholding, it was a bug that some miners abused to get paid for the
same work multiple times. This made it look like a lot of work was done
while finding few blocks.
> Basically you have the pool pick a secret k for each share, and commit
> to H(k) in the share. Additionally the share commits to a target divider
> D. The PoW validity rule is then changed from H(block header) < T, to be
> H(block header) < T * D && H(H(block header) + k) < max_int / D
>
>
> Thanks, this requires a change to the Bitcoin PoW. Good luck with that!
>
> Once again, this suggestion would make the GHash-at-51% situation
> possible again. Working extra hard to re-enable those painful days
> sounds like a terrible idea.
Block withholding didn't solve the problem back then. And guess what,
those painful days are here right now. China is at 65% and block
withholding isn't solving it.
I was disappointed when GHash got too big and refused to do anything. It
was sad when their miners didn't do anything. Then they used
double-spends to scam a casino. I was shocked that noone cared. Now two
thirds of the bitcoin hashpower is within the control of a single
government. This time I expected noone would care - but I'm still
disappointed. I'm also surprised at the irrational behavior; there are
so many who go out of their way to put their own investments in danger.
For a long time now many miners and pools have been irresponsible with
the hashpower. But block withholding just makes it worse.
Regards,
Geir H. Hansen, Bitminter mining pool

2023-06-07 17:46:57 UTC

- reply

📅 Original date posted:2015-12-27
📝 Original message: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, 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
> <mailto: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 <http://petertodd.org>
> 00000000000000000188b6321da7feae60d74c7b0becbdab3b1a0bd57f10947d
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

2023-06-07 17:34:48 UTC

- reply

📅 Original date posted:2015-08-13
📝 Original message:3) A few more people begin using bitcoin. Bitcoin buckles and dies.
- Something happens a few months from now causing an influx of new users
and more transactions.
- Blocks are constantly full.
- A backlog of transactions keeps growing indefinitely.
- At first people say "bitcoin is slow". After a while they say "bitcoin
doesn't work".
- Changing the hard limit on block size requires a fork and takes too long.
- As bitcoin no longer works people stop using it.
- Bitcoin lives out the last of its days in the backwaters of the
internet with only 5 users. They keep telling people "we increased the
block size now". Unfortunately noone is listening anymore.
- People laugh at you and say "I told you that buttcoin thing was doomed
to fail. After all it wasn't real money."
If the hard limit had been increased earlier then mining pools would
have been able to react quickly by upping their own soft limit. But this
was not the case and so ended Bitcoin.
So in summary:
By increasing the block size limit you run the risk of:
- The transaction fee market takes a little longer to develop.
By not increasing the limit you run the risk of:
- Bitcoin dies. The end.
Transaction fees should not be the main topic of this discussion, and
probably not even a part of it at all. That seems outright irresponsible
to me.
Regards,
Geir H. Hansen, Bitminter mining pool
On 12.08.2015 11:59, Jorge Timón via bitcoin-dev wrote:
> I believe all concerns I've read can be classified in the following groups:
>
>> 1) Potential indirect consequence of rising fees.
>
> - Lowest fee transactions (currently free transactions) will become
> more unreliable.
> - People will migrate to competing systems (PoW altcoins) with lower fees.
>
>> 2) Software problem independent of a concrete block size that needs to
>> be solved anyway, often specific to Bitcoin Core (ie other
>> implementations, say libbitcoin may not necessarily share these
>> problems).
>
> - Bitcoin Core's mempool is unbounded in size and can make the program
> crash by using too much memory.
> - There's no good way to increase the fee of a transaction that is
> taking too long to be mined without the "double spending" transaction
> with the higher fee being blocked by most nodes which follow Bitcoin
> Core's default policy for conflicting spends replacements (aka "first
> seen" replacement policy).
>
> I have started with the 3 concerns that I read more often, but please
> suggest more concerns for these categories and suggest other
> categories if you think there's more.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>