Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

It's Time For a Hard Bitcoin Fork

hackingdistributed.com

Post reply on HN
Print view View original

71–80 of 154 posts

Re: It's Time For a Hard Bitcoin Fork

#71

Post by Tuna-Fish »

Peaker wrote: post #55
emin-gun-sirer wrote: post #20

Earlier quoted context omitted.

That's not the kind of restriction that stops pool mining. The trick is to enable the pool members to steal the blocks they discover. Andrew Miller, a grad student at UMD, has an ingenious scheme for doing this. I am pretty sure I put the link in the article, under the first bullet in the "What to Do Now" section.

Wouldn't pool participants that use this extension to steal rewards be exposed to the pool simply due to their work being consistently challenged and thus lost? i.e: The pool would notice that certain participants contributions are conflicting with other discoveries, and ban such participants?

> The pool would notice that certain participants contributions are conflicting with other discoveries, and ban such participants?

How? Or, you ban me, I sign up again under a different alias.

Re: It's Time For a Hard Bitcoin Fork

#72

Post by dperfect »

nullc wrote: post #37
a3_nm wrote: post #17

The article makes a pretty interesting point: Bitcoin's version of proof of work can be delegated, which makes mining pools possible. An alternative design could ensure that the task to solve is designed so that miners and pool could not trust each other, thus ensuring that pools do not exist. It seems like this is a pretty big flaw in how Bitcoin is designed, as its security relies on miners remaining independent.

It's pretty easy to break delegation, but the cure is worse than the illness— to reduce mining variance there you must use hosted mining, where miners have even less control (absent more fixes…). GHash.IO is substantially hosted mining in any case. Really the more important point to note is that pooling for variance reduction has absolutely nothing to do with delegating control. Running a outbound only bitcoin full n…

> It's pretty easy to break delegation

I'd be interested to learn how mining delegation could (in theory) be avoided. It seems to me that as long as you have a proof-of-work designed around something that can be solved with distributed computing power, there may always be incentives for delegation and cooperation (especially to reduce variance). I'm genuinely curious to hear what other approaches can be used to "break delegation."

Re: It's Time For a Hard Bitcoin Fork

#73

Post by npizzolato »

chimeracoder wrote: post #5
wmf wrote: post #2

Like IPv4, the "experiment" has grown so large that it may be impossible to get consensus on any non-backwards-compatible change.

> Like IPv4, the "experiment" has grown so large that it may be impossible to get consensus on any non-backwards-compatible change. How is that an accurate description of IPv4 at all? IPv6 has made monumental progress[0] in a relatively short time (yes, for what we're talking about, it's only been a short amount of time). [0] https://www.google.com/intl/en/ipv6/statistics.html

Is 3% in three years really "monumental" progress? I honestly don't know much about the issue, but those numbers hardly seem monumental to me.

Re: It's Time For a Hard Bitcoin Fork

#74

Post by JacobEdelman »

travisb wrote: post #54
JacobEdelman wrote: post #22

Their Bitcoin is broken argument doesn't really seem to work. I agree that something needs to be done to stop huge amounts of pooling but this seems to be too alarmist. The initial Bitcoin is Broken post is at http://hackingdistributed.com/2013/11/04/bitcoin-is-broken/ and a counterpoint is at https://freedom-to-tinker.com/blog/felten/bitcoin-isnt-so-br... .

The argument in that counterpoint seems to be as follows: 1. Assume that selfish mining doesn't work. 2. Because selfish mining doesn't work there will be fair weather miners who will only mine on whichever chain is furthest ahead, defaulting to the public chain in the case of a tie. 3. Since the selfish mining pool won't be ahead all the time nobody will mine for it. 4. Therefore selfish mining doesn't work. It's no…

I think that the "selfish mining" in your first point isn't truly selfish mining. The idea is that the particular method of selfish mining being discussed would be defeated by a truly selfish mining method. No matter what you want to act selfishly and the debate is whether or not their is an optimal selfish strategy that is bad for the overall bitcoin infrastructure. Since little to no incentive exists to stick with a mining pool that is selfishly mining it is my understanding that that the attack using a mining pool mentioned in the previous post will not work well.

Re: It's Time For a Hard Bitcoin Fork

#75

Post by waterlesscloud »

gojomo wrote: post #59
emin-gun-sirer wrote: post #42

Earlier quoted context omitted.

Nice ad hominems you've got there. >In fact, the paper just formalized some concerns discussed in the mining community for years. This is false. Discussed here: http://hackingdistributed.com/2013/11/09/no-you-dint/ >the "Bitcoin lunatic fringe" this author mocks has been right about the pool(s) having such power refraining from destructive (and self-bankrupting) next steps. No. The Bitcoin lunatic fringe was adamant…

I think your track record of alarmism and disrespect to non-academics is relevant, but even if you classify it 'ad hominem', you've earned it with your own prolific slurs of critics. I've addressed your continued "no-you-dint" willful-blindness about earlier analysis elsewhere... including on your own blog at ( http://hackingdistributed.com/2013/11/14/response-to-feedbac... ). You failed to discover (and thus footnot…

"I'm sure someone said no pool would ever even try to get 51%."

Yeah, the 'lunatic fringe' like Sam Altman.

https://twitter.com/sama/statuses/477510946080845826

Re: It's Time For a Hard Bitcoin Fork

#76

Post by socrates1024 »

nullc wrote: post #37
a3_nm wrote: post #17

The article makes a pretty interesting point: Bitcoin's version of proof of work can be delegated, which makes mining pools possible. An alternative design could ensure that the task to solve is designed so that miners and pool could not trust each other, thus ensuring that pools do not exist. It seems like this is a pretty big flaw in how Bitcoin is designed, as its security relies on miners remaining independent.

It's pretty easy to break delegation, but the cure is worse than the illness— to reduce mining variance there you must use hosted mining, where miners have even less control (absent more fixes…). GHash.IO is substantially hosted mining in any case. Really the more important point to note is that pooling for variance reduction has absolutely nothing to do with delegating control. Running a outbound only bitcoin full n…

The non-outsourceable puzzle discourages hosted mining as well as pools (though if users are trusting, then hosted mining might persist anyway).

The non-outsourceable puzzle would have to be adopted at the same time as another change, which would allow solo-miners to enjoy the low variance they get in a pool.

Essentially you would need to allow miners to choose a lower difficulty, for proportionally lower block reward. This opens up DoS concerns if it can go arbitrarily low, and might generally require more bandwidth. This would essentially be Bitcoin internalizing p2pool.

Re: It's Time For a Hard Bitcoin Fork

#77

Post by socrates1024 »

dperfect wrote: post #72
nullc wrote: post #37

Earlier quoted context omitted.

It's pretty easy to break delegation, but the cure is worse than the illness— to reduce mining variance there you must use hosted mining, where miners have even less control (absent more fixes…). GHash.IO is substantially hosted mining in any case. Really the more important point to note is that pooling for variance reduction has absolutely nothing to do with delegating control. Running a outbound only bitcoin full n…

> It's pretty easy to break delegation I'd be interested to learn how mining delegation could (in theory) be avoided. It seems to me that as long as you have a proof-of-work designed around something that can be solved with distributed computing power, there may always be incentives for delegation and cooperation (especially to reduce variance). I'm genuinely curious to hear what other approaches can be used to "brea…

The basic idea for a delegation-breaking puzzle is outlined here: https://bitcointalk.org/index.php?topic=309073.0

The intuition (which is described in the original article, by the way) is that in this puzzle, whoever actually finds the solution can take the entire reward for themselves.

We've expanded this idea into a rigorous research paper that's currently undergoing peer review, but we may release a preprint soon.

Re: It's Time For a Hard Bitcoin Fork

#78

Post by Smudge »

emin-gun-sirer wrote: post #42
gojomo wrote: post #32

This is the same panic-prone author (@el33th4xor) who, in early November 2013 with Bitcoin at about $220, wrote "@el33th4xor: You heard it here first: now is a good time to sell your Bitcoins" ( https://twitter.com/el33th4xor/status/397219415025934336 ) This was just before releasing some research that he thought would cause a confidence collapse. (That is, his prediction was almost self-consciously attempting market…

Nice ad hominems you've got there. >In fact, the paper just formalized some concerns discussed in the mining community for years. This is false. Discussed here: http://hackingdistributed.com/2013/11/09/no-you-dint/ >the "Bitcoin lunatic fringe" this author mocks has been right about the pool(s) having such power refraining from destructive (and self-bankrupting) next steps. No. The Bitcoin lunatic fringe was adamant…

I don't disagree with you, but just FYI, 'ad hominem' has a pretty specific meaning and I don't think it applies in this case.

Simply calling someone 'panic-prone' isn't in itself ad hominem. If the argument were that because the author is panic-prone he cannot possibly be right, then it would be ad hominem. But if there isn't an explicit causality implied (i.e. being panic-prone makes you wrong), it's more just name-calling. (name-calling != ad hominem)

There may be other fallacies that apply here, but there is actually an argument backing up the commenter's claim that the author is being too panicky, and that this is less of an issue than it is being made out to be.

Re: It's Time For a Hard Bitcoin Fork

#79

Post by platz »

gtirloni wrote: post #69

And down it goes again: https://bitcoinity.org/markets In the previous crisis it was all based on trust ("it was just a bad player, trust will return to the market"). Now we've a doomsday scenario and what seems a serious flaw in Bitcoin. Feels like a chapter out of The Foundation books.

or it's because the silk road bitcoins being auctioned

Re: It's Time For a Hard Bitcoin Fork

#80

Post by gus_massa »

Tuna-Fish wrote: post #71
Peaker wrote: post #55

Earlier quoted context omitted.

Wouldn't pool participants that use this extension to steal rewards be exposed to the pool simply due to their work being consistently challenged and thus lost? i.e: The pool would notice that certain participants contributions are conflicting with other discoveries, and ban such participants?

> The pool would notice that certain participants contributions are conflicting with other discoveries, and ban such participants? How? Or, you ban me, I sign up again under a different alias.

The pool can use a 2% fee for old accounts and a 20% fee for new accounts (for example, with less than 1 month or less than 10^x hashes calculated.)
Post reply on HN