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

Bitcoin's ASICBOOST Problem Explained [pdf]

rubin.io

Post reply on HN
Print view View original

61–70 of 131 posts

Re: Bitcoin's ASICBOOST Problem Explained [pdf]

#61

Post by yorwba »

MichaelGG wrote: post #53
jcoffland wrote: post #32

Earlier quoted context omitted.

First of all we aren't talking about weaknesses in hash functions. We are talking about ways to compute hashes faster. > But is there any actual work where requiring 2 separate full checks to be worse than just one? That is, needing to verify MD5 plus SHA1 independently. One could then use both SHA1 and MD5 shortcuts.

OK, but having to use both a SHA1 and MD5 shortcut is still going to be more work than using just one of them.

But it's less work than having to compute both SHA1 and MD5 without shortcut, which is the comparison that matters.

Re: Bitcoin's ASICBOOST Problem Explained [pdf]

#62

Post by Kinnard »

tlrobinson wrote: post #60

This might not be the place for this question, but can someone explain why we can't / shouldn't have both unlimited block sizes and SegWit? Block sizes will supposedly be constrained by bandwidth / propagation times. SegWit will allow more transactions to occur off chain, reducing the need for larger blocks. They seem complementary to me.

You are correct and such proposals have been put forward: http://moneyandstate.com/thoughts-on-segwit2mb/

Re: Bitcoin's ASICBOOST Problem Explained [pdf]

#63

Post by shea256 »

timq wrote: post #20

Just to point out that SegWit is everything but "already adopted in the industry". It turns out that SegWit is the solution promoted by the developers of bitcoin core to allow for bigger blocks, and solve some issues like transactions maleability. It's more than 10 000 lines of code highly controversial because they require... A soft fork, and will change bitcoin in a fundamental ways. Not to add that a company calle…

A few red flags came up for me with this post. I feel I have an obligation to post a response to this to clarify some things, lest people less involved in the community come away with a misinformed view.

A few facts on the core developers:

-- There are hundreds of developers who contribute to Bitcoin Core. Over 50 of them have 10+ commits to Bitcoin Core.

-- Blockstream employs 7 of these developers, including Pieter Wuille, Luke Dashjr, Greg Maxwell, Jorge Timon, Patrick Strateman, Warren Togami and Mark Friedenbach.

-- By number of commits, the developers Blockstream employs are ranked #2, #8, #13, #14, #19, #35, and #50, respectively.

-- Another company called ChainCode Labs employs 3 of the top 50 developers, including Alex Morcos, Suhas Daftuar, and Matt Corallo (formerly employed by Blockstream).

-- By number of commits, the developers ChainCode employs are ranked #5, #11 and #12, respectively.

As for SegWit, it is a multi-faceted gold-mine of an update with many, many benefits to scaling, security and efficiency:

1. It fixes the substantial transaction malleability problem once and for all.

2. It improves the efficiency of signature-hashing so it scales linearly rather than quadratically.

3. It 1.7x's the # of single-signature transactions per block and 4x's the # of multi-signature transactions per block.

4. It enables second-layer scaling solutions like Lightning.

5. It upgrades pay-to-script-hash transactions from 160-bit hashes to 256-bit hashes.

6. It makes it safer for hardware wallets to sign transactions by explicitly hashing input values.

7. It reduces the growth of the system's most burdensome resource: unspent transaction outputs, which are ideally kept in memory.

8. It introduces versioning for the scripting language to allow for more easy upgradeability.

Here are some facts on the developer consensus:

-- Out of the top 100 committers to Bitcoin Core, almost all of them believe that SegWit is the best way forward. There is near unanimous consensus on that front. Former project lead Gavin Andresen (no longer associated with the project) is perhaps the most notable opponent.

-- Out of all of the wallet providers, almost all of them are supportive of or at least OK with modest block increases. Almost all of the major wallet providers have prepared themselves to be ready for SegWit.

Re: Bitcoin's ASICBOOST Problem Explained [pdf]

#64

Post by TD-Linux »

fpgaminer wrote: post #40

Besides the technical issues involved here, there's been a lot of political quarrels as well. Here's my run down of them. Note that I was heavily involved in the Bitcoin community a few years ago, but have been on the side lines recently. As with all things political, take my interpretations with a grain of salt: 1) The Bitcoin network began experiencing congestion due to rise in popularity driving large numbers of t…

One minor niggle: Segwit does increase block size, up to a 4MB maximum (though it's expected that most blocks will be about 2.1MB).

Re: Bitcoin's ASICBOOST Problem Explained [pdf]

#65

Post by TD-Linux »

Itsdijital wrote: post #14
petertodd wrote: post #6

Earlier quoted context omitted.

> everyone else uses it soon enough. Unfortunately in this case, ASICBOOST is both patented, and adds a fair bit of complexity to mining hardware. Both these problems have the undesirable effect of increasing the barriers to entry for new asic manufacturers - an undesirable thing from the point of view of Bitcoin users. You're quite correct that shortcuts are irrelevant, but the reality of manufacturing makes the pla…

>ASICBOOST is both patented China be like, lol "patented"

Not only that, Bitmain (the miner implied to be using ASICBOOST covertly) copied the American patent and submitted it to the Chinese patent system. It's not yet granted, though.

Re: Bitcoin's ASICBOOST Problem Explained [pdf]

#66

Post by shea256 »

jcoffland wrote: post #10

This is excellent. I've been trying to find a technical explanation of ASCIBOOST for some time. Most of the articles and discussions gloss over the details. It is possible that this is part of the reason some miners are blocking SegWit but there is more to it. Core (the main Bitcoin development team) promised to provide a block size scaling solution and then reneged. This pissed a lot of people off and led to the blo…

> Core (the main Bitcoin development team) promised to provide a block size scaling solution and then reneged.

This is not true at all and highly deceptive. They originally were supportive of doubling the transaction count via an increase to 2MB blocks and then realized they could accomplish this without a hard fork via SegWit.

SegWit does in fact allow for 1.7x the number of single-signature transactions per block and 4x for multi-signature transactions.

Core absolutely could have handled the communications around this better. But to say they reneged on providing a scaling solution is wrong.

It's also important to keep in mind that what matters is not the block size but the number of transactions that can fit into a block. Block size doubling and cutting transaction sizes in half each double the throughput.

Re: Bitcoin's ASICBOOST Problem Explained [pdf]

#67

Post by _coldfire »

AgentME wrote: post #57
fpgaminer wrote: post #40

Besides the technical issues involved here, there's been a lot of political quarrels as well. Here's my run down of them. Note that I was heavily involved in the Bitcoin community a few years ago, but have been on the side lines recently. As with all things political, take my interpretations with a grain of salt: 1) The Bitcoin network began experiencing congestion due to rise in popularity driving large numbers of t…

Just to add on to this: even ignoring the SegWit incompatibility, ASICBOOST has real downsides. ASICBOOST incentivizes miners to do things like drop transactions or even create empty blocks often, delaying transactions and going against the reason Bitcoin has mining. If it was discovered as Bitcoin was being created, it would have been fixed like any other bug. But now, since it's being used by people known to be ver…

The increasing number of empty blocks along with spymining that has been pushed under the table in this bizarre war, these are the real threats going forward.

Segwit or not, these issues will have to be dealt with at some point.

Re: Bitcoin's ASICBOOST Problem Explained [pdf]

#68

Post by wyldfire »

timq wrote: post #20

Just to point out that SegWit is everything but "already adopted in the industry". It turns out that SegWit is the solution promoted by the developers of bitcoin core to allow for bigger blocks, and solve some issues like transactions maleability. It's more than 10 000 lines of code highly controversial because they require... A soft fork, and will change bitcoin in a fundamental ways. Not to add that a company calle…

> The community and a growing majority of miners is actually switching to bitcoin unlimited

I love bitcoin too. I might be underinformed but everything I've learned so far is that larger blocks and segwit aren't a dichotomy at all. I think segwit sounds good. And I think larger blocks sound good too (but I realize that they do come at a cost). If the overall transaction throughput increases but the fee income goes down for miners, I will be understanding but not too overly concerned with the miners welfare.

IMO the folks opposing segwit are not acting in bitcoin's best interest. The folks opposing big blocks are heavily optimizing against centralization. I think the latter are genuinely interested in doing the right thing but I wonder if they aren't being a little to zealous.

Re: Bitcoin's ASICBOOST Problem Explained [pdf]

#69

Post by stale2002 »

tlrobinson wrote: post #60

This might not be the place for this question, but can someone explain why we can't / shouldn't have both unlimited block sizes and SegWit? Block sizes will supposedly be constrained by bandwidth / propagation times. SegWit will allow more transactions to occur off chain, reducing the need for larger blocks. They seem complementary to me.

The Core team does not want blocksize increases.

They explicitly want prices to be high/number of transactions to be limited (think, supply and demand) .

This is because transaction "price" is equivalent to "amount of money spent on securing the blockchain".

Re: Bitcoin's ASICBOOST Problem Explained [pdf]

#70

Post by shea256 »

tlrobinson wrote: post #60

This might not be the place for this question, but can someone explain why we can't / shouldn't have both unlimited block sizes and SegWit? Block sizes will supposedly be constrained by bandwidth / propagation times. SegWit will allow more transactions to occur off chain, reducing the need for larger blocks. They seem complementary to me.

SegWit does in fact represent a block size increase. It results in 1.7x the # of single-signature transactions per block and 4x the # of multi-signature transactions per block.

Unlimited block size? There are many reasons that's a very bad idea but here are a few:

1. It would put immense pressure on the network in terms of latency between miners, leading to less stable mining, a higher rate of reorganizations, and a massive advantage for the larger miners, resulting in increased mining centralization.

2. It would result in a substantial increase in the amount of bandwidth that each node has to handle. Modest increases are OK but unlimited blocks means the vast majority of nodes will die off. Remember that nodes have to check blocks as they come in, so this would be an insane DDoS vector. Imagine putting a funnel in someone's mouth instead of a straw and being able to force whatever you want in there.

3. It would result in a substantial increase in the amount of data that each node has to store. Remember that in Bitcoin 100% of data must be stored by 100% of nodes. Imagine "unlimited emails" with Gmail meant that you had to store all of the emails in the world for EVERYONE. Not a good idea.

Post reply on HN