Coinbase reallocation to discourage Finney attacks

Lately someone launched Finney attacks as a service (BitUndo). As a reminder for newcomers, Finney attacks are where a miner secretly works on a block containing a double spend. When they eventually find a block, they run to the merchant and pay, then broadcast the block. In a simpler variant of this attack you make purchases as normal with a modified wallet that always submits a double spend to the service, and then N% of the time where N is the percentage of overall hash power the dishonest miners have, you get your money back minus their fee.

N does not need to be very high to render Bitcoin much less useful. Real time transactions are very important. Although I never expected it when I first started using Bitcoin, nowadays most of my purchases with it are for food and drink. If Bitcoin could not support such purchases, I would use it much less. Even with their woeful security many merchants see <1-2% credit card chargeback rates, and chargebacks can be disputed. In fact merchants win about 40% of chargeback disputes. So if N was only, say, 5%, and there was a large enough population of users who were systematically trying to defraud merchants, we'd already be having worse security than magstripe credit cards. EMV transactions have loss rates in the noise, so for merchants who take those Bitcoin would be dramatically less secure.

The idea of discouraging blocks that perform Finney attacks by having honest miners refuse to build on them has been proposed. But it has a couple of problems:

   1. It's hard to automatically detect Finney attacks. Looking for blocks
   that contain unseen transactions that override the mempool doesn't work -
   the dishonest users could broadcast all their double spends once a Finney
   block was found and then broadcast the block immediately afterwards, thus
   making the block look like any other would in the presence of double spends.

   2. If they could be automatically identified, it possibly could be
   converted into a DoS on the network by broadcasting double spends in such a
   way that the system races, and every miner produces a block that looks like
   a Finney attack to some of the others. The chain would stop advancing.

   3. Miners who want to vote "no" on a block take a big risk, they could
   be on the losing side of the fork and end up wasting their work.

We can resolve these problems with a couple of tweaks:

   1. Dishonest blocks can be identified out of band, by having honest
   miners submit double spends against themselves to the service anonymously
   using a separate tool. When their own double spend appears they know the
   block is bad.

   2. Miners can vote to reallocate the coinbase value of bad blocks before
   they mature. If a majority of blocks leading up to maturity vote for
   reallocation, the value goes into a pot that subsequent blocks are allowed
   to claim for themselves. Thus there is no risk to voting "no" on a block,
   the work done by the Finney attacker is not wasted, and users do not have
   to suffer through huge reorgs.

This may seem a radical suggestion, but I think it's much less radical than some of the others being thrown around.

The above approach works as long as the majority of hashpower is honest, defined to mean, working to stop double spending. This is the same security property as described in the white paper, thus this introduces no new security assumptions. Note that assuming *all* miners are dishonest and are willing to double spend automatically resolves the Bitcoin experiment as a failure, because that would invalidate the entire theory upon which the system is built. That doesn't mean the assumption is wrong! It may be that an entirely unregulated market for double spending prevention cannot work and the participants eventually all end up trashing the commons - but the hope is that smart incentives can replace the traditional reliance on law and regulation to avoid this.

The voting mechanism would only apply to coinbases, not arbitrary transactions, thus it cannot be used to steal arbitrary users bitcoins. A majority of miners can already reallocate coinbases by forking them out, but this wastes energy and work presenting a significant discouragement to vote unless you already know via some out of band mechanism that you have a solid majority. Placing votes into the coinbase scriptSig as is done with other things avoids that problem.

The identification of Finney blocks relies on miners to take explicit action, like downloading and running a tool that submits votes via RPC. It can be expected that double spending services would try to identify and block the sentinel transactions, which is why it's better to have the code that fights this arms race be out of process and developed externally to Bitcoin Core itself, which should ultimately just enforce the new (forking) rule change.

On Wednesday 23 Apr 2014 08:55:30 Mike Hearn wrote:

> Even with their woeful security many merchants see <1-2% credit card
> chargeback rates, and chargebacks can be disputed. In fact merchants win
> about 40% of chargeback disputes. So if N was only, say, 5%, and there
> was a large enough population of users who were systematically trying to
> defraud merchants, we'd already be having worse security than magstripe
> credit cards. EMV transactions have loss rates in the noise, so for
> merchants who take those Bitcoin would be dramatically less secure.

Just pedantry: 100% of credit card transactions _can_ be fradulantly charged back but arent. In fact, only 2% are ever attempted.

If N was 5%, then only 5% of bitcoin transactions _could_ be fraudulantly "charged back"; so then why wouldn't only 2% of those bitcoin transactions be fraudulant too, just as in the CC case?

The comparison would then be 2% chargebacks for credit cards, equivalent to 0.1% (5%*2%) for bitcoin.

Not that I think that makes anything else you say invalid.

Andy

>
> Just pedantry: 100% of credit card transactions _can_ be fradulantly
> charged
> back but arent.
>

If you do a chargeback the bank double checks this, investigates it and people who repeatedly try and do fraudulent chargebacks get their accounts terminated. It's not like your bank offers you a "reverse this payment" button in the UI that always works, right?

> If N was 5%, then only 5% of bitcoin transactions _could_ be fraudulantly
> "charged back"; so then why wouldn't only 2% of those bitcoin transactions
> be fraudulant too, just as in the CC case?
>

If you attempt fraud against a bank, they know who you are and will come after you in one way or another. But it's safe to assume that users of a double spend service would be anonymous and the kind of merchants they go after are not hassling their customers with strong ID checks, so there would be no consequences for them. It's a game they can only win.

On Wednesday 23 Apr 2014 12:07:25 Mike Hearn wrote:

> > Just pedantry: 100% of credit card transactions _can_ be fradulantly
> > charged
> > back but arent.
>
> If you do a chargeback the bank double checks this, investigates it and
> people who repeatedly try and do fraudulent chargebacks get their
> accounts terminated. It's not like your bank offers you a "reverse this
> payment" button in the UI that always works, right?

True; the effort of a chargeback is non-zero on credit cards; but that's my point: it's non-zero for bitcoin too.

> > If N was 5%, then only 5% of bitcoin transactions _could_ be
> > fraudulantly "charged back"; so then why wouldn't only 2% of those
> > bitcoin transactions be fraudulant too, just as in the CC case?
>
> If you attempt fraud against a bank, they know who you are and will come
> after you in one way or another. But it's safe to assume that users of a
> double spend service would be anonymous and the kind of merchants they go
> after are not hassling their customers with strong ID checks, so there
> would be no consequences for them. It's a game they can only win.

You're still being unfair to bitcoin. Not everyone who uses bitcoins will be dishonest. The dishonest 5% hashing power is not going to be used in 100% of any given merchants transactions. That's all I'm saying. You're original statement that we could end up in a position that bitcoin has a higher failure rate than credit cards seems unfair to me.

> if N was only, say, 5%, and there was a large enough population of users

who were systematically trying to defraud merchants, we'd already be having worse security than magstripe credit cards.

"[If] there was a large enough population" -- why are bitcoin users more dishonest than credit card users? Most people are honest, so it seems unlikely that that 5% attack surface would be used at 100%; or even 40% necessary to equal the 2% chargeback rate with CC.

I really didn't want to get into an argument over this: all I'm saying is that things aren't as bad as you painted them.

Andy

>
> You're still being unfair to bitcoin.  Not everyone who uses bitcoins will
> be dishonest.  The dishonest 5% hashing power is not going to be used in
> 100% of any given merchants transactions.
>

OK, sure, let's say most Bitcoin users will be honest (we hope). But unfortunately in a situation where fraud is possible users wouldn't necessarily distribute evenly over transactions.

Back when I worked on Gmail, we did a little study where we selected a random subset of email accounts from Nigeria and waited to see if they received abuse reports, showed up on dating site blacklists etc. It turned out about 2/3rds of them did. This obviously doesn't imply that 2/3rds of all Nigerians are scammers, but unfortunately the few that are are responsible for a disproportionate number of account creations.

If a merchant is selling something of value repeatedly, then a small number of scammers can go back and try their luck over and over. I'm not sure how many trades fall into such an exploitable category, though.

Also, there's the philosophical question of how honest people really are when there's no consequences to their actions. For instance, if most people were honest, then piracy would be not a big problem. But game studios that have cracked DRM quite often report piracy rates of 95%, i.e. for every 5 sales they make, they get 100 people playing on their servers - the vast majority of their users are not honest.

Just a few issues with the idea as it currently stands:

1. This provides a very strong incentive to always vote for
reallocating a block if it isn't yours, regardless of whether it's bad
or not (there's a positive expected return to voting to reallocate
coinbases from other miners). The incentive is bigger the more hash
power you have. You can partially address this by:
    a) Requiring supermajorities
    b) Requiring a vote to include proof of a double spend (that's not
a very strong safeguard, since anyone can create them after the fact
if one of their own transactions has been included).
    c) Burning, rather than reallocating, the coins. Miners' immediate
incentive to attack honest pools is much reduced.

2. BitUndo gets paid using additional txouts in the double-spend transaction, no by miner's fees. This means that the coinbase transaction will represent a smaller and smaller share of their revenues over time (however if the total honest transaction fees they get in their block are high enough, the risk of losing those might still be enough).

On Wed, Apr 23, 2014 at 3:55 AM, Mike Hearn <mike@plan99•net> wrote:

> Lately someone launched Finney attacks as a service (BitUndo). As a reminder
> for newcomers, Finney attacks are where a miner secretly works on a block
> containing a double spend. When they eventually find a block, they run to
> the merchant and pay, then broadcast the block. In a simpler variant of this
> attack you make purchases as normal with a modified wallet that always
> submits a double spend to the service, and then N% of the time where N is
> the percentage of overall hash power the dishonest miners have, you get your
> money back minus their fee.
>
> N does not need to be very high to render Bitcoin much less useful. Real
> time transactions are very important. Although I never expected it when I
> first started using Bitcoin, nowadays most of my purchases with it are for
> food and drink. If Bitcoin could not support such purchases, I would use it
> much less.
> Even with their woeful security many merchants see <1-2% credit card
> chargeback rates, and chargebacks can be disputed. In fact merchants win
> about 40% of chargeback disputes. So if N was only, say, 5%, and there was a
> large enough population of users who were systematically trying to defraud
> merchants, we'd already be having worse security than magstripe credit
> cards. EMV transactions have loss rates in the noise, so for merchants who
> take those Bitcoin would be dramatically less secure.
>
> The idea of discouraging blocks that perform Finney attacks by having honest
> miners refuse to build on them has been proposed. But it has a couple of
> problems:
>
> It's hard to automatically detect Finney attacks. Looking for blocks that
> contain unseen transactions that override the mempool doesn't work - the
> dishonest users could broadcast all their double spends once a Finney block
> was found and then broadcast the block immediately afterwards, thus making
> the block look like any other would in the presence of double spends.
>
> If they could be automatically identified, it possibly could be converted
> into a DoS on the network by broadcasting double spends in such a way that
> the system races, and every miner produces a block that looks like a Finney
> attack to some of the others. The chain would stop advancing.
>
> Miners who want to vote "no" on a block take a big risk, they could be on
> the losing side of the fork and end up wasting their work.
>
> We can resolve these problems with a couple of tweaks:
>
> Dishonest blocks can be identified out of band, by having honest miners
> submit double spends against themselves to the service anonymously using a
> separate tool. When their own double spend appears they know the block is
> bad.
>
> Miners can vote to reallocate the coinbase value of bad blocks before they
> mature. If a majority of blocks leading up to maturity vote for
> reallocation, the value goes into a pot that subsequent blocks are allowed
> to claim for themselves. Thus there is no risk to voting "no" on a block,
> the work done by the Finney attacker is not wasted, and users do not have to
> suffer through huge reorgs.
>
> This may seem a radical suggestion, but I think it's much less radical than
> some of the others being thrown around.
>
> The above approach works as long as the majority of hashpower is honest,
> defined to mean, working to stop double spending. This is the same security
> property as described in the white paper, thus this introduces no new
> security assumptions. Note that assuming all miners are dishonest and are
> willing to double spend automatically resolves the Bitcoin experiment as a
> failure, because that would invalidate the entire theory upon which the
> system is built. That doesn't mean the assumption is wrong! It may be that
> an entirely unregulated market for double spending prevention cannot work
> and the participants eventually all end up trashing the commons - but the
> hope is that smart incentives can replace the traditional reliance on law
> and regulation to avoid this.
>
> The voting mechanism would only apply to coinbases, not arbitrary
> transactions, thus it cannot be used to steal arbitrary users bitcoins. A
> majority of miners can already reallocate coinbases by forking them out, but
> this wastes energy and work presenting a significant discouragement to vote
> unless you already know via some out of band mechanism that you have a solid
> majority. Placing votes into the coinbase scriptSig as is done with other
> things avoids that problem.
>
> The identification of Finney blocks relies on miners to take explicit
> action, like downloading and running a tool that submits votes via RPC. It
> can be expected that double spending services would try to identify and
> block the sentinel transactions, which is why it's better to have the code
> that fights this arms race be out of process and developed externally to
> Bitcoin Core itself, which should ultimately just enforce the new (forking)
> rule change.
>
>
>
> ------------------------------------------------------------------------------
> Start Your Social Network Today - Download eXo Platform
> Build your Enterprise Intranet with eXo Platform Software
> Java Based Open Source Intranet - Social, Extensible, Cloud Ready
> Get Started Now And Turn Your Intranet Into A Collaboration Platform
> http://p.sf.net/sfu/ExoPlatform
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge•net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

On Wed, Apr 23, 2014 at 2:43 PM, Christophe Biocca < christophe.biocca@gmail•com> wrote:

> 1. This provides a very strong incentive to always vote for
> reallocating a block if it isn't yours

If everyone votes to reallocate everyone elses blocks all the time, then you'd end up losing your own coins too, so this doesn't seem like a workable strategy.

>     a) Requiring supermajorities
>     c) Burning, rather than reallocating, the coins. Miners' immediate
> incentive to attack honest pools is much reduced.
>

I'm OK with burning actually. The total amount of coins in the system essentially defines its maximum price resolution. Ideally we'd not lose resolution, but it's less important than having a system that does actually work. Moreover, this sort of system is like double spending defence itself - if it does work, it doesn't need to actually be done very frequently because people know the safeguards work and don't try. So in practice total loss of resolution should be limited.

> 2. BitUndo gets paid using additional txouts in the double-spend
> transaction, no by miner's fees.

Right. It's indeed an assumption that block rewards matter to miners, even the ones that have double spend revenues.

On Wednesday 23 Apr 2014 12:45:34 Mike Hearn wrote:

> OK, sure, let's say most Bitcoin users will be honest (we hope). But
> unfortunately in a situation where fraud is possible users wouldn't
> necessarily distribute evenly over transactions.

That's true, but even in the worst that that 5% hashing power attack means that 95% of the time, your attack fails. That means you end up paying for what you bought. Also, you're again changing the comparison basis -- your CC figures were for the entire industry, not the most badly affected merchant. You can't say "one particular bitcoin merchant suffers 5% fraud, therefore that's worse than the 2% fraud averaged across all CC merchants".

> If a merchant is selling something of value repeatedly, then a small
> number of scammers can go back and try their luck over and over. I'm not
> sure how many trades fall into such an exploitable category, though.
>
> Also, there's the philosophical question of how honest people really are
> when there's no consequences to their actions. For instance, if most

There _are_ consequences though: 95% of the time, you end up buying something and paying for it.

Viewed another way, if I buy something repeatedly from an at risk merchant (and there won't be many; as you pointed out, mail order is completely unaffected as you can simply wait for your confirmations) that costs, say 0.01 BTC per item, then I have to buy 100 of them to get 5 of them for free. Do I really want 100 of them? Even if I do want them, then I've had to supply capital of 1 BTC to earn 0.05 BTC in kind.

If what I'm buying is another form of money (as with exchanges, or perhaps casinos) when that "in kind" is just as liquid as the BTC, then fair enough, there is a risk, but that just incentivises the merchant in those cases to not allow withdrawal/deposit until 6 confirmations have been received. Those merchants then move from "at risk" to "not at risk".

I'm still struggling to see how bitcoin could ever be as bad as CC fraud.

Andy

>
> There _are_ consequences though: 95% of the time, you end up buying
> something and paying for it.

Yeah, I was imagining a situation in which people who use Bitcoin regularly do buy things they actually want, but wouldn't say no to occasionally getting them for free (think coffees at starbucks etc). So if their double spend fails, no big deal, they're no worse off than if they didn't try.

On 04/23/2014 07:55 AM, Mike Hearn wrote:

> 2. Miners can vote to reallocate the coinbase value of bad blocks
> before they mature. If a majority of blocks leading up to maturity
> vote for reallocation, the value goes into a pot that subsequent
> blocks are allowed to claim for themselves. Thus there is no risk
> to voting "no" on a block, the work done by the Finney attacker is
> not wasted, and users do not have to suffer through huge reorgs.

If enough miners don't like a block that has been mined, they can all work to orphan it without any change to the protocol whatsoever.

Why are proposing this a change to the network that allows miners to vote to disregard output scripts, instead of creating an out of band network via which miners can coordinate actions using the capabilities the protocol already allows?

Once you've changed the network such that it is no longer a machine that faithfully processes scripts, and instead is a machine via which a set of controllers can decide which valid scripts will be honored and which ones will not, what will be the next proposed condition under which the miners can confiscate and redistribute balances?

- -- Support online privacy by using email encryption whenever possible. Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k

This is outright ridiculous.

Zero-confirmation double-spending is a small problem, and possible solutions are known. (E.g. trusted third party + multi-sig addresses for small-value transactions.)

On the other hand, protocol changes like described above might have game-theoretical implications which are non-trivial and hard to understand.

The above approach works as long as the majority of hashpower is honest,

> defined to mean, working to stop double spending. This is the same security
> property as described in the white paper, thus this introduces no new
> security assumptions.
>

No. Bitcoin should work if miners are merely individually rational, i.e. they try to maximize their pay-offs without colluding with others.

I guess word "honest" might have different meanings, that can be a source of confusing. 1. Honest -- not trying to destroy bitcoin 2. Honest -- following rules which are not required by the protocol

On Wed, Apr 23, 2014 at 4:52 PM, Justus Ranvier <justusranvier@gmail•com>wrote:

> If enough miners don't like a block that has been mined, they can all
> work to orphan it without any change to the protocol whatsoever.
>

As was already pointed out, yes. However this requires them to immediate establish a majority consensus and be absolutely sure it really is the majority. You suggest an out of band mechanism for that, but why is this better than using the actual consensus mechanism you're trying to measure?

> Once you've changed the network such that it is no longer a machine
> that faithfully processes scripts

Bitcoin imposes far more rules than just execution of the scripting language, many of which are entirely arbitrary and the result of (controversial) human judgement, like the inflation schedule. You can't claim Bitcoin implements only some kind of natural law.

>
> No. Bitcoin should work if miners are merely individually rational, i.e.
> they try to maximize their pay-offs without colluding with others.
>

And it still would. Non-collusive miners cast votes based on the outcome of their own attempts to double spend. If enough agree then they all agree that the vote is binding.

> I guess word "honest" might have different meanings, that can be a source
> of confusing.
> 1. Honest -- not trying to destroy bitcoin
> 2. Honest -- following rules which are not required by the protocol
>

I'm using it in the same sense Satoshi used it. Honest miners work to prevent double spends. That's the entire justification for their existence. Miners that are deliberately trying to double spend are worse than useless.

On Wed, Apr 23, 2014 at 06:04:00PM +0300, Alex Mizrahi wrote:

> This is outright ridiculous.
>
> Zero-confirmation double-spending is a small problem, and possible
> solutions are known. (E.g. trusted third party + multi-sig addresses for
> small-value transactions.)

Also replace-by-fee scorched earth.

> On the other hand, protocol changes like described above might have
> game-theoretical implications which are non-trivial and hard to understand.

To put it mildly. :) Beyond the obvious issues with adding mechanisms for miners to vote on what blacklists they wish to apply, it's interesting to consider how trying to make zeroconf transactions secure directly is quite close to changing the block interval. Like the blocksize that's a fundemental economic parameter of the system - how low-latency and well connected you must be to be allowed to mine. Even in a scheme where the punishment for allowing a double-spend was somehow applied perfectly fairly, you'd still be favoring large well-connected miners in a very similar way to reducing the block interval.

> The above approach works as long as the majority of hashpower is honest,
> > defined to mean, working to stop double spending. This is the same security
> > property as described in the white paper, thus this introduces no new
> > security assumptions.
> >
>
> No. Bitcoin should work if miners are merely individually rational, i.e.
> they try to maximize their pay-offs without colluding with others.

It's worth noting that the academic efforts studying Bitcoin are spending quite a bit of effort focused on the incentive compatibility of various mechanisms in the protocol: https://github.com/citp/bitcoin-sok/issues/5

There's solid consensus in the academic community that Bitcoin can't just depend on notions of "honesty" to work.

> I guess word "honest" might have different meanings, that can be a source
> of confusing.
> 1. Honest -- not trying to destroy bitcoin
> 2. Honest -- following rules which are not required by the protocol

What exactly those rules are is up for debate too. Right now if, say, just 5% of Bitcoin miners were willing to accept Colored Coin transactions you could still use Colored Coins. The other 95% may want to block said transactions, but there's huge practical difficulties in organizing a reorg and ensuring that everyone co-operates; miners have strong incentives to defect if the consensus isn't assured as any miners attempting to reorg are wasting their hashing power if it doesn't succeed.

OTOH with a voting scheme the cost to propose that a specific block or a transaction be blacklisted is much lower. In Mike's proposed scheme to not just blacklist, but actually take coinbases it's downright profitable. Rather than being a last resort option, it'll be easy for miners to propose various things be blacklisted, if the vote goes through, great, if it doesn't, no harm done. Obviously that makes blacklists into a much more useful tool and greatly changes the political landscape around them.

Remember, if you're operating a publicly known pool, and there's a voting mechanism available to you to blacklist specific blocks, how are you going to resist pressure from your local authorities to do just when there's no cost to you to do so?

On 4/23/2014 3:55 AM, Mike Hearn wrote:

> Lately someone launched Finney attacks as a service (BitUndo). As a
> reminder for newcomers, Finney attacks are where a miner secretly
> works on a block containing a double spend. When they eventually find
> a block, they run to the merchant and pay, then broadcast the block.
> In a simpler variant of this attack you make purchases as normal with
> a modified wallet that always submits a double spend to the service,
> and then N% of the time where N is the percentage of overall hash
> power the dishonest miners have, you get your money back minus their fee.
>
> N does not need to be very high to render Bitcoin much less useful.
> Real time transactions are very important. Although I never expected
> it when I first started using Bitcoin, nowadays most of my purchases
> with it are for food and drink. If Bitcoin could not support such
> purchases, I would use it much less.
> Even with their woeful security many merchants see <1-2% credit card
> chargeback rates, and chargebacks can be disputed. In fact merchants
> win about 40% of chargeback disputes. So if N was only, say, 5%, and
> there was a large enough population of users who were systematically
> trying to defraud merchants, we'd already be having worse security
> than magstripe credit cards. EMV transactions have loss rates in the
> noise, so for merchants who take those Bitcoin would be dramatically
> less secure.
>
> The idea of discouraging blocks that perform Finney attacks by having
> honest miners refuse to build on them has been proposed. But it has a
> couple of problems:
>
>  1. It's hard to automatically detect Finney attacks. Looking for
>     blocks that contain unseen transactions that override the mempool
>     doesn't work - the dishonest users could broadcast all their
>     double spends once a Finney block was found and then broadcast the
>     block immediately afterwards, thus making the block look like any
>     other would in the presence of double spends.
>
>  2. If they could be automatically identified, it possibly could be
>     converted into a DoS on the network by broadcasting double spends
>     in such a way that the system races, and every miner produces a
>     block that looks like a Finney attack to some of the others. The
>     chain would stop advancing.
>
>  3. Miners who want to vote "no" on a block take a big risk, they
>     could be on the losing side of the fork and end up wasting their work.
>
> We can resolve these problems with a couple of tweaks:
>
>  1. Dishonest blocks can be identified out of band, by having honest
>     miners submit double spends against themselves to the service
>     anonymously using a separate tool. When their own double spend
>     appears they know the block is bad.
>
>  2. Miners can vote to reallocate the coinbase value of bad blocks
>     before they mature. If a majority of blocks leading up to maturity
>     vote for reallocation, the value goes into a pot that subsequent
>     blocks are allowed to claim for themselves. Thus there is no risk
>     to voting "no" on a block, the work done by the Finney attacker is
>     not wasted, and users do not have to suffer through huge reorgs.
>
> This may seem a radical suggestion, but I think it's much less radical
> than some of the others being thrown around.
>
> The above approach works as long as the majority of hashpower is
> honest, defined to mean, working to stop double spending. This is the
> same security property as described in the white paper, thus this
> introduces no new security assumptions. Note that assuming
> /all/ miners are dishonest and are willing to double spend
> automatically resolves the Bitcoin experiment as a failure, because
> that would invalidate the entire theory upon which the system is
> built. That doesn't mean the assumption is wrong! It may be that an
> entirely unregulated market for double spending prevention cannot work
> and the participants eventually all end up trashing the commons - but
> the hope is that smart incentives can replace the traditional reliance
> on law and regulation to avoid this.
>
> The voting mechanism would only apply to coinbases, not arbitrary
> transactions, thus it cannot be used to steal arbitrary users
> bitcoins. A majority of miners can already reallocate coinbases by
> forking them out, but this wastes energy and work presenting a
> significant discouragement to vote unless you already know via some
> out of band mechanism that you have a solid majority. Placing votes
> into the coinbase scriptSig as is done with other things avoids that
> problem.
>
> The identification of Finney blocks relies on miners to take explicit
> action, like downloading and running a tool that submits votes via
> RPC. It can be expected that double spending services would try to
> identify and block the sentinel transactions, which is why it's better
> to have the code that fights this arms race be out of process and
> developed externally to Bitcoin Core itself, which should ultimately
> just enforce the new (forking) rule change.
>
>
>
>
> ------------------------------------------------------------------------------
> Start Your Social Network Today - Download eXo Platform
> Build your Enterprise Intranet with eXo Platform Software
> Java Based Open Source Intranet - Social, Extensible, Cloud Ready
> Get Started Now And Turn Your Intranet Into A Collaboration Platform
> http://p.sf.net/sfu/ExoPlatform
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge•net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

I have some questions: 1. How can we work towards solving the double-spending problem? 2. Is it possible to "scan" for double-spending and correct it? 3. Is the network at large not secure enough?

> And it still would. Non-collusive miners cast votes based on the outcome
> of their own attempts to double spend.
>

Individually rational strategy is to vote for coinbase reallocation on every block.

Yes, in that case nobody will get reward. It is similar to prisoner's dilemma: equilibrium has worst pay-off. In practice that would mean that simple game-theoretic models are no longer applicable, as they lead to absurd results.

> I'm using it in the same sense Satoshi used it. Honest miners work to
> prevent double spends. That's the entire justification for their existence.
> Miners that are deliberately trying to double spend are worse than useless.
>

Miners work to get rewards. It absolutely doesn't matter whether they are deliberately trying to double-spend or not: they won't be able to double-spend without a collusion.

On Wed, Apr 23, 2014 at 5:34 PM, Kevin <kevinsisco61784@gmail•com> wrote:

> I have some questions:
> 1.  How can we work towards solving the double-spending problem?

We have this awesome technology that solves the double-spending problem. It's called a blockchain. Of course, it only works when transactions are actually in a block.

This issue is about double-spending preventing before they're confirmed. This is (and has always been) just a best-effort mechanism in the network.

> 2.  Is it possible to "scan" for double-spending and correct it?

That is what is being proposed here, by introducing a mechanism where miners can vote to penalize other miners if they seem to allow (too many?) double spends.

> 3.  Is the network at large not secure enough?

Not very relevant.

On Wed, Apr 23, 2014 at 05:41:26PM +0200, Pieter Wuille wrote:

> On Wed, Apr 23, 2014 at 5:34 PM, Kevin <kevinsisco61784@gmail•com> wrote:
> > I have some questions:
> > 1.  How can we work towards solving the double-spending problem?
>
> We have this awesome technology that solves the double-spending
> problem. It's called a blockchain. Of course, it only works when
> transactions are actually in a block.
>
> This issue is about double-spending preventing before they're
> confirmed. This is (and has always been) just a best-effort mechanism
> in the network.
>
> > 2.  Is it possible to "scan" for double-spending and correct it?
>
> That is what is being proposed here, by introducing a mechanism where
> miners can vote to penalize other miners if they seem to allow (too
> many?) double spends.

Worse, it's a mechanism where miners can vote to penalize other miners for any reason at all. Nothing in the mechanism requires any proof that a double-spend happened, nor can it. Even if you require the simple "two signatures for same output" mechanism, that just proves the existance of a second signature, and says nothing at all about whether or not that signature was ever broadcast on any network.

It's not necessary that this "coinbase retribution" be either profitable or risk-free for this scheme to work. I think we should separate out the different layers of the proposal:

1. Attacking the coinbase instead of orphaning allows for 100 blocks' time for a consensus to be reached, rather than 10 minutes. This allows for human verification/intervention if needed (orphaning decisions would almost always need to be automated, due to the short timeframe). This is a useful insight, and I don't think it's been brought up before.

2. The original specification of how it's done (redistribution, no cost to voting) does seem exploitable. This can be fixed by reducing the incentive (burning instead of redistributing) and/or adding a risk to the orphaning attempts (a vote that fails destroys X bitcoins' worth from each voting block's own coinbase). The incentives can be tailored to mirror those of orphaning a block, to reduce the risk of abuse. Then the only difference from orphaning are 1) More limited rewriting of history (only the coinbase, vs all transactions in the block), and 2) More time to coordinate a response.

3. This proposal may be used for things other than punishing double-spend pools. In fact it might be used to punish miners for doing anything a significant percentage of hashpower dislikes (large OP_RETURNs, large blocks, gambling transactions, transactions banned by a government). But we can make the threshold higher than 51%, so that this doesn't turn into a significant risk (if 75% of hashpower is willing to enforce a rule, we're already likely to see it enforced through orphaning).

On Wed, Apr 23, 2014 at 11:38 AM, Alex Mizrahi <alex.mizrahi@gmail•com> wrote:

>
>>
>> And it still would. Non-collusive miners cast votes based on the outcome
>> of their own attempts to double spend.
>
>
> Individually rational strategy is to vote for coinbase reallocation on every
> block.
>
> Yes, in that case nobody will get reward. It is similar to prisoner's
> dilemma: equilibrium has worst pay-off.
> In practice that would mean that simple game-theoretic models are no longer
> applicable, as they lead to absurd results.
>
>>
>> I'm using it in the same sense Satoshi used it. Honest miners work to
>> prevent double spends. That's the entire justification for their existence.
>> Miners that are deliberately trying to double spend are worse than useless.
>
>
> Miners work to get rewards.
> It absolutely doesn't matter whether they are deliberately trying to
> double-spend or not: they won't be able to double-spend without a collusion.
>
> ------------------------------------------------------------------------------
> Start Your Social Network Today - Download eXo Platform
> Build your Enterprise Intranet with eXo Platform Software
> Java Based Open Source Intranet - Social, Extensible, Cloud Ready
> Get Started Now And Turn Your Intranet Into A Collaboration Platform
> http://p.sf.net/sfu/ExoPlatform
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge•net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

What is the advantage of this proposal over just orphaning the block with double spends?

There's currently a set of rules which government what constitutes a valid block. Miners don't build on blocks that don't accord with those rules out of fear that a major won't follow and they will waste hashing power.

If there was a rule supported by the majority that considered blocks with double spends (defined in some fashion) as invalid miners wouldn't build on them for the same reason they wouldn't build on a block with a coinbase over 25 btc, say. It seems that would accomplish the same without the other issues. On Apr 23, 2014 12:04 PM, "Christophe Biocca" <christophe.biocca@gmail•com> wrote:

> It's not necessary that this "coinbase retribution" be either
> profitable or risk-free for this scheme to work. I think we should
> separate out the different layers of the proposal:
>
> 1. Attacking the coinbase instead of orphaning allows for 100 blocks'
> time for a consensus to be reached, rather than 10 minutes. This
> allows for human verification/intervention if needed (orphaning
> decisions would almost always need to be automated, due to the short
> timeframe). This is a useful insight, and I don't think it's been
> brought up before.
>
> 2. The original specification of how it's done (redistribution, no
> cost to voting) does seem exploitable. This can be fixed by reducing
> the incentive (burning instead of redistributing) and/or adding a risk
> to the orphaning attempts (a vote that fails destroys X bitcoins'
> worth from each voting block's own coinbase). The incentives can be
> tailored to mirror those of orphaning a block, to reduce the risk of
> abuse. Then the only difference from orphaning are 1) More limited
> rewriting of history (only the coinbase, vs all transactions in the
> block), and 2) More time to coordinate a response.
>
> 3. This proposal may be used for things other than punishing
> double-spend pools. In fact it might be used to punish miners for
> doing anything a significant percentage of hashpower dislikes (large
> OP_RETURNs, large blocks, gambling transactions, transactions banned
> by a government). But we can make the threshold higher than 51%, so
> that this doesn't turn into a significant risk (if 75% of hashpower is
> willing to enforce a rule, we're already likely to see it enforced
> through orphaning).
>
> On Wed, Apr 23, 2014 at 11:38 AM, Alex Mizrahi <alex.mizrahi@gmail•com>
> wrote:
> >
> >>
> >> And it still would. Non-collusive miners cast votes based on the outcome
> >> of their own attempts to double spend.
> >
> >
> > Individually rational strategy is to vote for coinbase reallocation on
> every
> > block.
> >
> > Yes, in that case nobody will get reward. It is similar to prisoner's
> > dilemma: equilibrium has worst pay-off.
> > In practice that would mean that simple game-theoretic models are no
> longer
> > applicable, as they lead to absurd results.
> >
> >>
> >> I'm using it in the same sense Satoshi used it. Honest miners work to
> >> prevent double spends. That's the entire justification for their
> existence.
> >> Miners that are deliberately trying to double spend are worse than
> useless.
> >
> >
> > Miners work to get rewards.
> > It absolutely doesn't matter whether they are deliberately trying to
> > double-spend or not: they won't be able to double-spend without a
> collusion.
> >
> >
> ------------------------------------------------------------------------------
> > Start Your Social Network Today - Download eXo Platform
> > Build your Enterprise Intranet with eXo Platform Software
> > Java Based Open Source Intranet - Social, Extensible, Cloud Ready
> > Get Started Now And Turn Your Intranet Into A Collaboration Platform
> > http://p.sf.net/sfu/ExoPlatform
> > _______________________________________________
> > Bitcoin-development mailing list
> > Bitcoin-development@lists•sourceforge•net
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >
>
>
> ------------------------------------------------------------------------------
> Start Your Social Network Today - Download eXo Platform
> Build your Enterprise Intranet with eXo Platform Software
> Java Based Open Source Intranet - Social, Extensible, Cloud Ready
> Get Started Now And Turn Your Intranet Into A Collaboration Platform
> http://p.sf.net/sfu/ExoPlatform
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge•net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

I think the cost to mines is the same as what's possible today, actually.

Consider a group of miners who wish to do this with no changes to the rule set. They can coordinate out of band and figure out if they have a majority of hashpower behind the decision to orphan a block, e.g. by signing a nonce with their coinbase keys. If they reach quorum, then they begin work on a parallel chain. Because they have majority they are guaranteed to eventually win, though depending on luck it may take a while. Because of this, assuming the external quorum system is public, the moment consensus is reached the other miners should all abandon the existing branch and start work on the parallel chain too, lest they waste work mining on a branch that is surely doomed.

The end result would be that the chain stops making progress, disrupting end users and generally creating uncertainty as the new chain is forged. Also, miners who built on top of the orphaned block end up being punished even if they did nothing wrong. Both these side effects are undesirable and unnecessary.

So the more I think about this scheme, the more it seems like a simple improvement on the current status quo. Miners can do what they could already do, but with a more reliable in-band signalling mechanism that doesn't require things like coinbase keys to be online, and them doing so does not disrupt existing users or waste energy.

On 4/23/2014 12:04 PM, Christophe Biocca wrote:

> It's not necessary that this "coinbase retribution" be either
> profitable or risk-free for this scheme to work. I think we should
> separate out the different layers of the proposal:
>
> 1. Attacking the coinbase instead of orphaning allows for 100 blocks'
> time for a consensus to be reached, rather than 10 minutes. This
> allows for human verification/intervention if needed (orphaning
> decisions would almost always need to be automated, due to the short
> timeframe). This is a useful insight, and I don't think it's been
> brought up before.
>
> 2. The original specification of how it's done (redistribution, no
> cost to voting) does seem exploitable. This can be fixed by reducing
> the incentive (burning instead of redistributing) and/or adding a risk
> to the orphaning attempts (a vote that fails destroys X bitcoins'
> worth from each voting block's own coinbase). The incentives can be
> tailored to mirror those of orphaning a block, to reduce the risk of
> abuse. Then the only difference from orphaning are 1) More limited
> rewriting of history (only the coinbase, vs all transactions in the
> block), and 2) More time to coordinate a response.
>
> 3. This proposal may be used for things other than punishing
> double-spend pools. In fact it might be used to punish miners for
> doing anything a significant percentage of hashpower dislikes (large
> OP_RETURNs, large blocks, gambling transactions, transactions banned
> by a government). But we can make the threshold higher than 51%, so
> that this doesn't turn into a significant risk (if 75% of hashpower is
> willing to enforce a rule, we're already likely to see it enforced
> through orphaning).
>
> On Wed, Apr 23, 2014 at 11:38 AM, Alex Mizrahi <alex.mizrahi@gmail•com> wrote:
>>> And it still would. Non-collusive miners cast votes based on the outcome
>>> of their own attempts to double spend.
>>
>> Individually rational strategy is to vote for coinbase reallocation on every
>> block.
>>
>> Yes, in that case nobody will get reward. It is similar to prisoner's
>> dilemma: equilibrium has worst pay-off.
>> In practice that would mean that simple game-theoretic models are no longer
>> applicable, as they lead to absurd results.
>>
>>> I'm using it in the same sense Satoshi used it. Honest miners work to
>>> prevent double spends. That's the entire justification for their existence.
>>> Miners that are deliberately trying to double spend are worse than useless.
>>
>> Miners work to get rewards.
>> It absolutely doesn't matter whether they are deliberately trying to
>> double-spend or not: they won't be able to double-spend without a collusion.
>>
>> ------------------------------------------------------------------------------
>> Start Your Social Network Today - Download eXo Platform
>> Build your Enterprise Intranet with eXo Platform Software
>> Java Based Open Source Intranet - Social, Extensible, Cloud Ready
>> Get Started Now And Turn Your Intranet Into A Collaboration Platform
>> http://p.sf.net/sfu/ExoPlatform
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists•sourceforge•net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
> ------------------------------------------------------------------------------
> Start Your Social Network Today - Download eXo Platform
> Build your Enterprise Intranet with eXo Platform Software
> Java Based Open Source Intranet - Social, Extensible, Cloud Ready
> Get Started Now And Turn Your Intranet Into A Collaboration Platform
> http://p.sf.net/sfu/ExoPlatform
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge•net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

This all sounds verry restrictive. Is it possible to do a "sweep" in order to "clean up" double spending? Why punish miners for the sake of punishing them?

On 04/23/2014 03:07 PM, Mike Hearn wrote:

> On Wed, Apr 23, 2014 at 4:52 PM, Justus Ranvier
> <justusranvier@gmail•com>wrote:
>
>> If enough miners don't like a block that has been mined, they can
>> all work to orphan it without any change to the protocol
>> whatsoever.
>>
>
> As was already pointed out, yes. However this requires them to
> immediate establish a majority consensus and be absolutely sure it
> really is the majority. You suggest an out of band mechanism for
> that, but why is this better than using the actual consensus
> mechanism you're trying to measure?
>
>
>> Once you've changed the network such that it is no longer a
>> machine that faithfully processes scripts
>
>
> Bitcoin imposes far more rules than just execution of the
> scripting language, many of which are entirely arbitrary and the
> result of (controversial) human judgement, like the inflation
> schedule. You can't claim Bitcoin implements only some kind of
> natural law.
>

I've formulated my replies to you and this proposal in a more public venue, where such discussions of existential changes to the protocol more rightfully belong:

http://bitcoinism.blogspot.com/2014/04/dirty-deals-in-smoke-filled-rooms.html

- -- Support online privacy by using email encryption whenever possible. Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k

>
>
> I've formulated my replies to you and this proposal in a more public
> venue, where such discussions of existential changes to the protocol
> more rightfully belong
>
>

I strongly disagree. It makes perfect sense to discuss changes here, first, where there are lots of people who understand how the system works at a very detailed level.

And why do you think your blog is more public than this open, publicly archived mailing list???

On 04/23/2014 05:47 PM, Gavin Andresen wrote:

> And why do you think your blog is more public than this open,
> publicly archived mailing list???
>

Non-developers are more comfortable using social media tools. Blog posts can be shared, Tweeted, and commented upon using nothing more than a web browser.

The barrier to participation on a mailing list is higher, and the visibility is lower.

- -- Support online privacy by using email encryption whenever possible. Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k

>
> Non-developers are more comfortable using social media tools. Blog
> posts can be shared, Tweeted, and commented upon using nothing more
> than a web browser.
>

I don't think Twitter is an appropriate medium for discussing the details of byzantine consensus algorithms.

I'm not going to bother arguing in replies to a blog post. Suffice it to say, miners are already handsomely compensated via both inflation and fees for doing their job of preventing double spends. Your suggestion is people should pay them EVEN MORE for simply not being corrupt. My proposal is simpler - how about we find the ones that are claiming people's money via coinbases yet not doing their jobs correctly, and take the money back (or destroy it). I think I prefer that one. Miners that are maliciously double spending cannot justify their existence, they offer no useful service and do not deserve compensation as a result.

On 04/23/2014 05:57 PM, Mike Hearn wrote:

> I'm not going to bother arguing in replies to a blog post. Suffice
> it to say, miners are already handsomely compensated via both
> inflation and fees for doing their job of preventing double spends.
> Your suggestion is people should pay them EVEN MORE for simply not
> being corrupt. My proposal is simpler - how about we find the ones
> that are claiming people's money via coinbases yet not doing their
> jobs correctly, and take the money back (or destroy it). I think I
> prefer that one. Miners that are maliciously double spending cannot
> justify their existence, they offer no useful service and do not
> deserve compensation as a result.
>

The integrity of Bitcoin is more important than you and your personal preferences.

You don't have the right to decide which valid scripts in the blockchain will be disregarded, and neither does anyone else.

If you don't like what's in the blockchain, you and everybody else can work within the protocol to orphan the offending block.

But if you fail, then what's written in the blockchain is final and the sole purpose of the network is to enforce it - deal with it.

PS: We don't even know who runs BitUndo. They seem to have lots of money to spend on web design - I wonder where it came from?

- -- Support online privacy by using email encryption whenever possible. Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k

On Wed, Apr 23, 2014 at 06:04:49PM +0000, Justus Ranvier wrote:

> The integrity of Bitcoin is more important than you and your personal
> preferences.
>
>
> You don't have the right to decide which valid scripts in the
> blockchain will be disregarded, and neither does anyone else.
>
>
> If you don't like what's in the blockchain, you and everybody else can
> work within the protocol to orphan the offending block.
>
>
> But if you fail, then what's written in the blockchain is final and
> the sole purpose of the network is to enforce it - deal with it.

Agreed, although I think waxwing put it better: Bitcoin's most fundamental property is its neutrality. If it loses this, it is not Bitcoin.

But I also agree with Gavin that the bitcoin-development email list is a perfectly good place to have these types of discussions. I myself have used it repeatedly to publish ideas specifically due to wide readership and multiple independent archives.

> PS: We don't even know who runs BitUndo. They seem to have lots of
> money to spend on web design - I wonder where it came from?

Actually we do: Eric Springer

See

http://www.coindesk.com/double-spending-unconfirmed-transactions-concern-bitcoin/

https://github.com/espringe - joined Feb 11 2010

Anyway that's just twitter bootstrap or something; I hear the wizards can pump out a site like that in a few hours.

On 04/23/2014 06:15 PM, Peter Todd wrote:

> But I also agree with Gavin that the bitcoin-development email list
> is a perfectly good place to have these types of discussions. I
> myself have used it repeatedly to publish ideas specifically due to
> wide readership and multiple independent archives.

A development list is a great place to decide how to implement a technical feature, one that feature has been deemed desirable.

The chief scientist has a platform via which he can publicly announce proposed protocol changes. Anyone else could do the same.

There are conference happening all the time where people can announce ideas like this, to give time for the community to hear the idea and generate feedback.

There is absolutely nothing so urgent about this attack that requires the consensus process to start here, in a place that most Bitcoin users don't even know about and wouldn't even know which search terms to apply to look for such a discussion if they did.

>> PS: We don't even know who runs BitUndo. They seem to have lots
>> of money to spend on web design - I wonder where it came from?
>
> Actually we do: Eric Springer
>
> See
>
> http://www.coindesk.com/double-spending-unconfirmed-transactions-concern-bitcoin/
>
>  https://github.com/espringe - joined Feb 11 2010
>
> Anyway that's just twitter bootstrap or something; I hear the
> wizards can pump out a site like that in a few hours.
>

I stand corrected.

- -- Support online privacy by using email encryption whenever possible. Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k

If you want to try and argue that the development list is the wrong place to discuss development, please do so on another thread (or your blog). Let's keep this thread for discussion of the original proposal - ideally, discussed with the dryness that a topic as nerdy as distributed consensus algorithms deserves ;)

On 04/23/2014 06:37 PM, Mike Hearn wrote:

> If you want to try and argue that the development list is the wrong
> place to discuss development, please do so on another thread (or
> your blog). Let's keep this thread for discussion of the original
> proposal - ideally, discussed with the dryness that a topic as
> nerdy as distributed consensus algorithms deserves ;)
>

Is that what you say to yourself to quiet your conscience at night (assuming you're one of the non-sociopathic humans who does indeed have one)? It's "just a nerdy distributed consensus problem"?

The things you're talking about fucking around with have real life implications for quite a few people and your casual dismissal of this is precisely why I responded in the way that I did.

What you're doing is reckless endangerment and you're not got to get away with brushing it off as a mere technical detail.

Sunlight is the best disinfectant, and this episode is demonstrating to the world exactly how averse you are do that kind of transparency.

- -- Support online privacy by using email encryption whenever possible. Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k

On Wed, Apr 23, 2014 at 12:55 AM, Mike Hearn <mike@plan99•net> wrote:

> Lately someone launched Finney attacks as a service (BitUndo). As a reminder
> for newcomers, Finney attacks are where a miner secretly works on a block
> containing a double spend.

Hm? I didn't think this is at all what they did. What they claim to do is to prioritize transactions in their mempool from people who pay them, potentially over and above other transactions which they may or may not have received first.

This may still be bad news for someone taking an irreversible action in response to an unconfirmed payment and it may or may not be really ill advised in general, but I think it's less sinister than it sounds in your posts. Is there some reason to believe it isn't what it claims to be?

I think we have very clear evidence that the Bitcoin community doesn't care if miners reorder transactions in their mempool to profitable ends: In https://bitcointalk.org/index.php?topic=327767.0 it's demonstrated that GHash.IO, currently the largest publicly identified pool was used to rip off Betcoin dice via double-spends.

> first started using Bitcoin, nowadays most of my purchases with it are for
> food and drink. If Bitcoin could not support such purchases, I would use it
> much less.

Accepting zero-conf inherently has some risk (well, so does all business, but there is substantially more in a zero-conf payment). Even in a spherical-cow Bitcoin absent anything like Bitundo someone can just give a double spend to a large miner and currently give the whole rest of the network the one paying the merchant. They will, with high success rate be successful. Worse, it may _appear_ to the network that the miner was a "bitundo" but they really were not. The blockchain exists to establish consensus ordering, prior to the blockchain there is no order, and so it is not easy to really say which transaction came first in any meaningful sense.

But in business we balance risks and the risk that sometimes a transaction will be reversed exists in every electronic payment system available today, in most of them the risk persists for _months_ rather than minutes. Businesses can still operate in the face of these risks.

More importantly, it's possible to deploy technological approaches to make zero-conf very secure against reversal: Things like performing multi-sig with a anti-double-spending system, or using an external federated payment network... but this stuff requires substantial development work— though it's not work thats likely to happen if people are still confused about the level of security that zero-conf has.

> Miners can vote to reallocate the coinbase value of bad blocks before they
> mature.

I think miners 'voting' to reallocate coins, even if they're thoroughly convinced that the owner of the coins is a nasty party, is a much greater violation of the Bitcoin social contract than some twiddling with the unspecified unconfirmed transaction ordering.

Doubly so because a 'nasty' party with non-trivial hash-power can doublespend their own transactions with a pretty good success rate (as was the case for the GHash.io betcoin spends) including not-just zero-conf (though with obviously reduced effectiveness), and all of your reliable detection depends on it being a public service.

A much better defense is having the control of hash power very well distributed and so there isn't any central point that excerts enough influence to change the risk statistics much. Giving miners the ability to steal each others payments is, if anything, a force away from that decentralization.

Bitcoin has various checks and balances that help keep everything honest.

Even if a pool had 60% of the hashing power, they couldn't reverse 6 blocks without anyone noticing that it had happened.

There are sites which monitor the blocks and estimate the percentage of the blocks found by each pool.

In a way, bitcoin doesn't depend on the majority of miners following the protocol, it depends on miners believing that a majority of the other miners will follow the protocol.

If a miner has 5% of the hashing power and believes that the other 95% will follow the protocol, then the system should be set up so that it is in that miner's interests to follow the protocol too.

This is why soft forks work. The formal process convinces all the miners that the new rules are locked in.

In a system where miners can vote to cancel coinbases, each pool has an incentive to vote to reject everyone else's blocks.

Pools on the receiving end will be less profitable and lose customers.

It is possible that "predatory" pools would lose hashing power as miners switch to other pools, in protest.

The proposal allows "established" pools to vote to disallow new entrants. They could even justify it by saying that those pools haven't invested in "anti-double spending" infrastructure.

The proposal doesn't suddenly give the majority the ability to do it, but it isn't clear that making the process less disruptive is a good thing.

On Wed, Apr 23, 2014 at 7:37 PM, Mike Hearn <mike@plan99•net> wrote:

> If you want to try and argue that the development list is the wrong place
> to discuss development, please do so on another thread (or your blog).
> Let's keep this thread for discussion of the original proposal - ideally,
> discussed with the dryness that a topic as nerdy as distributed consensus
> algorithms deserves ;)
>
>
> ------------------------------------------------------------------------------
> Start Your Social Network Today - Download eXo Platform
> Build your Enterprise Intranet with eXo Platform Software
> Java Based Open Source Intranet - Social, Extensible, Cloud Ready
> Get Started Now And Turn Your Intranet Into A Collaboration Platform
> http://p.sf.net/sfu/ExoPlatform
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge•net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>

Cut it out with the ad hominem attacks please. If you cant be civil, please go away until you learn some manners.

I think the issue being discussed is do you orphan an entire block causing distress to users as well, or try to just cause distress just to the evil miner? This discussion is about exploring the ramifications of all these options.

I think you are also forgetting that, miners can implement their own filters and behaviours without anyone's consent. So having an open discussion and exploring all possibilities can only be a good thing before someone goes off an implements a change without taking into account other points of view they may not have considered yet. On 23 Apr 2014 19:51, "Justus Ranvier" <justusranvier@gmail•com> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 04/23/2014 06:37 PM, Mike Hearn wrote:
> > If you want to try and argue that the development list is the wrong
> > place to discuss development, please do so on another thread (or
> > your blog). Let's keep this thread for discussion of the original
> > proposal - ideally, discussed with the dryness that a topic as
> > nerdy as distributed consensus algorithms deserves ;)
> >
>
> Is that what you say to yourself to quiet your conscience at night
> (assuming you're one of the non-sociopathic humans who does indeed
> have one)? It's "just a nerdy distributed consensus problem"?
>
> The things you're talking about fucking around with have real life
> implications for quite a few people and your casual dismissal of this
> is precisely why I responded in the way that I did.
>
> What you're doing is reckless endangerment and you're not got to get
> away with brushing it off as a mere technical detail.
>
> Sunlight is the best disinfectant, and this episode is demonstrating
> to the world exactly how averse you are do that kind of transparency.
>
> - --
> Support online privacy by using email encryption whenever possible.
> Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.22 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQEcBAEBAgAGBQJTWAsmAAoJECoisBQbQ4v0XTcIAL70+EAkSMUgvGeTN+mROkkd
> 3ap5NhUYehfW33gEEEyO3a6ofrb6k1a8EbHlzDyq7qPZ925kdvbnwqXDQm7auAh1
> V8IPAwp+JfCgVDVAxtHuUBUvTuuCn1Mrxnf6ppwzFywBxU6l6KYK9zac1HoX3EVY
> QxME15zrBmtJfo9/ed9yWz8ZXl6nsx47D3r0VE8FiENJRgxLfZ7Odsr/sGvgL71N
> aYPv7vMxRBNXDvrMhEuYKa3L83W5kv4JJxzueUyO/0bww/aaeZMZr850u/hUjMgU
> ui37M+kiFHug3semWGKs1yJiKsEPsEPaU4j6WSDrd0bNbc73bBjvHm9SGYRHzDQ=
> =L5nX
> -----END PGP SIGNATURE-----
>
>
> ------------------------------------------------------------------------------
> Start Your Social Network Today - Download eXo Platform
> Build your Enterprise Intranet with eXo Platform Software
> Java Based Open Source Intranet - Social, Extensible, Cloud Ready
> Get Started Now And Turn Your Intranet Into A Collaboration Platform
> http://p.sf.net/sfu/ExoPlatform
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge•net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>

On Wed, Apr 23, 2014 at 8:57 PM, Gregory Maxwell <gmaxwell@gmail•com> wrote:

> Hm? I didn't think this is at all what they did.  What they claim to
> do is to prioritize transactions in their mempool from people who pay
> them
>

That's the definition of a Finney attack, right? A tx is broadcast and nodes normally take the first one they saw, allowing you to measure propagation and use double spend alerts to get pretty good confidence, pretty quick. A Finney attacker doesn't do that and includes a double spend, so the one in the mempool gets overridden.

I mean, I hope that's the definition of a Finney attack, given that I coined the term :)

> I think we have very clear evidence that the Bitcoin community doesn't
> care if miners reorder transactions in their mempool to profitable
> ends: In https://bitcointalk.org/index.php?topic=327767.0 it's
> demonstrated that GHash.IO, currently the largest publicly identified
> pool was used to rip off Betcoin dice via double-spends.
>

Yes, very disappointing. Though I'd hope that if this sort of thing was sustained over months and merchants started dropping Bitcoin as a result, miners would pay more attention.

Right now I suspect miners don't pay attention to anything other than hardware builds though.

Yes, Bitcoin is imperfect at stopping double spends today. It can certainly be improved! There are plenty of oft-discussed measures like double spend alerts and discouraging Finney-attack blocks as was debated extensively in 2011. This thread is just a third such proposal.

More importantly, it's possible to deploy technological approaches to

> make zero-conf very secure against reversal: Things like performing
> multi-sig with a anti-double-spending system
>

These sorts of proposals are all just ways of saying block chains kind of suck and we should go back to using trusted third parties.

That may well be how the Bitcoin experiment ends, but I think we all agree here that block chains and decentralised consensus are quite spiffy and we should try hard to make them work as well as possible before just shrugging and say "find a trusted third party". Otherwise why not just go back to using MasterCard? Any TTP that enforces anti double spending rules will be a lot more centralised than miners, given the difficulty of finding them, their need for a strong brand/reputation, and the difficulty of getting everyone to agree on them.

Not to mention that this solution makes Bitcoin sound like a joke currency. It's a super duper low fee totally decentralised financial system ..... unless you want to buy something in, you know, a shop. And walk out. Then you need to sign up with this company that looks suspiciously like a bank, and pay their fees, and yeah there's like 3 to pick from. Totally decentralised!

> Doubly so because a 'nasty' party with non-trivial hash-power can
> doublespend their own transactions
>

If a miner is vertically integrated and defrauding merchants themselves, with no service component, pretty quickly people would talk to each other, notice this pattern and stop trading with them, making their coins rather useless. Also if their real identity is ever revealed they could be liable and there'd be a lot of people wanting to sue them.

So I think the ability to resell double spending to lots of different people around the world seems important to practicality.

On Wed, Apr 23, 2014 at 12:19 PM, Mike Hearn <mike@plan99•net> wrote:

> That's the definition of a Finney attack, right?

A finney attack is where you attempt to mine a block with a transaction paying you, and as soon as you are successful you quickly make a transaction spending that coin to someone else, then release the block after they've taken an irreversible action. If everything is automated it should have something like a 99% success rate, though it has a cost of some small increase in the number of orphan blocks you experience.

> I mean, I hope that's the definition of a Finney attack, given that I coined
> the term :)

You might have coined the term, but I don't think the attack you're describing is the attack Hal described: https://bitcointalk.org/index.php?topic=3441.msg48384#msg48384

What you're talking about is just disagreement about the content of the memory pool, but we have no consensus mechanism there (the blockchain _is_ the consensus mechanism). Mempools are sometimes inconsistent all on their own, without any attacker being involved.

> These sorts of proposals are all just ways of saying block chains kind of
> suck and we should go back to using trusted third parties.

I think thats an unsophisticated view.

Consider this protocol.

I take some of my funds and assign them to a 2 of 2 multisig with myself and Oscar. I do not announce this transaction until I get Oscar to sign a timelocked anyonecanpay refund to send the coin back to me (say in 3 months). Oscar gives me my refund and I announce the transaction.

Later I can make instant payments with oscar signing up until the refund time comes clue to anyone who trusts Oscar to never double spend. For the receiver this is purely additive with regular blockchain security: in that even with Oscar's help I cannot double spend except where I would have been successful absent Oscar. On the sender side, Oscar cannot up and steal my funds and he can't try to extort me (except by creating a delay up to the refund time).

Oscar himself can be implemented as a majority M parties to further increase confidence, though if you're talking about using this for low value retail transactions— the fact that any cheating by oscar is cryptographically provable (just show them the double signatures) maybe be strong enough alone. (Though there is a multitude of other proposals to provide more evidence of Oscar's honesty). There are also ways to blind Oscar so he can't reliably identify which transactions are ones he signed for.

I don't think this is at all a "return to trusted third parties"— that it's a shrug and an admission of defeat. Its a very narrowly scoped trust, filling in precisely where large scale decentralized consensus is fundamentally weak... the result is something which combines advantages from both classes and is stronger than either trust or blockchains alone. (I'm also not trying to say that an implementation of this is _simple_ by any means, working out all the details is hard.)

By contrast, I think proposals which overly depend on colluding miners to behave in very specific ways are themselves just a way of saying block chains suck unless we turn the miners themselves into a trusted third party. I'm much more in favor of adding a little bit of mastercard to transactions where mastercard is really what people want, than turning mining— and thus bitcoin itself— into mastercard, especially since miners— self selecting as they are— are a pretty poor set of parties to act as trusted agents. :)

>> Doubly so because a 'nasty' party with non-trivial hash-power can
>> doublespend their own transactions
> If a miner is vertically integrated and defrauding merchants themselves,
> with no service component, pretty quickly people would talk to each other,
> notice this pattern and stop trading with them, making their coins rather
> useless. Also if their real identity is ever revealed they could be liable
> and there'd be a lot of people wanting to sue them.

We have an existence proof that it isn't so— you can say that it wasn't consistent enough, but what is? There wasn't any major doubt that they were actually doing it. They're the largest identifiable pool as we speak.

I think, instead, that strong zero-conf security isn't a part of what many people think of when they think of Bitcoin's characteristics. Zero conf is risky, and I think for a lot of people thats okay. If it isn't there are ways to improve it that don't involve asking miners to participate in a majority vote to take away funds from people.

>
> What you're talking about is just disagreement about the content of
> the memory pool
>

That's the same thing. Whilst you're mining your double spend tx, it's in your mempool but you don't broadcast it as per normal. Then when you find the block you broadcast it to override everyone elses mempool. So yours and theirs were inconsistent.

The only slight way BitUndo differs is, they provide it as a service, and I don't know if they inform you when they found a block (probably not), so you have to do the purchase and then hope BitUndo finds the next block. Otherwise the purchase clears. But they could certainly add a pre-notification before they broadcast to get back to the exact scheme originally described, they have everything else in place.

> Oscar himself can be implemented as a majority M parties to further
> increase confidence

This just brings us back to square one. Who are these parties and what if I pay them to be corrupt? What if they offer to be corrupt as a service?

Let's say I succeed in finding some parties who are incorruptible no matter how large of a percentage I offer them. At this point, why bother with miners at all? Why pay for double spend protection twice, once to a group of Oscar's who are trustworthy and once to a group of miners who are not?

The point of the broadcast network and mining is so there can be lots of Oscar's and I don't have to know who they are or sign up with them or put any effort into evaluating their reputation.

> value retail transactions— the fact that any cheating by oscar is
> cryptographically provable (just show them the double signatures)
> maybe be strong enough alone.
>

But as you point out, cheating my GHash.io did not result in any obvious negative consequence to them, despite that preventing double spending is their sole task. Why would Oscar be different to GHash.io?

Trying to solve the problem of dishonest miners is effectively trying to solve the "automatically find trusted third parties" problem at scale.

On Wed, Apr 23, 2014 at 12:59 PM, Mike Hearn <mike@plan99•net> wrote:

>> What you're talking about is just disagreement about the content of
>> the memory pool
> That's the same thing. Whilst you're mining your double spend tx, it's in
> your mempool but you don't broadcast it as per normal. Then when you find
> the block you broadcast it to override everyone elses mempool. So yours and
> theirs were inconsistent.

The difference is when you transact. In the attack Hal described you transact with your victim only after finding a block but before announcing it.

> don't know if they inform you when they found a block (probably not), so you
> have to do the purchase and then hope BitUndo finds the next block.

Right, this works in the Bitcoin network today absent any collusion by the miners. You give one miner a transaction and you give every other node you can reach another transaction. You then hope your selected miner finds the next block and 'undoes' the transaction you gave the rest of the network.

> This just brings us back to square one. Who are these parties and what if I
> pay them to be corrupt? What if they offer to be corrupt as a service?
>
> Let's say I succeed in finding some parties who are incorruptible no matter
> how large of a percentage I offer them. At this point, why bother with
> miners at all? Why pay for double spend protection twice, once to a group of
> Oscar's who are trustworthy and once to a group of miners who are not?
>
> The point of the broadcast network and mining is so there can be lots of
> Oscar's and I don't have to know who they are or sign up with them or put
> any effort into evaluating their reputation.

But it isn't at all the same thing. Miners select themselves based on controlling hash-power. You can distrust a miner all you like but all your distrust does not prevent him from participating in the consensus, potentially to your detriment. Moreover, the set of miners has to be the same for everyone or otherwise the network doesn't converge. There are miners I _know_ to be scoundrels, but there is nothing I can do about it.

Someone you ask to not double spend is an entirely separate matter. They aren't self-selecting: you select who you trust to not make double spends and there is no need for this trust to be globally consistent. If they behave in an untrustworthy way you can instantly stop honoring them because the bad action is provable beyond any doubt and never trust them again (unlike mempool consistency)... and you can do this even if everyone else is too foolish to do so for some reason.

The trustworthness of oscars needs only be limited and is different in kind from the kind of 'trust' we need over the history— they arbitrating over the ordering of some subset of transactions right at the tip of the chain, and only those transaction of people who have specifically chosen to use them, of lower value transactions where you need instant settlement. Why pay twice? Because you're actually getting a different part of your security from each, and the result is additive.

There is no such thing as an uncorruptable party, invoking that is a useless strawman. Instead we can consider how difficult the corruption is and what can happen if they're corrupted and hope to balance the risks and the controls for those risks. Any self-selectingness as anonymity (in the not-previously-enumerated sense) of mining is important for censorship security but it's terrible for other things like getting reliable mempool behavior.

> But as you point out, cheating my GHash.io did not result in any obvious
> negative consequence to them, despite that preventing double spending is
> their sole task. Why would Oscar be different to GHash.io?

Because you can choose to stop trusting an oscar while you— individually— can't choose anything about ghash.io. To stop GHash.io we would have to take away their hardware or change the Bitcoin protocol to make their hardware useless, and in the latter case we'd _all_ have to agree to do this not just some (perhaps quite large) subset of us who doesn't want to trust them, and even though it is quite apparent what they did there is still some room to claim doubt.

> Trying to solve the problem of dishonest miners is effectively trying to
> solve the "automatically find trusted third parties" problem at scale.

Mining is universal— everyone must use the same miners, trust seldom is seldom universal and shouldn't be. The trust we have in mining is exceptionally limited, I think any effort to increase it is doomed to fail— both because trust heavy systems stink, because mining is a bad fit for trust, and because increasing the requirements create other exposures and vulnerabilities.

On Wed, Apr 23, 2014 at 10:24 PM, Gregory Maxwell <gmaxwell@gmail•com>wrote:

> Right, this works in the Bitcoin network today absent any collusion by
> the miners. You give one miner a transaction and you give every other
> node you can reach another transaction.
>

Yes, but that can be fixed with double spend alerts.

> Someone you ask to not double spend is an entirely separate matter.
> They aren't self-selecting: you select who you trust to not make
> double spends and there is no need for this trust to be globally
> consistent.
>

No? It's not just your decision that matters, the receiver also has to trust them. They're like a dispute mediator in this regard. You can pick whoever you want, but that doesn't matter if the receiver doesn't recognise them or trust them. You have to find an overlap to make an instant trade.

In practice if people have to think about this, evaluate brands etc then you'd get a very small number of parties because the value of global agreement is so high. Then it becomes hard to remove ones that have a lot of momentum.

The censorship resistance of the block chain doesn't matter if your double spending partners refuse to help you spend your money (because they're being coerced). The censorship can just happen at a different place.

> To stop GHash.io we would have to take away their hardware or change the
> Bitcoin
> protocol to make their hardware useless
>

..... or, have a majority decide to zero out their coinbase rewards for blocks that double spent against dice sites. That wouldn't undo the double spend, but you can't do that with the multisig scheme either. All you can do is punish the corrupted party post-hoc, either by not using them again, or by "unpaying" them for the service they did not provide.

The memory pool is just talk. There is no expectation that the memory pool has to satisfy some standard as to what will eventually exist in the block chain, and there are any number of ways that people could communicate transactions to one another without putting them in the memory pool. The memory pool can't be treated like a contract because there is no cryptography to enforce it--there is no contract until the transactions appear in the block chain, inherently.

Mike Hearn's proposal is nonsense because it requires miners to develop a concensus on which blocks in the block chain are dishonest. There is no way to prove cryptographically that a block is dishonest because the block chain itself is the concensus system--before there is concensus, there is no concept of dishonesty, at least as far as double-spending goes. In order to decide that a block is dishonest and reallocate the coinbase, a prior consensus mechanism would be required. Of course, such a consensus mechanism would also be subject to attacks just like the block chain.

Maxwell's proposal is very good. One only trusts the oscar not to double spend, which is perfectly reasonable if oscar is a well-known service. Normal everyday wallets for immediate payments would simply require a little more infrastructure.

Daniel Krawisz

On Wed, Apr 23, 2014 at 2:59 PM, Mike Hearn <mike@plan99•net> wrote:

> What you're talking about is just disagreement about the content of
>>  the memory pool
>>
>
> That's the same thing. Whilst you're mining your double spend tx, it's in
> your mempool but you don't broadcast it as per normal. Then when you find
> the block you broadcast it to override everyone elses mempool. So yours and
> theirs were inconsistent.
>
> The only slight way BitUndo differs is, they provide it as a service, and
> I don't know if they inform you when they found a block (probably not), so
> you have to do the purchase and then hope BitUndo finds the next block.
> Otherwise the purchase clears. But they could certainly add a
> pre-notification before they broadcast to get back to the exact scheme
> originally described, they have everything else in place.
>
>
>> Oscar himself can be implemented as a majority M parties to further
>> increase confidence
>
>
> This just brings us back to square one. Who are these parties and what if
> I pay them to be corrupt? What if they offer to be corrupt as a service?
>
>  Let's say I succeed in finding some parties who are incorruptible no
> matter how large of a percentage I offer them. At this point, why bother
> with miners at all? Why pay for double spend protection twice, once to a
> group of Oscar's who are trustworthy and once to a group of miners who are
> not?
>
> The point of the broadcast network and mining is so there can be lots of
> Oscar's and I don't have to know who they are or sign up with them or put
> any effort into evaluating their reputation.
>
>
>> value retail transactions— the fact that any cheating by oscar is
>> cryptographically provable (just show them the double signatures)
>> maybe be strong enough alone.
>>
>
> But as you point out, cheating my GHash.io did not result in any obvious
> negative consequence to them, despite that preventing double spending is
> their sole task. Why would Oscar be different to GHash.io?
>
> Trying to solve the problem of dishonest miners is effectively trying to
> solve the "automatically find trusted third parties" problem at scale.
>
>
> ------------------------------------------------------------------------------
> Start Your Social Network Today - Download eXo Platform
> Build your Enterprise Intranet with eXo Platform Software
> Java Based Open Source Intranet - Social, Extensible, Cloud Ready
> Get Started Now And Turn Your Intranet Into A Collaboration Platform
> http://p.sf.net/sfu/ExoPlatform
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge•net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>

Isn't a faster blockchain for transactions (maybe as a sidechain) solving the problem? If there would be a safe way for 0-confirmation transactions, the Bitcoin blockchain wouldn't even be needed.

On Wed, Apr 23, 2014 at 10:37 PM, Mike Hearn <mike@plan99•net> wrote:

> On Wed, Apr 23, 2014 at 10:24 PM, Gregory Maxwell <gmaxwell@gmail•com>wrote:
>
>> Right, this works in the Bitcoin network today absent any collusion by
>> the miners. You give one miner a transaction and you give every other
>> node you can reach another transaction.
>>
>
> Yes, but that can be fixed with double spend alerts.
>
>
>> Someone you ask to not double spend is an entirely separate matter.
>> They aren't self-selecting: you select who you trust to not make
>> double spends and there is no need for this trust to be globally
>> consistent.
>>
>
> No? It's not just your decision that matters, the receiver also has to
> trust them. They're like a dispute mediator in this regard. You can pick
> whoever you want, but that doesn't matter if the receiver doesn't recognise
> them or trust them. You have to find an overlap to make an instant trade.
>
> In practice if people have to think about this, evaluate brands etc then
> you'd get a very small number of parties because the value of global
> agreement is so high. Then it becomes hard to remove ones that have a lot
> of momentum.
>
> The censorship resistance of the block chain doesn't matter if your double
> spending partners refuse to help you spend your money (because they're
> being coerced). The censorship can just happen at a different place.
>
>
>> To stop GHash.io we would have to take away their hardware or change the
>> Bitcoin
>> protocol to make their hardware useless
>>
>
> ..... or, have a majority decide to zero out their coinbase rewards for
> blocks that double spent against dice sites. That wouldn't undo the double
> spend, but you can't do that with the multisig scheme either. All you can
> do is punish the corrupted party post-hoc, either by not using them again,
> or by "unpaying" them for the service they did not provide.
>
>
>
> ------------------------------------------------------------------------------
> Start Your Social Network Today - Download eXo Platform
> Build your Enterprise Intranet with eXo Platform Software
> Java Based Open Source Intranet - Social, Extensible, Cloud Ready
> Get Started Now And Turn Your Intranet Into A Collaboration Platform
> http://p.sf.net/sfu/ExoPlatform
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge•net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>

On Wed, Apr 23, 2014 at 10:44 PM, Adam Ritter <aritter@gmail•com> wrote:

> Isn't a faster blockchain for transactions (maybe as a sidechain) solving
> the problem? If there would be a safe way for 0-confirmation transactions,
> the Bitcoin blockchain wouldn't even be needed.
>

The 10 minute average comes from a desire to balance wasted work due to natural chain splits with latency. With a very fast block interval you end up with lots of forks and things take longer to converge, also, it can make attacks easier because an attacker is building on his own blocks so he doesn't suffer propagation delays and the attendant splits.

It's not clear you can just make a faster block chain. 10 minutes is somewhat arbitrary, it could be 5 minutes and the system would still work, but it probably can't be 5 seconds.

Unfortunately for best physical-world usability you really need very fast payments. A few seconds is competitive with modern credit cards. The new contactless cards seem to be able to reliably manage <1 sec which is impressive. Waiting for blocks in a block chain can't really work. Waiting for propagation can work and has been working so far. Hence, the question of how that mechanism can be kept working in the face of malicious miners, before you end up having to fall back to trusted third parties and recentralisation.

On Wed, Apr 23, 2014 at 1:44 PM, Adam Ritter <aritter@gmail•com> wrote:

> Isn't a faster blockchain for transactions (maybe as a sidechain) solving
> the problem? If there would be a safe way for 0-confirmation transactions,
> the Bitcoin blockchain wouldn't even be needed.

Large scale consensus can't generally provide instantly irreversible transactions directly: Increasing the block speed can't help past the point where the time starts getting close to the network diameter... you simply can't tell what a consensus of a group of nodes is until several times the light cone that includes all of them. And if you start getting close to the limit you dilute the power working on the consensus and potentially make life easier for a large attacker.

Maybe other chains with different parameters could achieve a different tradeoff which was better suited to low value retail transactions (e.g. where you want a soft confirmation fast). A choice of tradeoffs could be very useful, and maybe you can practically get close enough (e.g. would knowing you lost a zero-conf double spend within 30 seconds 90% of the time be good enough?)... but I'm not aware of any silver bullet there which gives you something identical to what a centralized service can give you without invoking at least a little bit of centralization.

An interesting experiment would be a transaction "proof of publication" chain.

Each transaction would be added to that chain when it is received. It could be merge mined with the main chain.

If the size was limited, then it doesn't even require spam protection.

Blocks could be "discouraged" if they have transactions which violate the ordering in that chain. Miners could still decide which transactions they include, but couldn't include transactions which are double spends.

The locktime/final field could be used for transactions which want to be replaceable.

The chain could use some of the fast block proposals. For example, it could include orphans of a block when computing the block's POW.

On Wed, Apr 23, 2014 at 9:53 PM, Gregory Maxwell <gmaxwell@gmail•com> wrote:

> On Wed, Apr 23, 2014 at 1:44 PM, Adam Ritter <aritter@gmail•com> wrote:
> > Isn't a faster blockchain for transactions (maybe as a sidechain) solving
> > the problem? If there would be a safe way for 0-confirmation
> transactions,
> > the Bitcoin blockchain wouldn't even be needed.
>
> Large scale consensus can't generally provide instantly irreversible
> transactions directly: Increasing the block speed can't help past the
> point where the time starts getting close to the network diameter...
> you simply can't tell what a consensus of a group of nodes is until
> several times the light cone that includes all of them.  And if you
> start getting close to the limit you dilute the power working on the
> consensus and potentially make life easier for a large attacker.
>
> Maybe other chains with different parameters could achieve a different
> tradeoff which was better suited to low value retail transactions
> (e.g. where you want a soft confirmation fast). A choice of tradeoffs
> could be very useful, and maybe you can practically get close enough
> (e.g. would knowing you lost a zero-conf double spend within 30
> seconds 90% of the time be good enough?)... but I'm not aware of any
> silver bullet there which gives you something identical to what a
> centralized service can give you without invoking at least a little
> bit of centralization.
>
>
> ------------------------------------------------------------------------------
> Start Your Social Network Today - Download eXo Platform
> Build your Enterprise Intranet with eXo Platform Software
> Java Based Open Source Intranet - Social, Extensible, Cloud Ready
> Get Started Now And Turn Your Intranet Into A Collaboration Platform
> http://p.sf.net/sfu/ExoPlatform
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge•net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

On Wed, Apr 23, 2014 at 2:23 PM, Tier Nolan <tier.nolan@gmail•com> wrote:

> An interesting experiment would be a transaction "proof of publication"
> chain.
>
> Each transaction would be added to that chain when it is received.  It could
> be merge mined with the main chain.
>
> If the size was limited, then it doesn't even require spam protection.
>
> Blocks could be "discouraged" if they have transactions which violate the
> ordering in that chain.  Miners could still decide which transactions they
> include, but couldn't include transactions which are double spends.
>
> The locktime/final field could be used for transactions which want to be
> replaceable.
>
> The chain could use some of the fast block proposals.  For example, it could
> include orphans of a block when computing the block's POW.

You can see me proposing this kind of thing in a number of places (e.g. http://download.wpsoftware.net/bitcoin/wizards/2014-04-15.txt "p2pool only forces the subsidy today, but the same mechnism could instead force transactions.. e.g. to get you fast confirmation.", or previously on BCT for the last couple years) but there are still limits here: If you don't follow the fast-confirmation share chain you cannot mine third party transactions because you'll be at risk of mining a double spend that gets you orphaned, or building on a prior block that other miners have decided is bad. This means that if the latency or data rate requirements of the share chain are too large relative to ordinary mining it may create some centralization pressure.

That said, I think using a fast confirmation share-chain is much better than decreasing block times and could be a very useful tool if we believe that there are many applications which could be improved with e.g. a 30 second or 1 minute interblock time. Mostly my thinking has been that these retail applications really want sub-second confirmation, which can't reasonably be provided in this manner so I didn't mention it in this thread.

One of the neat things about this is that you can introduce it totally separately from Bitcoin without any consensus or approval from anyone else— E.g. P2pool builds such a chain today though it doesn't enforce transactions. It would immediately provide the useful service of demonstrating that some chunk of hashpower was currently working on including a particular set of transactions. Once the details were worked out it could be added as a soft-forking requirement to the commonly run system.

>
> These sorts of proposals are all just ways of saying block chains kind of
> suck and we should go back to using trusted third parties.
>

No. Different approaches have different trade-offs, and thus different areas of applicability.

Proof-of-work's inherent disadvantage is that it takes some time until transaction becomes practically irreversible. On the other hand, it has advantages like neutrality, censorship-resistance, high degree of security, etc.

TTP can be very efficient, but doesn't have advantages mentioned above.

It is possible to combine several different approaches into one hybrid systems. For example, classic Bitcoin PoW blockchain can be used for settlements, large transactions, savings and so on. While TTP-based payment system will be used for small-value transaction like buying coffee.

In this case you get benefits of both approaches. Censorship-resistance is irrelevant when one buys a cup of coffee with his pocket money, isn't it?

For some reason, instead of considering these hybrid solutions (which can also address scalability problems), you want to make PoW-based system more complex to be applicable for real-time transaction too.

This will, likely, weaken advantages provided by PoW, and also it won't provide any hard guarantees, and, if implemented, will undermine development of alternative solutions.

On Wed, Apr 23, 2014 at 10:39 PM, Gregory Maxwell <gmaxwell@gmail•com>wrote:

> You can see me proposing this kind of thing in a number of places (e.g.
> http://download.wpsoftware.net/bitcoin/wizards/2014-04-15.txt "p2pool
> only forces the subsidy today, but the same mechnism could instead
> force transactions..

Interesting. You set the share-block size to 16kB and set the share POW to 1/64 of the main target.

Each share-block would be allowed to append up to 16kB on the previous share-block.

This would keep the bandwidth the same, but on average blocks would be only 512kB.

e.g. to get you fast confirmation.", or

> previously on BCT for the last couple years) but there are still
> limits here:  If you don't follow the fast-confirmation share chain
> you cannot mine third party transactions because you'll be at risk of
> mining a double spend that gets you orphaned, or building on a prior
> block that other miners have decided is bad.  This means that if the
> latency or data rate requirements of the share chain are too large
> relative to ordinary mining it may create some centralization
> pressure.
>

This effect could be reduced by having "colours" for blocks and transactions.

The block colour would be a loop based on block height.

You could have 16 transaction "colours" based on the lowest 4 bits in the txId.

A transaction is only valid if all inputs into the transaction are the correct colour for that block.

This allows blocks to be created in advance. If you are processing colour 7 at the moment, you can have a colour 8 block ready.

16 colours is probably to many. It would only be necessary for things like 1 second block rates.

The disadvantage is that wallets would have to make sure that they have coins for each of the 16 colours.

If you spend the wrong colour, you add 16 block times of latency.

>
> That said, I think using a fast confirmation share-chain is much
> better than decreasing block times and could be a very useful tool if
> we believe that there are many applications which could be improved
> with e.g. a 30 second or 1 minute interblock time.  Mostly my thinking
> has been that these retail applications really want sub-second
> confirmation, which can't reasonably be provided in this manner so I
> didn't mention it in this thread.
>

In a shop setting, you could set it up so that the person scans a QR-code to setup a channel with the shop.

They can then scan all their stuff and by the time they have done that, the channel would be ready.

If there was a queue, it could be done when the person enters the queue.

In fact, there could be QR-codes at multiple locations.

On 4/23/2014 2:23 PM, Tier Nolan wrote:

> An interesting experiment would be a transaction "proof of
> publication" chain.

What if a transaction could simply point back to an earlier transaction, forming a chain? Not a separately mined blockchain, just a way to establish an official publication (execution) order. Double spends would be immediately actionable with such a sequence. Transactions in a block could eventually be required to be connected in such a chain. Miners would have to keep or reject a whole mempool chain, since they lack the keys to change the sequence. They would have to prune a whole tx subchain to insert a double spend (and this would still require private keys to the double spend utxo's).

This idea seemed promising, until I realized that with the collision rebasing required, it would barely scale to today's transaction rate. Something that scales to 10,000's of transactions per second, and really without limit, is needed.

Anyway, I wrote it up here: https://github.com/dgenr8/out-there/blob/master/tx-chains.md

On Thu, Apr 24, 2014 at 12:06 AM, Alex Mizrahi <alex.mizrahi@gmail•com>wrote:

>
> Different approaches have different trade-offs, and thus different areas
> of applicability.
>
> Proof-of-work's inherent disadvantage is that it takes some time until
> transaction becomes practically irreversible. On the other hand, it has
> advantages like neutrality, censorship-resistance, high degree of security,
> etc.
>

Sure, they have different tradeoffs. My assertion is this: the costs and disadvantages that come with building what is in effect an entirely parallel and separate system for stopping double spends, are much much worse than making simple tweaks to strengthen the mechanism we already have.

Put another way, the cost/benefit ratio of this proposal seems much better to me than the alternatives.

> In this case you get benefits of both approaches.
>

You also get the costs of both approaches, which are extremely significant.

Censorship-resistance is irrelevant when one buys a cup of coffee with his

> pocket money, isn't it?

That's like saying banks can't censor you because you can always withdraw all your money in cash. But in practice:

   1. That's a huge pain in the ass so nobody does it
   2. Many merchants will refuse non-trivial payments in cash and demand
   bank money because it's simpler for them

Analogously, having to wait some large expiry period to extract your money from the "double spending prevention service" (a.k.a. bitbank) is a pain in the ass, and many merchants would refuse to take your newly double spendable money even if theoretically they could, because it keeps their operations much simpler if they can just assume a sale is final and can't be reversed.

So I think such a scheme would rapidly return to the a world that looks much like the one we have now.

> For some reason, instead of considering these hybrid solutions (which can
> also address scalability problems), you want to make PoW-based system more
> complex to be applicable for real-time transaction too.
>

The complexity overhead is trivial - we already used coinbase scriptSigs for voting on P2SH, I'm sure it'll be used for voting on other things in future too. So that's already in place. Counting up votes and editing the UTXO set is the sort of patch one guy can create, it's not very big. And it's conceptually just the same as what miners can do today by re-orging out blocks, but with much less impact on end users and less implementation complexity (no giant reorgs that might themselves have to split recursively whilst they're being built).

On the other hand, building an entirely separate system, with separate trusted companies that have trusted brand names, adding support to all the wallets, getting all sellers on board, making everything use an extended BIP 70 (as that's the only real way to implement it), trying to explain to users why they're now expected to pay extra fees when they previously didn't and then discovering that you got a choice of only a handful of double-spend-preventers everyone could agree on with little potential for more .... that's hugely complex and messy.

> This will, likely, weaken advantages provided by PoW
>

Why? Remember deleting coinbases with nothing more than a simple majority is already possible in the existing protocol and always has been.

On Thu, Apr 24, 2014 at 12:58 AM, Mike Hearn <mike@plan99•net> wrote:

> The complexity overhead is trivial - we already used coinbase scriptSigs for
> voting on P2SH, I'm sure it'll be used for voting on other things in future
> too.

We use coinbase sigs to gauge the safety of enforcing a soft fork several times and not just for P2SH, to determine when enforcement of it will be decisive and not result in risking a partition in the network that might permit transaction reversals. This is not voting. As a feature decision mechanism his is a rather coercive thing because it gives the highest hash-power bidders control even when their interests may be rather thoroughly unaligned with population that owns and uses bitcoin in general, but as a plain indicator of when its safe to enforce a new rule (same mechanism, different motivation— though a point is that safe usage means using much more than 50% as the threshold) it works pretty well.

> .... that's hugely complex and messy.

Yes, making really distributed systems that work in a complex world is hard. It certantly would be /easier/ to just declare miners "trusted parties" and require them to always collude to produce a single consensus view of the world that is always honest and never contradictory, except that it doesn't work. Because they aren't individually trusted or even trustworthy.

> Why? Remember deleting coinbases with nothing more than a simple majority is
> already possible in the existing protocol and always has been.

Temporarily censoring transactions by orphaning otherwise valid blocks that contain them for as long as you retain a majority is possible and impossible to prevent in this architecture. This isn't the same as deleting. Deleting suggests the common misconception that a majority of miners can do anything they want.

On Thu, Apr 24, 2014 at 10:19 AM, Gregory Maxwell <gmaxwell@gmail•com>wrote:

> This is not voting.
>

It absolutely is! It was widely discussed as such at the time, here is a thread where people ask how to vote and the operator of Eclipse said he was removing his vote for P2SH:

https://bitcointalk.org/index.php?topic=60937.0

You might not feel it's a particularly fair or representative vote, but it's still miners saying "I support enforcement of this new rule" or "I do not support this" where the majority of cast votes wins. Some miners have more votes than others, but it's still a vote.

> Yes, making really distributed systems that work in a complex world is
> hard. It certantly would be /easier/ to just declare miners "trusted
> parties"
>

Miners *are* trusted parties, they are just not all trusted simultaneously. Bitcoin can tolerate a small number of dishonest miners whilst producing a degraded service. It cannot work if all miners are dishonest or decide to deviate from their intended operation, like if they all produce empty blocks. The white paper made this clear from the start, and it's also common sense.

Allowing the majority of honest miners to keep the dishonest ones in check is what Bitcoin is all about. I don't understand this view that a very small change to the existing protocol is somehow terrible or impossible, but expecting everyone to simply build an entirely new system from scratch is easy and inevitable. I'd much prefer to just keep the existing system working as well as it has so far, and I think that is true of most users too.

> Temporarily censoring transactions by orphaning otherwise valid blocks
> that contain them for as long as you retain a majority is possible

No, coinbases are deletable. If some miners fork the chain and build a longer one, the others will all switch to it and the coinbases blocks they previously mined will never become spendable (effectively they were "deleted" before maturity). Only if the other miners also blacklist the majorities fork and never join it, then the majority for some reason gives up and rejoins the minority, is what you described correct. But why would they do that? If they're the majority then all the other nodes will follow them. They have no incentive to throw away their fork and rejoin the minority chain ever again.

I think the root of this disagreement is whether the block chain algorithm left by Satoshi is somehow immutable and itself the end, or whether it's (as I see it) just a means to an end and therefore an algorithm that can be tweaked and improved, to get us closer to the goal.

If the end is a useful payments system, as decentralised as possible, that prevents double spending, then this proposal is a simple enhancement of the current system that ensures corrupt miners don't get paid by honest users for services they didn't provide, thus discouraging a particular kind of attack.

On Wednesday 23 April 2014 15:31:38 Mike Hearn wrote:

> > There _are_ consequences though: 95% of the time, you end up buying
> > something and paying for it.
>
> Yeah, I was imagining a situation in which people who use Bitcoin regularly
> do buy things they actually want, but wouldn't say no to occasionally
> getting them for free (think coffees at starbucks etc). So if their double
> spend fails, no big deal, they're no worse off than if they didn't try.

Again true enough; but then we're back to evenly distributed dishonesty, and so you still don't get the potential 5% scam being used at 100% capacity.

Andy

On Thu, Apr 24, 2014 at 1:39 AM, Mike Hearn <mike@plan99•net> wrote:

> It absolutely is!
> https://bitcointalk.org/index.php?topic=60937.0

May I direct your attention to the third post in that thread?

Luke attempting to ret-con the enforcement flag into a vote didn't make it one, and certantly wouldn't make it a fair, just, or sane method of one. And so much for the effectiveness— you didn't implement it for years even after it was deployed.

And yes, you can take any decision system and draw comparisons to voting and call it a vote but that doesn't mean is serves the same role or was intended for that purpose.

> No, coinbases are deletable. If some miners fork the chain and build a
> longer one, the others will all switch to it and the coinbases blocks they

Yes, you can reorg out the blocks and actually remove them, but I understood that you were _not_ proposing that quite specifically. But instead proposed without reorging taking txouts that were previously assigned to one party and simply assigning them to others.

> I think the root of this disagreement is whether the block chain algorithm
> left by Satoshi is somehow immutable and itself the end, or whether it's (as
> I see it) just a means to an end and therefore an algorithm that can be
> tweaked and improved, to get us closer to the goal.

I don't think thats the root of the the disagreement at all. I think all sorts of changes are interesting, especially ones that increase flexibility or fix bugs but less so ones that would impose significant changes on parties without their consent especially things that look like taking someone's coins and assigning them to someone else.

I think the root is that you believe that the miners are, should be, or even could be trustworthy in ways that I do not, and as a result you expect to be able to extract the performance of a trusted centralized system out of them that I do not. Bitcoin is a system where the incentives are well enough aligned that you appear to only need a small amount of altruism to make it reliable. ... and even summoning that altruism is a challenge— as miners hand over control of their hash-power to centralized pools (some known to have behaved poorly in the past), etc.

I would like that performance if it came at no cost: But proposals that miners conspiring to blacklist transactions/blocks produced by other people is something with a risk of a worse violation of the system's promises than some disagreement of the ordering of unconfirmed transactions. Pretty much immediately after your post Peter Todd— in his trouble making manner— went and posted on reddit proposing the mechanism be used to claw back mining income from a hardware vendor accused of violating its agreements on the amount of self mining / mining on customers hardware. While Peter's suggestion was no doubt intentionally trouble making— I'm not clear on where the line is here: Harm from reordering pretty much non-existent currently and is highly speculative, while the harm to miners by hardware vendors who've promised to not compete with their own customers or use their equipment is not at all speculative and very salient to miners.

This especially in light of the fact that the system already has an equitable method to decide what order transactions should be in... but instead you propose an additional complex heuristic system where based on some unspecified collusion some majority of miners take a minorities coins and assign them to themselves.

Unlike reorginization this form of wealth transferal has no collateral damage meaning that a majority cabal can use it to deprive a minority outsider of some or all income without risking disrupting the network, it would also lay the groundwork for additional forms of censorship which I believe would be at odds with the purpose and architecture of the system... and, as I noted above, it wouldn't actually prevent theft, it would just mean that no single block could make its theft services available to all comers (or even any of the public at all). The simple mechenism of allowing only only a small number of paid reordering transactions per block would prevent forming a quorum on the decision to revoke the coinbase, and you'd even get additional income from the probe transactions without even helping any real double spends at all. The incentives seem very hard to analyze.

>
> Yes, you can reorg out the blocks and actually remove them, but I
>

understood that you were _not_ proposing that quite specifically. But

> instead proposed without reorging taking txouts that were previously
> assigned to one party and simply assigning them to others.
>

Well, my original thought was just to delete the coinbases. But then some people don't like the idea of destroying money (equivalently, reducing the system's resolution) so I proposed reallocating it instead. I'm not sure which is better though. Deletion is closer to what the existing system allows, for sure.

Would you feel differently if the consequence was UTXO deletion rather than reallocation? I think the difference makes no impact to the goal of discouraging double spending.

> ... proposing the mechanism be used to claw back mining income from a
> hardware vendor accused of violating its agreements on the amount of
> self mining / mining on customers hardware.
>

I think this would not be doable in practice, unless there was a way to identify that a block was mined with pre-sold equipment. Peter points out that the pool in question is marking their blocks by reusing addresses - ditto for the double spending against dice sites - but that's a trivial thing for them to fix. Then it'd be difficult (impossible?) for miners to identify KnC blocks even if there was a strong majority consensus to delete their coinbases.

The reason I think this particular change is doable is that it should be possible to quite reliably identify blocks that are Finney attacking for profit. That doesn't generalise to any policy though. Blocks are intended to be structurally identical to each other if best practices are followed and even with the dire pool situation a big chunk of mining hash power today is effectively anonymous.

On 4/23/14, Mike Hearn <mike@plan99•net> wrote:

>> I guess word "honest" might have different meanings, that can be a source
>> of confusing.
>> 1. Honest -- not trying to destroy bitcoin
>> 2. Honest -- following rules which are not required by the protocol
>>
>
> I'm using it in the same sense Satoshi used it. Honest miners work to
> prevent double spends. That's the entire justification for their existence.

I thought the mechanism they used to prevent double-spends was proof of work. Therefore dishonest miners where only those who mine on top of a block which is not the longest valid chain they've seen. To distinguish this definition from your own "honest miners are those who decide on double-spends by mining the transaction they saw first" definition I propose to give another new name to the later, instead of changing the definition of the former. So inside the group of honest miners we have some that decide on transactions based on reception times and others that simply maximize their revenue while respecting the protocol rules. I suggest "stupid miners" and "smart miners" respectively as more clear terms for what we're talking about here.

> Miners that are deliberately trying to double spend are worse than useless.

I completely disagree. Miner's proof of work makes transactions irreversible. Even if zero confirmation transactions weren't possible in a replace-by-fee environment, that's very useful. Even if you always had to wait for transactions to be confirmed with some irreversible proof of work (as described in Satoshi's whitepaper), it doesn't follow that "automatically resolves the Bitcoin experiment as a failure". I don't understand how can you conclude that.

But in fact 0 conf txs are possible *precisely* using replace-by-fee, as described in the " 0 confirmation txs using replace-by-fee and game theory" thread. So that conclusion is definitely wrong.

On your concrete proposal, it seems to me that you're trying to prevent double-spending without relying on proof of work, which I think it impossible in the context of a truly p2p system. I don't think your current proposal is secure and I fear that at best you will end up with an "invite only" transaction processing network like Ripple.com has with their consensus algorithm and Unique Node Lists: that's not really p2p.

On Thu, Apr 24, 2014 at 1:22 PM, Jorge Timón <jtimon@monetize•io> wrote:

> > I'm using it in the same sense Satoshi used it. Honest miners work to
> > prevent double spends. That's the entire justification for their
> existence.
>
> I thought the mechanism they used to prevent double-spends was proof of
> work.
> Therefore dishonest miners where only those who mine on top of a block
> which is not the longest valid chain they've seen.
>

No! This is a misunderstanding. The mechanism they use to prevent double spends is to *ignore double spends*. The blocks they created indicate the ordering of transactions they saw and proof of work is used to arrive at a shared consensus ordering given the possibility that transactions arrived at different times.

I'm continually amazed at how many people seem to see the current algorithm as the goal in and of itself, instead of an imperfect but workable means of achieving the actual goal.

To distinguish this definition from your own "honest miners are those

> who decide on double-spends by mining the transaction they saw first"
>

This definition of honesty is not my own, the one Bitcoin has always used. Obviously if Satoshi had wanted transactions to be double spendable by fee in the mempool he would have made Bitcoin work that way, instead of coming up with the nSequence based replacement scheme instead.

First-seen *is* a protocol rule, as much as Set-Cookie storing data in a browser is an HTTP protocol rule. The fact that auditing compliance with it is harder to do than some others does not make it less of a rule.

I completely disagree.

> Miner's proof of work makes transactions irreversible.

Again you are hopelessly confused. Miners that are trying to double spend are *by definition* not making transactions irreversible, they are trying to make transactions reversible.

Look at it this way. There is no inherent reason BitUndo has to undo only Finney attacks. If it gets sufficient hash power it could offer undoing of 1-confirm transactions too, right? Sure it'll mostly fail but that's already a part of its business model. Sometimes it'll get two blocks in a row and succeed. It's a very minor tweak to what they're doing. Would you argue these miners are still useful? After all, it's impossible to be certain after the fact that miners built on top of the "wrong" block because forks occur naturally.

> Even if you always had to wait for transactions to be confirmed with
> some irreversible proof of work (as described in Satoshi's
> whitepaper), it doesn't follow that "automatically resolves the
> Bitcoin experiment as a failure". I don't understand how can you
> conclude that.
>

What I said is, if you believe all miners are willing to double spend for a fee then this resolves the experiment as a failure. This is also obvious - if you can pay miners to go back and rewrite the chain at will, Bitcoin doesn't work.

Consider the incentives. Let's say all miners are "smart" in your estimation and are willing to double spend transactions for higher fees. Because all miners follow this ridiculous policy, they should be willing to fork the chain at any point to claim the higher fee on the new tx. After all, although they will throw away the work they did on the previous chain, if the fee on the new tx is high enough to balance this then it can be profitable for them to do it.

Because a double spender can afford to give nearly all of his new tx away in fees, this means even txns well buried in the chain can be profitably double spent: even if the double spender gets back only 10% of the transferred amount, if it was a big transfer for some expensive object, they still win! They got object + 10%

Do you see now why your definition of honesty is completely broken?

On Thu, Apr 24, 2014 at 11:56:23AM +0200, Mike Hearn wrote:

> > ... proposing the mechanism be used to claw back mining income from a
> > hardware vendor accused of violating its agreements on the amount of
> > self mining / mining on customers hardware.
> >
>
> I think this would not be doable in practice, unless there was a way to
> identify that a block was mined with pre-sold equipment. Peter points out
> that the pool in question is marking their blocks by reusing addresses -
> ditto for the double spending against dice sites - but that's a trivial
> thing for them to fix. Then it'd be difficult (impossible?) for miners to
> identify KnC blocks even if there was a strong majority consensus to delete
> their coinbases.

Like I said before, that leads to the obvious next step of deleting/stealing their coinbases if they don't identify themselves.

Another likely outcome would be for coinbase blacklisting to be used as a way to force a minority of miners to adopt a transaction blacklist that the majority of miners had adopted. Any block containing transactions spending coins on the txout blacklist would itself be punished by having the block reward either blacklisted or taken.

> The reason I think this particular change is doable is that it should be
> possible to quite reliably identify blocks that are Finney attacking for
> profit. That doesn't generalise to any policy though.

It's not possible to produce a cryptographic proof that a given block engaged in a Finney attack. You're proposed coinbase blacklisting/reallocation mechanism is simply a way of voting on what coinbases to either blacklist or reallocation, nothing more.

On 4/24/14, Mike Hearn <mike@plan99•net> wrote:

> No! This is a misunderstanding. The mechanism they use to prevent double
> spends is to *ignore double spends*. The blocks they created indicate the
> ordering of transactions they saw and proof of work is used to arrive at a
> shared consensus ordering given the possibility that transactions arrived
> at different times.
>
> I'm continually amazed at how many people seem to see the current algorithm
> as the goal in and of itself, instead of an imperfect but workable means of
> achieving the actual goal.

I'm not saying proof of work is the goal, the goal is still p2p transaction serialization. And that's achieved through proof of work, not through "miner's honesty".

> This definition of honesty is not my own, the one Bitcoin has always used.

Whatever, let's keep calling stupid miners "honest miners", smart miners "dishonest-by-replace-by fee miners" and miners that do replace by fee and also hash on top of old blocks "utterly dishonest miners".

> Obviously if Satoshi had wanted transactions to be double spendable by fee
> in the mempool he would have made Bitcoin work that way, instead of coming
> up with the nSequence based replacement scheme instead.

Maybe Satoshi hadn't thought in depth about replace-by-fee when he wrote the code. Why should we care? If nSequence was a design mistake Satoshi did, should we maintain it to somehow honor him? Maybe the payment protocol shouldn't have been developed because he had some weird ideas about paying to ips? Maybe we shouldn't write any tests because he didn't do so? This persistent argument from authority is annoying.

> First-seen *is* a protocol rule, as much as Set-Cookie storing data in a
> browser is an HTTP protocol rule. The fact that auditing compliance with it
> is harder to do than some others does not make it less of a rule.

It is not a protocol rule that validators can use to discriminate the longest valid chain and therefore is not enforceable. Not even through a softfork because miners can't know which transactions other miners saw first. So if it is a protocol rule, I think it shouldn't be.

> Again you are hopelessly confused. Miners that are trying to double spend
> are *by definition* not making transactions irreversible, they are trying
> to make transactions reversible.

Miners that mine on top of the longest valid chain are helping in making transactions irreversible whether they implement a first-saw or a replace-by-fee policy.

> Look at it this way. There is no inherent reason BitUndo has to undo only
> Finney attacks. If it gets sufficient hash power it could offer undoing of
> 1-confirm transactions too, right? Sure it'll mostly fail but that's
> already a part of its business model. Sometimes it'll get two blocks in a
> row and succeed. It's a very minor tweak to what they're doing. Would you
> argue these miners are still useful? After all, it's impossible to be
> certain after the fact that miners built on top of the "wrong" block
> because forks occur naturally.

That's not what I'm saying. Miners that don't mine on top of the longest chain are dishonest by my own definition as well. You want to equate replace-by-fee "dishonesty" with trying-to-rewrite-history dishonesty by saying that the transactions that "have been seen" in the network are already history and that's where we disagree. I think only what's in the chain is history and I also think that's the whole point of proof of work. And I also disagree that all the people who think this way are "hopelessly confused". We may be confused, but I think there's always hope for removing confusions provided that there's will to learn, which I think it is at least my case.

> What I said is, if you believe all miners are willing to double spend for a
> fee then this resolves the experiment as a failure. This is also obvious -
> if you can pay miners to go back and rewrite the chain at will, Bitcoin
> doesn't work.

This is in fact quite polemic and thus obviously not obvious. Bitcoin works because rewriting the chain gets exponentially more expensive as time passes.

> Because all miners follow this ridiculous policy, they should be willing to
> fork the chain at any point to claim the higher fee on the new tx. After
> ...
>
> Do you see now why your definition of honesty is completely broken?

I see now that I may have not properly expressed myself in the earlier post since you clearly misunderstood what I meant by "smart miners". By that I mean miners implementing replace-by-fee and child-pays-for-parent policies Not miners trying to rewrite history, which I agree is about as smart as mining on top of orphan blocks.

>
> Like I said before, that leads to the obvious next step of
> deleting/stealing their coinbases if they don't identify themselves.
>

And as I said before, that's a huge leap. A majority of miners deciding double spending needs tougher enforcement doesn't imply they also think all miners should identify themselves. Those are unrelated things.

This kind of totally unsupported "obvious next step" argument can be applied to any proposal in any walk of life. We developed SPV clients? The obvious next step is that miners have to stop being anonymous. We developed floating fees? The obvious next step is that miners have to stop being anonymous. The prior arguments sound absurd exactly because they're not obvious or even logical - same as this.

>
> And that's achieved through proof of work, not through "miner's honesty".
>

You can't disentangle the two. Proof of work just makes a block chain hard to tamper with. What it contains is arbitrary. Honest miners build a block chain that's intended to stop double spending. Dishonest miners don't. They're both engaging in proof of work, to different ends.

> Whatever, let's keep calling stupid miners "honest miners"
>

No, let's not. Your definition of "smart miner" is one I'd called "stupid miner" (or possibly "short bitcoin miner"). They are miners who would reduce the value of their coins, by making their own system less useful. That's not smart, that's simply short termism taken to an extreme, sort of like a business owner who puts so much pressure on his employees they all quit. He might have gained a bit more profit in the short term, but only at the cost of destroying his business that would have given lower but sustainable returns over the long term.

> This persistent argument from authority is annoying.
>

Peter always says this too, but it's again an incorrect position. This is not an argument from authority.

Why are we here? We are here because we were brought together by shared goals.

What are those goals? They were defined at the start of the project by the creator of the project.

Why do we issue 21 million coins and not 42? Because 21 million is the goal everyone signed up for.

Why did everyone sign up for 21 million coins? Because that's what Satoshi picked.

If someone asked us to change from 21 to 42 million coins, we'd probably say no and the justification would be that this is the number we started with. That's not "argument from authority", it's just recognition that the parameters of a shared project has to be defined somehow, and for Bitcoin it was defined at the start.

Now the argument Gregory makes is that changing the block chain algorithm in this way would be a violation of the social contract. This is a generic outcome to be legitimately worried about - we don't want to change what Bitcoin is in ways that would dismay its users. That just leads to a fork.

I argue that this isn't such a change because it makes nothing possible that was previously impossible, it just makes it less disruptive, and the *actual* shared goal of Bitcoin is not "preserve the block chain algorithm exactly as found in v0.1" but rather "stop double spending".

You are arguing elsewhere that Bitcoin should allow double spending for a fee. That *would* be a clear violation of the social contract!

> That's not what I'm saying. Miners that don't mine on top of the
> longest chain are dishonest by my own definition as well.
>

Right, but I don't accept this definition of honesty. That's not a definition any man on the street would use:

    "If you pay for something with forged bank notes and walk out
immediately, you are honest. But if you pay for something with forged bank
notes and hang around for longer than 10 minutes, you are dishonest"

That would sound silly to anyone because what's so special about 10 minutes? It's the act of passing counterfeit money and stealing from the merchant that's the dishonest act, how long it takes is irrelevant.

In Bitcoin, the dishonest act by the user is signing for the same output twice (ignoring special protocols here), and the dishonest act by the miner is deviating from normal behaviour for a fee to try and trick the recipient into believing they have been paid. The exact details are something computer scientists care about, but the average Bitcoin user would not.

> And I also disagree that all the people who think this way are
> "hopelessly confused". We may be confused, but I think there's always
> hope for removing confusions provided that there's will to learn,
> which I think it is at least my case.
>

Indeed and that's why we have these threads! These are fundamental issues that simply must be debated.

Actually Peter, coinbase confiscations are a much worse mechanism for enforcement of widespread censorship rules than simple orphaning. They lose their power when the transaction miners are punished for can build up over time without losing their usefulness:

Assume a world where 75% of the hashpower is coerced into stealing/burning the coinbases of miners who allow transactions to and from a particular set of addresses (the actual rule isn't that important). Then the following would be a rational behaviour from the remaining 25%:

- Mine according to the enforced rules most of the time. - Accept banned transactions paying you with an output (no real miners' fees) and keep them in an ever-accumulating pool. - When there's so much of those to make it worth your while, mine a block filled with them.

If miners don't orphan your block, you made money. They can't retaliate further, because you can publish the block anonymously, not tying it to your previous identity. Hell, some of the 75% might be able to do the same right under the authorities' noses (it would be really hard to spot by an external observer).

Note that I, banned user, can submit to all these non-enforcing miners at once (with a different fee txout for each). I get a severe degradation of service, especially if I'm part of an extremely small minority, but ultimately as long as a single miner can accumulate enough transactions with enough fees, I'll eventually get through.

Of course, in such a dystopian future, orphaning would be the enforcement mechanism. It would be stupid to rely on coinbase reallocation/burning to do this task when the existing tools work so much better.

What's interesting is that this mechanism is especially tailored to blocking time sensitive transactions (that need to be confirmed now/soon, or are worthless), such that their total out-of-band fees can't build up over time. Double spending is one such category. I'm at a loss to come up with something else, but maybe someone has a good example?

On Thu, Apr 24, 2014 at 10:09 AM, Mike Hearn <mike@plan99•net> wrote:

>> Like I said before, that leads to the obvious next step of
>> deleting/stealing their coinbases if they don't identify themselves.
>
>
> And as I said before, that's a huge leap. A majority of miners deciding
> double spending needs tougher enforcement doesn't imply they also think all
> miners should identify themselves. Those are unrelated things.
>
> This kind of totally unsupported "obvious next step" argument can be applied
> to any proposal in any walk of life. We developed SPV clients? The obvious
> next step is that miners have to stop being anonymous. We developed floating
> fees? The obvious next step is that miners have to stop being anonymous. The
> prior arguments sound absurd exactly because they're not obvious or even
> logical - same as this.
>
>
>
> ------------------------------------------------------------------------------
> Start Your Social Network Today - Download eXo Platform
> Build your Enterprise Intranet with eXo Platform Software
> Java Based Open Source Intranet - Social, Extensible, Cloud Ready
> Get Started Now And Turn Your Intranet Into A Collaboration Platform
> http://p.sf.net/sfu/ExoPlatform
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge•net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

I wouldn't mind having $5 of my money held at Apple/Google/VISA/Mastercard/BitPay (and I wouldn't be sad of losing $5 if any of these companies go bankrupt). Actually I had in mind creating a centralized version of Bitcoin for ultra-fast payments. With keeping all addresses on SSDs, asking for 1 cent / address month, 1 cent / transaction should be possible to reach even with 6x replication. Companies could compete in price as long as the API is standardized. Automatic top-up should be simple as well.

On Wed, Apr 23, 2014 at 10:53 PM, Gregory Maxwell <gmaxwell@gmail•com>wrote:

> On Wed, Apr 23, 2014 at 1:44 PM, Adam Ritter <aritter@gmail•com> wrote:
> > Isn't a faster blockchain for transactions (maybe as a sidechain) solving
> > the problem? If there would be a safe way for 0-confirmation
> transactions,
> > the Bitcoin blockchain wouldn't even be needed.
>
> Large scale consensus can't generally provide instantly irreversible
> transactions directly: Increasing the block speed can't help past the
> point where the time starts getting close to the network diameter...
> you simply can't tell what a consensus of a group of nodes is until
> several times the light cone that includes all of them.  And if you
> start getting close to the limit you dilute the power working on the
> consensus and potentially make life easier for a large attacker.
>
> Maybe other chains with different parameters could achieve a different
> tradeoff which was better suited to low value retail transactions
> (e.g. where you want a soft confirmation fast). A choice of tradeoffs
> could be very useful, and maybe you can practically get close enough
> (e.g. would knowing you lost a zero-conf double spend within 30
> seconds 90% of the time be good enough?)... but I'm not aware of any
> silver bullet there which gives you something identical to what a
> centralized service can give you without invoking at least a little
> bit of centralization.
>

On Thu, Apr 24, 2014 at 10:47:35AM -0400, Christophe Biocca wrote:

> Actually Peter, coinbase confiscations are a much worse mechanism for
> enforcement of widespread censorship rules than simple orphaning. They
> lose their power when the transaction miners are punished for can
> build up over time without losing their usefulness:

<snip>

> Of course, in such a dystopian future, orphaning would be the
> enforcement mechanism. It would be stupid to rely on coinbase
> reallocation/burning to do this task when the existing tools work so
> much better.

I don't disagree with you at an end stage, but the thing with coinbase blacklists/confiscation is because it's a voting mechanism the initial stages of enforcing widespread censorship rules with it are much easier. For instance, if a 10% pool that has been forced/wants to blacklist certain transactions can do so, and then vote to blacklist blocks that do not abide by that blacklist. Casting that vote does them no harm. Every time another pool joins the blacklist, there's no harm to them to doing so. At some point they will reach a majority, which causes the blacklist to actually apply. The whole process happens smoothly, letting the blacklist be applied safely and easily. With orphaning/reorging on the other hand you just can't be sure that the other miners will actually adopt it, making adoption risky.

Of course, that's above and beyond the fact that you can't prove a Finney attack happened to a third-party, making it easy to attack smaller miners with Sybil attacks, get them creating blocks with double-spends in them, and using that as an excuse to punish them.

> What's interesting is that this mechanism is especially tailored to
> blocking time sensitive transactions (that need to be confirmed
> now/soon, or are worthless), such that their total out-of-band fees
> can't build up over time. Double spending is one such category. I'm at
> a loss to come up with something else, but maybe someone has a good
> example?

Decentralized markets are a great example: the bids and orders they depend on are time-senstive and become much less valuable if they get delayed greatly.

On 23/04/2014 05:51 p.m., Mike Hearn wrote:

> On Wed, Apr 23, 2014 at 10:44 PM, Adam Ritter <aritter@gmail•com
> <mailto:aritter@gmail.com>> wrote:
>
>     Isn't a faster blockchain for transactions (maybe as a sidechain)
>     solving the problem? If there would be a safe way for
>     0-confirmation transactions, the Bitcoin blockchain wouldn't even
>     be needed.
>
>
> The 10 minute average comes from a desire to balance wasted work due
> to natural chain splits with latency. With a very fast block interval
> you end up with lots of forks and things take longer to converge,
> also, it can make attacks easier because an attacker is building on
> his own blocks so he doesn't suffer propagation delays and the
> attendant splits.
>
> It's not clear you can just make a faster block chain. 10 minutes is
> somewhat arbitrary, it could be 5 minutes and the system would still
> work, but it probably can't be 5 seconds.

5 seconds block interval is possible. I've simulate it with great success and I encourage anyone to repeat or check my simulations.

There are a very few protocol modifications that are required to allow 5 seconds block, and most of them have already been discussed in the forums. For more information you can check my post: http://bitslog.wordpress.com/2014/02/17/5-sec-block-interval/ Also NimbleCoin is a new alt-coin that uses 5-sec block intervals, allows 100 tps and .... it's based on BitcoinJ (NimbleCoinJ now). So not only it is possible, but it was coded by Mike itself. Important note: the 5-sec block interval method probably requires a block reward forever. It doesn't work well if there is no block reward at all.

>
> Unfortunately for best physical-world usability you really need very
> fast payments. A few seconds is competitive with modern credit cards.

Another solution to achieve <5 secs block intervals is this: http://bitslog.wordpress.com/2014/03/20/mincen-a-new-protocol-to-achieve-instant-payments/

So the problem with 0-confirmations is solely of Bitcoin and other alt-coins, new alt-coins may achieve instant transactions and no not have to rely on 0-confirmations.

Best regards, Sergio.

Thanks Sergio!

On Thu, Apr 24, 2014 at 5:13 PM, Sergio Lerner <sergiolerner@certimix•com>wrote:

> For more information you can check my post:
> http://bitslog.wordpress.com/2014/02/17/5-sec-block-interval/
> Also NimbleCoin is a new alt-coin that uses 5-sec block intervals, allows
> 100 tps and .... it's based on BitcoinJ (NimbleCoinJ now). So not only it
> is possible, but it was coded by Mike itself.
>

Fascinating! I think that's the first time I heard of an alt coin entirely based on bitcoinj as its core implementation. Looking forward to your release.

My understanding is that dogecoin suffers somewhat from having so many headers. SPV clients have to download them all in sequence so the more blocks you have, the more data they must download and thus the slower they sync. Sync times for SPV wallets today are fast enough that unless you spend six months in the jungle with your phone switched off, you probably won't notice. With 5 second block times unless there's some other solution you'd have much worse UX.

BTW, Pieter experimented with relaying blocks as hash lists (actually merkleblocks) and I believe he found that it could often fail and be slower if the mempools were not quite synced. At any rate, it was apparently more complicated than it looked. That may be a side effect of trying to reuse the Bloom filtering code however.

> Another solution to achieve <5 secs block intervals is this:
> http://bitslog.wordpress.com/2014/03/20/mincen-a-new-protocol-to-achieve-instant-payments/
>

MinCen looks like a rather interesting idea. I will read the paper.

On 4/24/14, Mike Hearn <mike@plan99•net> wrote:

> You can't disentangle the two. Proof of work just makes a block chain hard
> to tamper with. What it contains is arbitrary. Honest miners build a block
> chain that's intended to stop double spending. Dishonest miners don't.
> They're both engaging in proof of work, to different ends.

Yes, you can disentangle replace-by-fee policies from "rewriting history" attacks. That's exactly what I'm saying. Proof of work is the most important thing that makes the blockchain hard to tamper with.

>> Whatever, let's keep calling stupid miners "honest miners"
>>
>
> No, let's not. Your definition of "smart miner" is one I'd called "stupid
> miner" (or possibly "short bitcoin miner"). They are miners who would
> reduce the value of their coins, by making their own system less useful.
> That's not smart, that's simply short termism taken to an extreme, sort of
> like a business owner who puts so much pressure on his employees they all
> quit. He might have gained a bit more profit in the short term, but only at
> the cost of destroying his business that would have given lower but
> sustainable returns over the long term.

Whatever, pick the terms yourself but let's just stick to the same ones, please. I've read this argument before, but I simply don't buy it because I disagree with the premise that replace-by-fee reduces the value of the coins (not to mention we shouldn't assume miners stock coins for long). I think replace-by-fee policies are actually an improvement over first-saw-first-included policies.

>> This persistent argument from authority is annoying.
>>
>
> Peter always says this too, but it's again an incorrect position. This is
> not an argument from authority.

I don't know about other occasions with other people but what you just used with me was an argument from authority fallacy. Now you're using a false analogy to try to convince us you didn't.

If I was saying "we should change the maximum from 21 M to 100 M because mining subsidies could continue for longer". "Mining subsidies aren't necessarily a good thing" or "That's no justification for a hardfork" or "That could destroy people's confidence in the currency" would be logical arguments.

"No, because Satoshi picked 21 M" would be an argument from authority fallacy.

>> That's not what I'm saying. Miners that don't mine on top of the
>> longest chain are dishonest by my own definition as well.
>>
>
> Right, but I don't accept this definition of honesty. That's not a
> definition any man on the street would use:

Whatever let's use whatever definitions you want, if I don't like your definition of honesty I will just invent a new term to define my own.

>     "If you pay for something with forged bank notes and walk out
> immediately, you are honest. But if you pay for something with forged bank
> notes and hang around for longer than 10 minutes, you are dishonest"

Sorry, I don't see the analogy.

> That would sound silly to anyone because what's so special about 10
> minutes? It's the act of passing counterfeit money and stealing from the
> merchant that's the dishonest act, how long it takes is irrelevant.

10 minutes is what Satoshi picked. Just kidding...

> In Bitcoin, the dishonest act by the user is signing for the same output
> twice (ignoring special protocols here), and the dishonest act by the miner
> is deviating from normal behaviour for a fee to try and trick the recipient
> into believing they have been paid. The exact details are something
> computer scientists care about, but the average Bitcoin user would not.

People need to understand that Bitcoin transactions are not instant. For instants transactions you need to rely somehow on trust, use some trust-less offchain mechanism or use a payment protocol that would make double-spending irrational (like the one described in the other thread that uses replace-by-fee). So I think miner's default behavior should be replace-by-fee. But that doesn't imply that I want miners to rewrite pow-validated history.

> Casting that vote does them no harm.
> Every time another pool joins the blacklist, there's no harm to them to doing so.

I actually agree that this is a problem, but that's actually not inherent in the proposed enforcement mechanism (just the current voting rules).

Here's an alternate:

- To start a vote, you set aside a part of your coinbase with amount X <= their entire coinbase amount. - Then you need 51 blocks with a "yes" vote before the coinbase maturity of the target for the vote to be considered a success. - Success means target coinbase has X coins reallocated/burned. - Failure means vote-initiating coinbase has X coins reallocated/burned.

The incentives for voting miners are to vote yes if and only if they dislike the targeted miner more than the initiator (all other monetary effects are identical). That isn't a bulletproof way to force miners to only punish double spenders (rather than anything they dislike in general), but it removes the risk free nature of trying to take away another miner's coinbase.

It means that you'll need a high level of confidence other miners are on your side before taking a risk, but, because you've got a much longer time frame than 10 minutes, you can get manual confirmation from other miners.

On Thu, Apr 24, 2014 at 11:03 AM, Peter Todd <pete@petertodd•org> wrote:

> On Thu, Apr 24, 2014 at 10:47:35AM -0400, Christophe Biocca wrote:
>> Actually Peter, coinbase confiscations are a much worse mechanism for
>> enforcement of widespread censorship rules than simple orphaning. They
>> lose their power when the transaction miners are punished for can
>> build up over time without losing their usefulness:
> <snip>
>> Of course, in such a dystopian future, orphaning would be the
>> enforcement mechanism. It would be stupid to rely on coinbase
>> reallocation/burning to do this task when the existing tools work so
>> much better.
>
> I don't disagree with you at an end stage, but the thing with coinbase
> blacklists/confiscation is because it's a voting mechanism the initial
> stages of enforcing widespread censorship rules with it are much easier.
> For instance, if a 10% pool that has been forced/wants to blacklist
> certain transactions can do so, and then vote to blacklist blocks that
> do not abide by that blacklist. Casting that vote does them no harm.
> Every time another pool joins the blacklist, there's no harm to them to
> doing so.  At some point they will reach a majority, which causes the
> blacklist to actually apply. The whole process happens smoothly, letting
> the blacklist be applied safely and easily.  With orphaning/reorging on
> the other hand you just can't be sure that the other miners will
> actually adopt it, making adoption risky.
>
> Of course, that's above and beyond the fact that you can't prove a
> Finney attack happened to a third-party, making it easy to attack
> smaller miners with Sybil attacks, get them creating blocks with
> double-spends in them, and using that as an excuse to punish them.
>
>> What's interesting is that this mechanism is especially tailored to
>> blocking time sensitive transactions (that need to be confirmed
>> now/soon, or are worthless), such that their total out-of-band fees
>> can't build up over time. Double spending is one such category. I'm at
>> a loss to come up with something else, but maybe someone has a good
>> example?
>
> Decentralized markets are a great example: the bids and orders they
> depend on are time-senstive and become much less valuable if they get
> delayed greatly.
>
> --
> 'peter'[:-1]@petertodd.org
> 0000000000000000091ae589c034bc0466e2feca51dc018bb2c3303e8ab8648b

>
> Casting that vote does them no harm.
> Every time another pool joins the blacklist, there's no harm to them to
> doing so.  At some point they will reach a majority

These statements do not follow from each other.

On 04/24/2014 03:37 PM, Jorge Timón wrote:

The 21 million bitcoin limit is not important because of its exact value, nor is it important because Satoshi picked it.

The 21 million limit is important because users hold bitcoin based on the promise that the block reward will never be adjusted ex post facto. The behavior users are relying on is "The bitcoins you hold are forever a calculable fraction of all the bitcoins that will ever be issued."

That's what bitcoin holders agreed to, and that's what can never be changed.

The fact that the number is arbitrary is not relevant. We can agree to meet for lunch at some arbitrarily chosen time, and the fact that the time was chosen arbitrary in no way means that one party arbitrarily choosing not to show up doesn't break the agreement.

- -- Support online privacy by using email encryption whenever possible. Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k

On 25/04/14 00:28, Mike Hearn wrote:

> Why are we here? We are here because we were brought together by shared
> goals.
>
> What are those goals? They were defined at the start of the project by
> the creator of the project.
>
> Why do we issue 21 million coins and not 42? Because 21 million is the
> goal everyone signed up for.

Mike: the blockchain is a public document, with a very public and well defined interpretation, which we've all signed up for too.

What's the point of piling PoW on top of some data to make it difficult to modify if the interpretation itself is open to modification?

There is an important distinction to draw between a hard fork via a change in block validation rules, and a hard fork via a change in the /interpretation of the blockchain itself/.

Bitcoin validates data /before/ it makes it into a block; we can all be confident that, short of a reorg, /if it's in a block, it's the law/. As much as the 21m cap is the law anyway.

Proving that you can convince the economic majority that the interpretation of existing blocks is in any way up for grabs would set a dangerous precedent, and shake some people's faith in Bitcoin's overall robustness and security (well, mine anyway.)

My 2 bits.

-Gareth

>
> Proving that you can convince the economic majority that the
>

interpretation of existing blocks is in any way up for grabs would set a

> dangerous precedent, and shake some people's faith in Bitcoin's overall
> robustness and security (well, mine anyway.)

Hmm, then I think your faith needs to be shaken. Bitcoin is money, and money is a purely artificial social construct. The interpretation of what a bitcoin means, or what a dollar means, has always been and always will be a human decision taken in order to achieve some socially useful goal. How could it be any other way? Do you want humanity to be enslaved by its own money?

This notion that the block chain encodes some kind of natural, immovable law that's above human judgement is a very strange one to me - I guess it comes from the fact that encryption *is* based on some kind of natural law. Without the key you can't decrypt a message no matter how strong the consensus is. But Bitcoin doesn't use encryption anywhere, just digital signatures. The only thing approaching natural law, that stops majority consensus controlling everything, is lack of information. Hence all the discussion around privacy and anonymity that goes on all the time.

On 25/04/14 20:17, Mike Hearn wrote:

>     Proving that you can convince the economic majority that the
>
>     interpretation of existing blocks is in any way up for grabs would set a
>     dangerous precedent, and shake some people's faith in Bitcoin's overall
>     robustness and security (well, mine anyway.)
>
>
> Hmm, then I think your faith needs to be shaken. Bitcoin  is money, and
> money is a purely artificial social construct. The interpretation of
> what a bitcoin means, or what a dollar means, has always been and always
> will be a human decision taken in order to achieve some socially useful
> goal.

My argument does not concern what a bitcoin means, just what data in the blockchain means. People are free to value an individual bitcoin however they like. But it's useful if we all agree on a standard that defines who owns them - ie. the protocol as described in Satoshi's whitepaper. I recognise that your ability to provide a valid scriptSig for /any existing UTXO in the blockchain/ as proof of your ownership of the corresponding bitcoin. You want to pick and choose which UTXO (well, coinbase; same diff) you consider valid and spendable /after they've become part of the blockchain/, regardless of the fact they're buried under PoW.

As an illustration, consider Counterparty - an altcoin whose TXns are embedded as unvalidated data in the bitcoin blockchain. A lot of people imagine that an XCP transaction buried under 100 blocks and a BTC transaction buried under the same 100 blocks are equally secure. You tell me: are they? It's the same PoW chain after all.

Hell no they're not! The way Counterparty interprets that data in the blockchain is anything but stable or well documented. On more than one occasion they've gone "whoops, found a bug that caused some transactions to occur that we don't consider valid - we'll just fix that." A suddenly the reference client doesn't consider the XCP in your wallet valid anymore - they just magically disappear - because the parent of the TXn that paid you was actually invalid. Nobody rewrote history via PoW; they simply tweaked their interpretation of the existing history.

When you have a *bitcoin* TXn buried under 100 blocks you can be damn sure that money is yours - but only because the rules for interpreting data in the blockchain are publicly documented and (hopefully) immutable. If they're mutable then the PoW alone gives me no confidence that the money is really mine, and we're left with a much less useful system. This should be more sacred than the 21m limit.

>
> When you have a *bitcoin* TXn buried under 100 blocks you can be damn
>

sure that money is yours - but only because the rules for interpreting

> data in the blockchain are publicly documented and (hopefully)
> immutable. If they're mutable then the PoW alone gives me no confidence
> that the money is really mine, and we're left with a much less useful
> system. This should be more sacred than the 21m limit.

Well, I think we should avoid the term "sacred" - nothing is sacred because we're not building a religion here, we're engineering a tool.

Consider a world in which 1 satoshi is too valuable to represent some kinds of transactions, so those transactions stop happening even though we all agree they're useful. The obvious solution is to change the rules so there can be 210 million coins and 10x everyones UTXOs at some pre-agreed flag day. We probably wouldn't phrase it like that, it's easier for people to imagine what's happening if it's phrased as "adding more places after the decimal point" or something, but at the protocol level coins are represented using integers, so it'd have to be implemented as a multiply.

Would this be a violation of the social contract? A violation of all that is sacred? I don't think so, it'd just be sensible engineering and there'd be strong consensus for that exactly because 21 million *is* so arbitrary. If all balances and prices multiply 100-fold overnight, no wealth is reallocated which would be the *actual* violation of the social contract: we just get more resolution for setting prices.

So. The thing that protects your money from confiscation is not proof of work. PoW is just a database synchronisation mechanism. The thing that protects your money from confiscation is a strong group consensus that theft is bad. But that's a social rule, not a mathematical rule.

On 26/04/14 01:28, Mike Hearn wrote:

>     When you have a *bitcoin* TXn buried under 100 blocks you can be damn
>
>     sure that money is yours - but only because the rules for interpreting
>     data in the blockchain are publicly documented and (hopefully)
>     immutable. If they're mutable then the PoW alone gives me no confidence
>     that the money is really mine, and we're left with a much less useful
>     system. This should be more sacred than the 21m limit.
>
>
> Well, I think we should avoid the term "sacred" - nothing is sacred
> because we're not building a religion here, we're engineering a tool.

Are you sure there isn't room for just a touch of "religion"? :) As you state below, all that protects my money from confiscation is strong group consensus that it's mine - "a social rule, not a mathematical one."

Everything ultimately balances on that. People being a little bit "religious" about following the protocol faithfully are the linchpin of Bitcoin security, not PoW.

> Consider a world in which 1 satoshi is too valuable to represent some
> kinds of transactions, so those transactions stop happening even though
> we all agree they're useful. The obvious solution is to change the rules
> so there can be 210 million coins and 10x everyones UTXOs at some
> pre-agreed flag day. We probably wouldn't phrase it like that, it's
> easier for people to imagine what's happening if it's phrased as "adding
> more places after the decimal point" or something, but at the protocol
> level coins are represented using integers, so it'd have to be
> implemented as a multiply.

Agree.

> Would this be a violation of the social contract? A violation of all
> that is sacred? I don't think so, it'd just be sensible engineering and
> there'd be strong consensus for that exactly because 21 million /is/ so
> arbitrary. If all balances and prices multiply 100-fold overnight, no
> wealth is reallocated which would be the /actual/ violation of the
> social contract: we just get more resolution for setting prices.

Wholeheartedly agree. "21 million" is just shorthand for the preservation of artificial scarcity. No rational person could argue that what you described violates the social contract.

I do see what you're driving at - that there exists a situation where it would be justified to change the interpretation of data in existing blocks.

But, please consider: if I controlled a single UTXO worth 1% of the total money supply before your change, the network would still recognise that I control a single UTXO worth 1% of the total money supply after your change. So you haven't really changed the interpretation of existing blocks at all there. It's just semantics :)

Contrast this with invalidating a coinbase before maturity, which clearly has a very real impact. At the point the vote passes, you're *** sidestepping the PoW mechanism and rewriting the meaning of an existing, validated block ***.

> So. The thing that protects your money from confiscation is not proof of
> work. PoW is just a database synchronisation mechanism. The thing that
> protects your money from confiscation is a strong group consensus that
> theft is bad. But that's a social rule, not a mathematical rule.

Agree. That's my whole point :)

I recognise my security is in the hands of the users (the economic majority.) Tomorrow they could all decide to patch their nodes to reallocate my UTXOs, and there's not a damn thing I could do about it, PoW and private keys notwithstanding. I must simply trust that they will not do this.

So we can have: 1. "Neutral Bitcoin", where everyone is committed to prevention of theft by following a simple set of mathematical rules which treat all validated blocks as equal. Or: 2. "Political Bitcoin", where everyone is committed to prevention of theft based on human judgements, and the contents of some validated blocks are more equal than others.

I recognise that the latter allows for a lot of flexibility in combating fraud, but with (substantial) due respect, it isn't Bitcoin.

-Gareth

This seems like splitting hairs, no? A block isn't a guarantee (it can get orphaned). And as a user of bitcoin (as opposed to a miner), this change cannot affect any payment you ever receive.

Some of the interpretation is already different for coinbase UTXO's (need a valid height, locked for 100 blocks). Anyone expecting them to behave like any other UTXO will get bitten by one of those subtleties (MtGox's withdrawals had issues with exactly this, IIRC).

On Sat, Apr 26, 2014 at 8:15 AM, Gareth Williams <gacrux@gmail•com> wrote:

> On 26/04/14 01:28, Mike Hearn wrote:
>>     When you have a *bitcoin* TXn buried under 100 blocks you can be damn
>>
>>     sure that money is yours - but only because the rules for interpreting
>>     data in the blockchain are publicly documented and (hopefully)
>>     immutable. If they're mutable then the PoW alone gives me no confidence
>>     that the money is really mine, and we're left with a much less useful
>>     system. This should be more sacred than the 21m limit.
>>
>>
>> Well, I think we should avoid the term "sacred" - nothing is sacred
>> because we're not building a religion here, we're engineering a tool.
>
> Are you sure there isn't room for just a touch of "religion"? :) As you
> state below, all that protects my money from confiscation is strong
> group consensus that it's mine - "a social rule, not a mathematical one."
>
> Everything ultimately balances on that. People being a little bit
> "religious" about following the protocol faithfully are the linchpin of
> Bitcoin security, not PoW.
>
>
>> Consider a world in which 1 satoshi is too valuable to represent some
>> kinds of transactions, so those transactions stop happening even though
>> we all agree they're useful. The obvious solution is to change the rules
>> so there can be 210 million coins and 10x everyones UTXOs at some
>> pre-agreed flag day. We probably wouldn't phrase it like that, it's
>> easier for people to imagine what's happening if it's phrased as "adding
>> more places after the decimal point" or something, but at the protocol
>> level coins are represented using integers, so it'd have to be
>> implemented as a multiply.
>
> Agree.
>
>
>> Would this be a violation of the social contract? A violation of all
>> that is sacred? I don't think so, it'd just be sensible engineering and
>> there'd be strong consensus for that exactly because 21 million /is/ so
>> arbitrary. If all balances and prices multiply 100-fold overnight, no
>> wealth is reallocated which would be the /actual/ violation of the
>> social contract: we just get more resolution for setting prices.
>
> Wholeheartedly agree. "21 million" is just shorthand for the
> preservation of artificial scarcity. No rational person could argue that
> what you described violates the social contract.
>
> I do see what you're driving at - that there exists a situation where it
> would be justified to change the interpretation of data in existing blocks.
>
> But, please consider: if I controlled a single UTXO worth 1% of the
> total money supply before your change, the network would still recognise
> that I control a single UTXO worth 1% of the total money supply after
> your change. So you haven't really changed the interpretation of
> existing blocks at all there. It's just semantics :)
>
> Contrast this with invalidating a coinbase before maturity, which
> clearly has a very real impact. At the point the vote passes, you're ***
> sidestepping the PoW mechanism and rewriting the meaning of an existing,
> validated block ***.
>
>
>> So. The thing that protects your money from confiscation is not proof of
>> work. PoW is just a database synchronisation mechanism. The thing that
>> protects your money from confiscation is a strong group consensus that
>> theft is bad. But that's a social rule, not a mathematical rule.
>
> Agree. That's my whole point :)
>
> I recognise my security is in the hands of the users (the economic
> majority.) Tomorrow they could all decide to patch their nodes to
> reallocate my UTXOs, and there's not a damn thing I could do about it,
> PoW and private keys notwithstanding. I must simply trust that they will
> not do this.
>
> So we can have:
> 1. "Neutral Bitcoin", where everyone is committed to prevention of theft
> by following a simple set of mathematical rules which treat all
> validated blocks as equal.
> Or:
> 2. "Political Bitcoin", where everyone is committed to prevention of
> theft based on human judgements, and the contents of some validated
> blocks are more equal than others.
>
> I recognise that the latter allows for a lot of flexibility in combating
> fraud, but with (substantial) due respect, it isn't Bitcoin.
>
> -Gareth
>
>
> ------------------------------------------------------------------------------
> Start Your Social Network Today - Download eXo Platform
> Build your Enterprise Intranet with eXo Platform Software
> Java Based Open Source Intranet - Social, Extensible, Cloud Ready
> Get Started Now And Turn Your Intranet Into A Collaboration Platform
> http://p.sf.net/sfu/ExoPlatform
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge•net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

On 27/04/14 11:42, Christophe Biocca wrote:> This seems like splitting hairs, no? A block isn't a guarantee (it can

> get orphaned). And as a user of bitcoin (as opposed to a miner), this
> change cannot affect any payment you ever receive.

Disagree. Maybe we just have a fundamental disagreement about what Bitcoin is? :)

Bitcoin is this perfect /trustless/ mathematical machine, built - most unfortunately - upon a foundation of mushy humans.

We depend specifically upon these three assumptions: 1. >50% of hashpower will not cooperate to rewrite history 2. the economic majority will not cooperate to reinterpret history 3. enough people believe in the illusion of artificial scarcity to give it real value

Given that the above hold, from there up the system operates completely trustlessly, with predictable security parameters. (Of course a block isn't a guarantee of anything, but I know the probability that you can cause a re-org from depth N with X% hashpower, which allows me to reason about security.)

Now, some people on this thread might point to the above 3 points and say "that isn't really a trustless system, it's a democratic system." And then advocate that we can do without assumption 2, replacing it with: 2. the economic majority will not cooperate to reinterpret history against any good guys, only against bad guys; "please trust their good judgement."

That moves us away from a pure trustless system built upon a small democratic foundation (as something of a necessary evil in an imperfect world where humans run our computers and use our system) and toward a "democratic system".

You don't have to agree, but I hope you can understand the point I'm making :-) It's a fundamental shift in the nature of the system, and to some people a violation of the social contract. Definitely not splitting hairs.

I feel I've now consumed rather more bytes of everyone's inboxes than I ought to have with this topic. I appreciate you and Mike taking the time to reply to a newbie/lurker.

-Gareth

>
> That moves us away from a pure trustless system built upon a small
> democratic foundation (as something of a necessary evil in an imperfect
> world where humans run our computers and use our system) and toward a
> "democratic system".
>
> You don't have to agree, but I hope you can understand the point I'm
> making :-)

Yep, your point is well made.

I don't have much more to say about this proposal specifically, but I think this whole question of what changes are OK and what would be a violation of the social contract will get discussed endlessly over the coming years. Put another way, what do Bitcoin's users expect and want - a system that evolves or a system that remains exactly as they found it? There will be good arguments on both sides, and the answer will probably be different on a case by case basis. But personally I'm skeptical of any argument that argues against change for its own sake. It has to be an argument rooted in a careful analysis of costs and benefits.

Agreed. I'm a pragmatist, certainly not anti-change (or even anti-zero-conf.) Useful and non-controversial hard forks don't keep me awake at night :) I support your general position on zero-conf payments (that they're useful and we should make them as reliable as practical.)

But the very essence of Bitcoin, to me, is trustlessness. Satoshi's great invention isn't just another payment network - it's /ecash/. Bearer-negotiable, whoever-controls-the-private-keys-owns-it, **ecash**.

If not that, what do you think it is? :-)

I like trustless systems for purely pragmatic, cost-benefit reasons. They allow us to avoid all the costs associated with imperfect humans, while reaping the benefits of reliability and predictability :P

On 28 April 2014 12:31:05 AM AEST, Mike Hearn <mike@plan99•net> wrote:

>>
>> That moves us away from a pure trustless system built upon a small
>> democratic foundation (as something of a necessary evil in an
>imperfect
>> world where humans run our computers and use our system) and toward a
>> "democratic system".
>>
>> You don't have to agree, but I hope you can understand the point I'm
>> making :-)
>
>
>Yep, your point is well made.
>
>I don't have much more to say about this proposal specifically, but I
>think
>this whole question of what changes are OK and what would be a
>violation of
>the social contract will get discussed endlessly over the coming years.
>Put
>another way, what do Bitcoin's users expect and want - a system that
>evolves or a system that remains exactly as they found it? There will
>be
>good arguments on both sides, and the answer will probably be different
>on
>a case by case basis. But personally I'm skeptical of any argument that
>argues against change for its own sake. It has to be an argument rooted
>in
>a careful analysis of costs and benefits.

On Sun, Apr 27, 2014 at 10:53:08PM +1000, Gareth Williams wrote:

>Bitcoin is this perfect /trustless/ mathematical machine [...]
>
>2. the economic majority will not cooperate to reinterpret history
>
> [this proposal was...] replacing it with:
>
>2. the economic majority will not cooperate to reinterpret history
>against any good guys, only against bad guys; "please trust their good
>judgement."

Nicely put.

I agree the idea of a populist vote to redistribute or remove mining reward is an inelegant thing which would probably devolve into politics.

I think the reason that it would likely work out badly is that its not provable, and so no consensus rule can be constructed requiring proof, so then it risks devolving to a political decision.

Step 1: Finney attackers for hire anonymize their blocks (publish via Tor, use a different reward address for each block, and each pool miner). Demanding identification of blocks is generally undesirable for the objective of avoiding centralization and policy abuse. Dont even think about demanding identity, there is no identity in a distributed system.

Step 2: people send tracer payments through Finney attackers, and use that evidence to decide to vote away their reward. (However the proof is non-transitive so people can vote anyway they like for any reason).

Step 3: Finney attackers vote down other pools to make the point.

Adam

I do think we need to move beyond this idea of Bitcoin being some kind of elegant embodiment of natural mathematical law. It just ain't so.

Every time miners and nodes ignore a block that creates >formula() coins that's a majority vote on a controversial political matter, as evidenced by the disagreement with mainstream economics and that it's one of the most common things for alt coins to change. Indeed Satoshi's chosen inflation formula is a highly political statement on the value of inflation - he could have programmed Bitcoin to inflate forever and avoided a whole area of politics, but he chose not to.

So please, let's agree to accept that Bitcoin is ultimately just a piece of software that encodes rules helping us run our little community in some specific ways. It's not physics and we should believe our own hype by pretending it is.

On Mon, Apr 28, 2014 at 11:41 PM, Adam Back <adam@cypherspace•org> wrote:

> I think the reason that it would likely work out badly is that its not
> provable, and so no consensus rule can be constructed requiring proof, so
> then it risks devolving to a political decision.
>

It's the other way around. If miners decide to fork the chain then that leaves no proof (beyond the old blocks, which could have been a natural fork - there's no way to know - and nodes don't want to keep them around anyway). If they explicitly vote to get the same effect but without actually forking, it leaves a proof in the form of the votes in the coinbase that can be seen afterwards.

> Step 3: Finney attackers vote down other pools to make the point.

It only works if the majority of hashpower is controlled by attackers, in which case Bitcoin is already doomed. So it doesn't matter at that point.

On Tue, Apr 29, 2014 at 7:13 AM, Mike Hearn <mike@plan99•net> wrote:

> It only works if the majority of hashpower is controlled by attackers, in
> which case Bitcoin is already doomed. So it doesn't matter at that point.

These parties wouldn't generally consider themselves attackers— nor would many users (presumably everyone who mines on ghash.io, for example)— rather they'd they may consider someone using hashpower voting to reassign coins to be an attacker, and reassigning their coins instead to be a morally justified and pragmatic response.

I think we're capable here of discussing the specifics without needing to use generalizations which invite definitional arguments... I don't think that bombastic language like doomed helps the dialog.

>
> These parties wouldn't generally consider themselves attackers
>

Of course not, attackers rarely do :)

But they are miners who are taking part in malicious double spending. That makes them attackers. If miners don't exist to stop double spending, what do they exist for?

I mean, this is fundamental. What do you think miners exist for?

On 04/29/2014 02:13 PM, Mike Hearn wrote:

> I do think we need to move beyond this idea of Bitcoin being some
> kind of elegant embodiment of natural mathematical law. It just
> ain't so.
>

I think everybody understands that Bitcoin has a positive net present value exactly because it, unlike every other digital currency which came before, does not include a feature that allows for balances to be confiscated. Implementing any such feature, to any degree at all, would render Bitcoin completely valueless.

There are two possibilities here:

If you understand this, then your proposal is a malicious attempt to undermine Bitcoin.

If you don't understand this then you suffer from a very serious case of economic illiteracy, a case so bad that your continued participation in Bitcoin represents a clear and present danger to all Bitcoin users. If you can't even get the easy questions right, then god help us all if you're ever faced with a difficult one.

I don't have enough evidence to distinguish between the incompetence hypothesis and the malice hypothesis, but it doesn't matter. Regardless of your abilities or motives your proposal is unacceptable. If you want a currency where miners can vote to steal from other miners then implement it in Hearncoin and leave Bitcoin alone.

- -- Support online privacy by using email encryption whenever possible. Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k

On 30/04/14 00:13, Mike Hearn wrote:

> I do think we need to move beyond this idea of Bitcoin being some kind
> of elegant embodiment of natural mathematical law. It just ain't so.

I haven't seen anybody arguing that it is.

Bitcoin is the elegant embodiment of /artificially contrived/ mathematical rules, which just so happen to be very useful in their current configuration :-P

Nobody is saying those rules are immutable. Just that it isn't sensible to undermine them by introducing imprecise and unpredictable elements like human politics.

> Every time miners and nodes ignore a block that creates >formula() coins
> that's a majority vote on a controversial political matter

No it isn't. That's the node enforcing the protocol. It isn't a matter of opinion, and it isn't a vote. The protocol is clearly defined: you either follow it or you're not running a Bitcoin node. If 51% don't follow it tomorrow /they're/ not running Bitcoin.

Contrast with your "vote to reinterpret the meaning of arbitrary blocks" mechaism - you're free to vote either way while remaining within the protocol. That's a /real/ vote - majority decides what the Bitcoin protocol /and every node that follows it/ will recognise as valid. Nothing like that currently exists. Thank $deity.

On 30/04/14 00:26, Mike Hearn wrote:

>     These parties wouldn't generally consider themselves attackers
>
>
> Of course not, attackers rarely do :)

If Bitcoin works correctly nobody should have to care if they consider themselves attackers, defenders, or little green men from Mars. There are simply nodes that follow the protocol, and nodes that do not.

The fact that you even need to think about who should and should not be considered an attacker, in the context of your proposed change, should be ringing alarm bells :)

> What do you think miners exist for?

Ordering transactions.

I think we're going around in circles here so this will be my last message on the thread unless someone comes up with something new.

On Wed, Apr 30, 2014 at 3:12 PM, Gareth Williams <gacrux@gmail•com> wrote:

> If Bitcoin works correctly nobody should have to care if they consider
> themselves attackers, defenders, or little green men from Mars.

One last time, I request that people read the white paper from 2008 before making statements like this. If the notion of attacker was irrelevant to Bitcoin, it would not be mentioned in the abstract, would it?

On 30/04/14 00:13, Mike Hearn wrote:

> Every time miners and nodes ignore a block that creates >formula() coins
> that's a majority vote on a controversial political matter

Actually, there's one more thing I'd like to add. Apologies to the list, but it bears repeating:

* rejecting a block at validation

Is /very different/ from:

* reinterpreting a block that has already passed validation

Nodes ignoring a block that creates >formula() coins is rejection at block *validation*. That's the protocol working as it is supposed to. It's deliberately an all-or-nothing mechanism; you can't pick and choose which blocks you like. If 51% of the network say your block is invalid, they're now on a different fork. The consequences are this drastic on purpose, for stability.

Nodes reinterpreting a block that has already passed validation is almost the polar opposite of this. They're /ignoring the protocol/ and making up their own meaning for stuff. Sidestepping the mechanism in the paragraph above. I would hope it'd be self evident that this is dangerous.

Adam Back is arguing practicality in this thread. I'm arguing fundamental principle. (And, er, someone else is randomly throwing around ad hominems, which we'll politely ignore; Mike could work for Lucifer himself and his good ideas would still be good, and his bad ideas would still be bad, so let's just stick to the ideas eh.)

So, fundamental principle: don't reinterpret history!

We have validation for a very good reason. Undermine it and you might as well have an unvalidated system like Counterparty, which I wouldn't ever trust with more than the value of a small hamburger.

If the economic majority starts reinterpreting history (through whatever voting mechanism / side-channel you like) that completely undermines Bitcoin's validation, and its PoW. It's worse than 51% of miners deciding to rewrite history.

On 30/04/14 23:55, Mike Hearn wrote:

>     If Bitcoin works correctly nobody should have to care if they consider
>     themselves attackers, defenders, or little green men from Mars.
>
>
> One last time, I request that people read the white paper from 2008
> before making statements like this. If the notion of attacker was
> irrelevant to Bitcoin, it would not be mentioned in the abstract, would it?

I've read it :) The notion of an attacker is obviously relevant to someone designing the system. It should not be relevant to someone running a node.

I'll retire from posting on this too, I've posted way too much.

Our fundamental disagreement is simply that you think Bitcoin is, or should be, a /democratic/ system. I think Bitcoin is, and should be, a /trustless/ system. If we're going to resort to appeal to authority, I'll point to the words "Electronic Cash System" in the title of Satoshi's whitepaper :-P He intended to create ecash; that's widely understood to mean trustless.

If there was this magic computer up in the sky somewhere, free from human influence, that would run Satoshi's code for him in perpetuity (let's overlook the initial upload please, bear with me), then I believe Satoshi would've built his perfectly trustless ecash to run on that.

For lack of such a magic masterless computer he had to approximate one, ingeniously using distributed consensus to achieve it. That's his real invention - the "magic masterless computer" simulator, and the incentive scheme to get the world to run it for him. (We'll see more of what it can do if Ethereum ever gets off the ground.)

But for Pete's sake, Bitcoin is trustless. Just because the infrastructure it sits atop is "democratic" (because there was no other way to implement it,) doesn't mean you suddenly have to start voting on everything.

On Wed, Apr 30, 2014 at 11:00:06PM +1000, Gareth Williams wrote:

> On 30/04/14 00:13, Mike Hearn wrote:
> > I do think we need to move beyond this idea of Bitcoin being some kind
> > of elegant embodiment of natural mathematical law. It just ain't so.
>
> I haven't seen anybody arguing that it is.
>
> Bitcoin is the elegant embodiment of /artificially contrived/
> mathematical rules, which just so happen to be very useful in their
> current configuration :-P
>
> Nobody is saying those rules are immutable. Just that it isn't sensible
> to undermine them by introducing imprecise and unpredictable elements
> like human politics.

As an end-user of Bitcoin, the whole possible value of a set of mathematical rules has become completely trashed by the imprecise and unpredictable behavior of buyers and sellers.

If the rules are not responsive to real human needs, bitcoin is worthless as a long-term store of value because **my idea of value** changes over time. This implies, in my mind, an absolutely requirement to attempt to gather some useful signal from the human political noise.

How do you determine what that signal is, so you can **change the rules** and the mathematics so it makes more sense?

You've got to deal with politics, one way or another.

Perhaps I missed it somewhere, but I don't recall it ever being a goal of Bitcoin to act as a stable long-term store of value.

- Jameson

On 04/30/2014 01:06 PM, Troy Benjegerdes wrote:

> On Wed, Apr 30, 2014 at 11:00:06PM +1000, Gareth Williams wrote:
>> On 30/04/14 00:13, Mike Hearn wrote:
>>> I do think we need to move beyond this idea of Bitcoin being some kind
>>> of elegant embodiment of natural mathematical law. It just ain't so.
>>
>> I haven't seen anybody arguing that it is.
>>
>> Bitcoin is the elegant embodiment of /artificially contrived/
>> mathematical rules, which just so happen to be very useful in their
>> current configuration :-P
>>
>> Nobody is saying those rules are immutable. Just that it isn't sensible
>> to undermine them by introducing imprecise and unpredictable elements
>> like human politics.
>
> As an end-user of Bitcoin, the whole possible value of a set of mathematical
> rules has become completely trashed by the imprecise and unpredictable behavior
> of buyers and sellers.
>
> If the rules are not responsive to real human needs, bitcoin is worthless
> as a long-term store of value because **my idea of value** changes over time.
> This implies, in my mind, an absolutely requirement to attempt to gather
> some useful signal from the human political noise.
>
> How do you determine what that signal is, so you can **change the rules**
> and the mathematics so it makes more sense?
>
> You've got to deal with politics, one way or another.
>
>