Re: [bitcoin-dev] Scaling Bitcoin conference micro-report

2015-09-19 Thread Mike Hearn via bitcoin-dev
> > Let me get this straight. You start this whole debate with a "kick the can > down the road" proposal to increase the block size to 20MB, which obviously > would require another hard fork in the future, but if someone else proposes > a similar "kicka the can" proposal you will outright reject

Re: [bitcoin-dev] Scaling Bitcoin conference micro-report

2015-09-19 Thread Dave Scotese via bitcoin-dev
phm got most of this, but... On Sat, Sep 19, 2015 at 2:53 PM, phm via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Mike Hearn via bitcoin-dev wrote: > > > > > * Most governments can easily spend enough money to do a 51% attack, > > especially if they can compel chip fabs

Re: [bitcoin-dev] Hash of UTXO set as consensus-critical

2015-09-19 Thread Rune K. Svendsen via bitcoin-dev
An honest miner is a miner that supports the network by building on top of the best valid chain. A malicious miner is one who wants to disrupt the Bitcoin network, not support it, for example by executing a 51% attack which mines empty blocks on top of the best chain. /Rune > Den 19/09/2015

Re: [bitcoin-dev] Scaling Bitcoin conference micro-report

2015-09-19 Thread Mike Hearn via bitcoin-dev
> > Your argument is that the state is not a threat to a system designed to > deprive the state of seigniorage, because the state will see that system > as too important? > And so we get to one of the hearts of the debate. The axiom upon which you and NxtChg disagree is this: he/she believes

Re: [bitcoin-dev] Scaling Bitcoin conference micro-report

2015-09-19 Thread NxtChg via bitcoin-dev
>While to many of us that sounds crazy, if you're threat model assumes >Bitcoin is a legal/regulated service provided by a highly trusted mining >community it's a reasonable design. There is a large, grey area all the way to "legal/regulated service provided by a highly trusted mining

Re: [bitcoin-dev] Scaling Bitcoin conference micro-report

2015-09-19 Thread NxtChg via bitcoin-dev
>Your vision of censorship resistance is to become such a strong >central authority that you can resist it in direct physical confrontation. >If you succeed at this, you are the threat. My vision is a strong _decentralized_ system, which is: a) too important to close, b) able to provide

Re: [bitcoin-dev] Scaling Bitcoin conference micro-report

2015-09-19 Thread Eric Voskuil via bitcoin-dev
On 09/18/2015 11:06 PM, NxtChg via bitcoin-dev wrote: >> While to many of us that sounds crazy, if you're threat model assumes >> Bitcoin is a legal/regulated service provided by a highly trusted >> mining community it's a reasonable design. > > There is a large, grey area all the way to

Re: [bitcoin-dev] Scaling Bitcoin conference micro-report

2015-09-19 Thread Eric Voskuil via bitcoin-dev
On 09/19/2015 12:57 AM, NxtChg wrote:> >> Your vision of censorship resistance is to become such a strong >> central authority that you can resist it in direct physical >> confrontation. If you succeed at this, you are the threat. > > My vision is a strong _decentralized_ system, which is: > >

Re: [bitcoin-dev] Fill-or-kill transaction

2015-09-19 Thread Tom Harding via bitcoin-dev
On 9/17/2015 8:27 PM, jl2012 via bitcoin-dev wrote: > However, requiring 100 block maturity will unfortunately make the > system much less appealing since the recipient may not like it. The maturity requirement can be dropped if the expiration height is more that 100 blocks after inclusion

Re: [bitcoin-dev] Scaling Bitcoin conference micro-report

2015-09-19 Thread NxtChg via bitcoin-dev
>Your argument is that the state is not a threat to a system >designed to deprive the state of seigniorage, because the state will see that >system as too important? Well, if you look at governments from the point of youtube illuminati videos, then, yeah, I guess my position would seem a bit

Re: [bitcoin-dev] Hash of UTXO set as consensus-critical

2015-09-19 Thread Rune Kjær Svendsen via bitcoin-dev
We need to distinguish between two different things here: 1) A 51% attack, where the majority of mining power is *malicious* (hence “attack”) and 2) A fork that exists because of a disagreement in the network, with total mining power split in two camps, each camp mining peacefully on their

Re: [bitcoin-dev] Scaling Bitcoin conference micro-report

2015-09-19 Thread cipher anthem via bitcoin-dev
Let me get this straight. You start this whole debate with a "kick the can down the road" proposal to increase the block size to 20MB, which obviously would require another hard fork in the future, but if someone else proposes a similar "kicka the can" proposal you will outright reject it?