Re: [bitcoin-dev] We need to fix the block withholding attack

On 12/19/15, Emin Gün Sirer wrote: > > Chris Priest is confusing these attacks with selfish mining, and further, > his characterization of selfish mining is incorrect. Selfish Mining is > guaranteed to yield profits for any pool over 33% (as a result, Nick > Szabo has dubbed this the "34% attack")

Re: [bitcoin-dev] We need to fix the block withholding attack

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 witho

Re: [bitcoin-dev] We need to fix the block withholding attack

Chris Priest 於 2015-12-19 22:47 寫到: On 12/19/15, jl2012 wrote: Chris Priest via bitcoin-dev 於 2015-12-19 22:34 寫到: Block witholding attacks are only possible if you have a majority of hashpower. If you only have 20% hashpower, you can't do this attack. Currently, this attack is only a theoreti

Re: [bitcoin-dev] We need to fix the block withholding attack

Chris Priest via bitcoin-dev 於 2015-12-19 22:34 寫到: Block witholding attacks are only possible if you have a majority of hashpower. If you only have 20% hashpower, you can't do this attack. Currently, this attack is only a theoretical attack, as the ones with all the hashpower today are not engag

Re: [bitcoin-dev] We need to fix the block withholding attack

On 12/19/15, jl2012 wrote: > Chris Priest via bitcoin-dev 於 2015-12-19 22:34 寫到: >> Block witholding attacks are only possible if you have a majority of >> hashpower. If you only have 20% hashpower, you can't do this attack. >> Currently, this attack is only a theoretical attack, as the ones with

Re: [bitcoin-dev] We need to fix the block withholding attack

Then shouldn't this be something the pool deals with, not the bitcoin protocol? On 12/19/15, Matt Corallo wrote: > Peter was referring to pool-block-withholding, not selfish mining. > > On December 19, 2015 7:34:26 PM PST, Chris Priest via bitcoin-dev > wrote: >>Block witholding attacks are only

Re: [bitcoin-dev] Segregated witness softfork with moderate adoption has very small block size effect

By that same logic, any wallet that implemented P2SH is also voting for an increased block size, since P2SH results in smaller transactions, in the same way SW results in smaller transactions. On 12/19/15, Peter Todd via bitcoin-dev wrote: > On Sat, Dec 19, 2015 at 11:49:25AM -0500, jl2012 via bi

Re: [bitcoin-dev] We need to fix the block withholding attack

Peter was referring to pool-block-withholding, not selfish mining. On December 19, 2015 7:34:26 PM PST, Chris Priest via bitcoin-dev wrote: >Block witholding attacks are only possible if you have a majority of >hashpower. If you only have 20% hashpower, you can't do this attack. >Currently, this

Re: [bitcoin-dev] We need to fix the block withholding attack

Block witholding attacks are only possible if you have a majority of hashpower. If you only have 20% hashpower, you can't do this attack. Currently, this attack is only a theoretical attack, as the ones with all the hashpower today are not engaging in this behavior. Even if someone who had a lot of

Re: [bitcoin-dev] Segregated witness softfork with moderate adoption has very small block size effect

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 2015/12/19 08:49, jl2012 via bitcoin-dev wrote: > P2SH has been introduced for 3.5 years and only about 10% of > bitcoin is stored this way (I can't find proportion of existing > P2SH address). A 1-year adoption rate of 40% for segwit is clearly >

[bitcoin-dev] Fwd: Block size: It's economics & user preparation & moral hazard

Appealing moderator's decision. If my post was off-topic, then so is the whole thread. As for content-heavy, I made a very specific compromise proposal that I'd like to bring to the developers attention. If this isn't the place to do that, then I don't know what is, but I'd be happy to repost to a

Re: [bitcoin-dev] Segregated Witness in the context of Scaling Bitcoin

A couple observations: - The consensus block limit is different than the disk space required to do validation. Some participants are worried about one and some about the other, and sometimes they feel what amounts to an imaginary contention because they perceive these two different th

Re: [bitcoin-dev] We need to fix the block withholding attack

After the meeting I find a softfork solution. It is very inefficient and I am leaving it here just for record. 1. In the first output of the second transaction of a block, mining pool will commit a random nonce with an OP_RETURN. 2. Mine as normal. When a block is found, the hash is concatena

Re: [bitcoin-dev] We need to fix the block withholding attack

Peter Todd via bitcoin-dev [bitcoin-dev@lists.linuxfoundation.org] wrote: > One of the issues raised by the pools present was block withholding > attacks, which they said are a real issue for them. In particular, pools > are receiving legitimate threats by bad actors threatening to use block > with

Re: [bitcoin-dev] Segregated witness softfork with moderate adoption has very small block size effect

I disagree. I think all client-side adoption of SW reliably tells you is that those implementers saw value in it greater than the cost of implementation. It's possible what they valued was the malleability fix and didn't see the limited potential circumvention of MAX_BLOCK_SIZE material to their

Re: [bitcoin-dev] Block size: It's economics & user preparation & moral hazard

I've already publicly declared that I offer one bitcoin to "those who suffer from a May 5, 2016 hardfork to 2MB blocks" but that's probably way too sloppy. Here's a better idea that transmits the economic power of merchants and customers (well, anyone with bitcoin) to the miners on whom they must

Re: [bitcoin-dev] Segregated witness softfork with moderate adoption has very small block size effect

On Sat, Dec 19, 2015 at 09:37:06PM +0300, Santino Napolitano wrote: > I disagree. I think all client-side adoption of SW reliably tells you is that > those implementers saw value in it greater than the cost of implementation. > It's possible what they valued was the malleability fix and didn't se

[bitcoin-dev] We need to fix the block withholding attack

At the recent Scaling Bitcoin conference in Hong Kong we had a chatham house rules workshop session attending by representitives of a super majority of the Bitcoin hashing power. One of the issues raised by the pools present was block withholding attacks, which they said are a real issue for them.

Re: [bitcoin-dev] The increase of max block size should be determined by block height instead of block time

On Sat, Dec 19, 2015 at 03:17:03AM +0800, Chun Wang via bitcoin-dev wrote: > In many BIPs we have seen, include the latest BIP202, it is the block > time that determine the max block size. From from pool's point of > view, it cannot issue a job with a fixed ntime due to the existence of > ntime rol

Re: [bitcoin-dev] Segregated witness softfork with moderate adoption has very small block size effect

On 12/19/2015 10:49 AM, jl2012 via bitcoin-dev wrote: > I am not convinced that SW softfork should be the *only* short term > scalability solution I don't think SW is relevant at all with respect to scalability. Fraud proofs are extremely important from a security perspective. The network as it e

Re: [bitcoin-dev] On the security of softforks

On Fri, Dec 18, 2015 at 2:47 AM, Jonathan Toomim via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > > On Dec 18, 2015, at 10:30 AM, Pieter Wuille via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > > 1) The risk of an old full node wallet accepting a transaction that

Re: [bitcoin-dev] Segregated witness softfork with moderate adoption has very small block size effect

On Sat, Dec 19, 2015 at 11:49:25AM -0500, jl2012 via bitcoin-dev wrote: > I have done some calculation for the effect of a SW softfork on the > actual total block size. Note how the fact that segwit needs client-side adoption to enable an actual blocksize increase can be a good thing: it's a clear

[bitcoin-dev] Segregated witness softfork with moderate adoption has very small block size effect

I have done some calculation for the effect of a SW softfork on the actual total block size. Definitions: Core block size (CBS): The block size as seen by a non-upgrading full node Witness size (WS): The total size of witness in a block Total block size (TBS): CBS + WS Witness discount (WD):

Re: [bitcoin-dev] On the security of softforks

On Fri, Dec 18, 2015 at 6:18 AM, Peter Todd via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Anyway, we should write this up as a BIP - there's been a tremendous > amount of misinformation, even flat out lies, floating around on this > subject. > Er, this sounds like something th

Re: [bitcoin-dev] On the security of softforks

On Dec 18, 2015, at 10:30 AM, Pieter Wuille via bitcoin-dev > wrote: 2) The risk of an old full node wallet accepting a transaction whose coins passed through a script that depends on the softforked rules. There's that, but there's also a case where

Re: [bitcoin-dev] The increase of max block size should be determined by block height instead of block time

On Fri, 2015-12-18 at 15:15 -0500, Jeff Garzik via bitcoin-dev wrote: > My preference is height activation + one step per block (i.e. also > height). Height seems KISS. > > Under this scheme the size of the step-per-block increase could be decreased every 210,000 blocks (at time of reward halvin