* Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
2014-04-23 7:55 [Bitcoin-development] Coinbase reallocation to discourage Finney attacks Mike Hearn
@ 2014-04-23 9:57 ` Andy Parkins
2014-04-23 11:07 ` Mike Hearn
2014-04-23 12:43 ` Christophe Biocca
` (4 subsequent siblings)
5 siblings, 1 reply; 90+ messages in thread
From: Andy Parkins @ 2014-04-23 9:57 UTC (permalink / raw)
To: bitcoin-development
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
--
Dr Andy Parkins
andyparkins@gmail•com
^ permalink raw reply [flat|nested] 90+ messages in thread* Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
2014-04-23 9:57 ` Andy Parkins
@ 2014-04-23 11:07 ` Mike Hearn
2014-04-23 11:39 ` Andy Parkins
0 siblings, 1 reply; 90+ messages in thread
From: Mike Hearn @ 2014-04-23 11:07 UTC (permalink / raw)
To: Andy Parkins; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 926 bytes --]
>
> 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.
[-- Attachment #2: Type: text/html, Size: 1364 bytes --]
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
2014-04-23 11:07 ` Mike Hearn
@ 2014-04-23 11:39 ` Andy Parkins
2014-04-23 11:45 ` Mike Hearn
0 siblings, 1 reply; 90+ messages in thread
From: Andy Parkins @ 2014-04-23 11:39 UTC (permalink / raw)
To: Mike Hearn; +Cc: Bitcoin Dev
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
--
Dr Andy Parkins
andyparkins@gmail•com
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
2014-04-23 11:39 ` Andy Parkins
@ 2014-04-23 11:45 ` Mike Hearn
2014-04-23 13:21 ` Andy Parkins
0 siblings, 1 reply; 90+ messages in thread
From: Mike Hearn @ 2014-04-23 11:45 UTC (permalink / raw)
To: Andy Parkins; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 1434 bytes --]
>
> 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.
[-- Attachment #2: Type: text/html, Size: 1808 bytes --]
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
2014-04-23 11:45 ` Mike Hearn
@ 2014-04-23 13:21 ` Andy Parkins
2014-04-23 13:31 ` Mike Hearn
0 siblings, 1 reply; 90+ messages in thread
From: Andy Parkins @ 2014-04-23 13:21 UTC (permalink / raw)
To: Mike Hearn; +Cc: Bitcoin Dev
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
--
Dr Andy Parkins
andyparkins@gmail•com
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
2014-04-23 13:21 ` Andy Parkins
@ 2014-04-23 13:31 ` Mike Hearn
2014-04-24 9:21 ` Andy Parkins
0 siblings, 1 reply; 90+ messages in thread
From: Mike Hearn @ 2014-04-23 13:31 UTC (permalink / raw)
To: Andy Parkins; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 398 bytes --]
>
> 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.
[-- Attachment #2: Type: text/html, Size: 657 bytes --]
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
2014-04-23 13:31 ` Mike Hearn
@ 2014-04-24 9:21 ` Andy Parkins
0 siblings, 0 replies; 90+ messages in thread
From: Andy Parkins @ 2014-04-24 9:21 UTC (permalink / raw)
To: Mike Hearn; +Cc: Bitcoin Dev
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
--
Dr Andy Parkins
andyparkins@gmail•com
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
2014-04-23 7:55 [Bitcoin-development] Coinbase reallocation to discourage Finney attacks Mike Hearn
2014-04-23 9:57 ` Andy Parkins
@ 2014-04-23 12:43 ` Christophe Biocca
2014-04-23 12:51 ` Mike Hearn
2014-04-23 14:52 ` Justus Ranvier
` (3 subsequent siblings)
5 siblings, 1 reply; 90+ messages in thread
From: Christophe Biocca @ 2014-04-23 12:43 UTC (permalink / raw)
To: Bitcoin Dev
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
>
^ permalink raw reply [flat|nested] 90+ messages in thread* Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
2014-04-23 12:43 ` Christophe Biocca
@ 2014-04-23 12:51 ` Mike Hearn
0 siblings, 0 replies; 90+ messages in thread
From: Mike Hearn @ 2014-04-23 12:51 UTC (permalink / raw)
To: Christophe Biocca; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 1221 bytes --]
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.
[-- Attachment #2: Type: text/html, Size: 1897 bytes --]
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
2014-04-23 7:55 [Bitcoin-development] Coinbase reallocation to discourage Finney attacks Mike Hearn
2014-04-23 9:57 ` Andy Parkins
2014-04-23 12:43 ` Christophe Biocca
@ 2014-04-23 14:52 ` Justus Ranvier
2014-04-23 15:07 ` Mike Hearn
2014-04-23 15:04 ` Alex Mizrahi
` (2 subsequent siblings)
5 siblings, 1 reply; 90+ messages in thread
From: Justus Ranvier @ 2014-04-23 14:52 UTC (permalink / raw)
To: bitcoin-development
[-- Attachment #1: Type: text/plain, Size: 1900 bytes --]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBAgAGBQJTV9OUAAoJECoisBQbQ4v0XE8H+QGcOc3JiYsS2/xoR8SqpyEx
gDChDFvhaao9qMPhfxBG0bso+4ITZ5c3mJawkqdBm3ZZPeygt1fLqvxe4c1AWocH
YCf9CyZJlm8KsDJOqorja5o/6oXjH5xiGgVi042Jhb9wj/aGNPFvL9X6DGhEeFKQ
uXFN4wTSPViEOryVqo3vEFh3md9Y1AIqcvc/b5M+EAtvaAD33/ALnzY9CNKymQZE
o0JGLEfwamKkZ+QA0mTfeDheJe9kj0KOQhXqOG/x3NlKCFVpmGz3daWZHJCFMDb4
+RmDwoxOKvXxgveXu9w4d3bc3SQZ75hygmeMvVQwZggia31wqrHtsWLqIiFhVnU=
=hpdg
-----END PGP SIGNATURE-----
[-- Attachment #2: 0x1B438BF4.asc --]
[-- Type: application/pgp-keys, Size: 21521 bytes --]
^ permalink raw reply [flat|nested] 90+ messages in thread* Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
2014-04-23 14:52 ` Justus Ranvier
@ 2014-04-23 15:07 ` Mike Hearn
2014-04-23 17:19 ` Justus Ranvier
0 siblings, 1 reply; 90+ messages in thread
From: Mike Hearn @ 2014-04-23 15:07 UTC (permalink / raw)
To: Justus Ranvier; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 886 bytes --]
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.
[-- Attachment #2: Type: text/html, Size: 1396 bytes --]
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
2014-04-23 15:07 ` Mike Hearn
@ 2014-04-23 17:19 ` Justus Ranvier
2014-04-23 17:47 ` Gavin Andresen
0 siblings, 1 reply; 90+ messages in thread
From: Justus Ranvier @ 2014-04-23 17:19 UTC (permalink / raw)
To: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 1954 bytes --]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBAgAGBQJTV/Y0AAoJECoisBQbQ4v08NcH/RfkaBAcS5eAKmwePqFuqIUN
xJKyIWo+tyY1vPYgArCVNsYr3YM8Wc5fkpqLNxCaM7S0/UmO8YaOdiD7XJyl7bF9
xAveyRt1mfHhx9x6hnPLYbe8WKqtjssSt6MglN8OXtf0EDO+eIxPj6Ya8OZ5YJrL
N8SMHaDs2J+qy3Qfec9keE5dyhYLNRC6PjYPVvrRAyqFSjt/8r4Z2a4r0oqvv3Yt
mYU1Tx+WoXMKXWY/Dwql1NLbuspZsOhPx/ncROZ5KVryCdrcW/GEIEQ6P0AIdHvT
TKYJzh1bdRDYDmVS5z8nUG6waxJwuWPStQo7UYdg26daRUw5qPzjO9SMLLFZPCU=
=OOck
-----END PGP SIGNATURE-----
[-- Attachment #2: 0x1B438BF4.asc --]
[-- Type: application/pgp-keys, Size: 21191 bytes --]
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
2014-04-23 17:19 ` Justus Ranvier
@ 2014-04-23 17:47 ` Gavin Andresen
2014-04-23 17:49 ` Justus Ranvier
0 siblings, 1 reply; 90+ messages in thread
From: Gavin Andresen @ 2014-04-23 17:47 UTC (permalink / raw)
To: Justus Ranvier; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 465 bytes --]
>
>
> 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???
--
--
Gavin Andresen
[-- Attachment #2: Type: text/html, Size: 823 bytes --]
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
2014-04-23 17:47 ` Gavin Andresen
@ 2014-04-23 17:49 ` Justus Ranvier
2014-04-23 17:57 ` Mike Hearn
0 siblings, 1 reply; 90+ messages in thread
From: Justus Ranvier @ 2014-04-23 17:49 UTC (permalink / raw)
To: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 1129 bytes --]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBAgAGBQJTV/0yAAoJECoisBQbQ4v0Fm8H/j0fG7s/iEQUDlV2+5mxeiBO
eoPY2gwuDSTjXc74/3olPHrL/BTGtGg90zwFmlwruUJOaW2m3xvbTD78S8e3HmCC
fqqFKQLg+gOQYud2oiHVNW6H++QqKgSJXu4Lr87ZTkpiRGTgr5PWyhe+4sLeXxam
InqcFmtTHiUMKlmiPj/FUaPHxYT+n+FaPuiZRUYt0Wfxcc9b1n6gEpV7r36Wh8gl
e3rMeDwTfsj/0R4+E+oFEgPl7XBGIJWAf4Nzebuog4ABlqzm4B/RlclZ/5N3W2zZ
6ym6dGpFwN+RuDY2/S2kah6dAeKyk2mAsAChoSOj+vfhCW9wKzclVyM2FNV6lwE=
=djWj
-----END PGP SIGNATURE-----
[-- Attachment #2: 0x1B438BF4.asc --]
[-- Type: application/pgp-keys, Size: 21191 bytes --]
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
2014-04-23 17:49 ` Justus Ranvier
@ 2014-04-23 17:57 ` Mike Hearn
2014-04-23 18:04 ` Justus Ranvier
0 siblings, 1 reply; 90+ messages in thread
From: Mike Hearn @ 2014-04-23 17:57 UTC (permalink / raw)
To: Justus Ranvier; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 908 bytes --]
>
> 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.
[-- Attachment #2: Type: text/html, Size: 1195 bytes --]
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
2014-04-23 17:57 ` Mike Hearn
@ 2014-04-23 18:04 ` Justus Ranvier
2014-04-23 18:15 ` Peter Todd
0 siblings, 1 reply; 90+ messages in thread
From: Justus Ranvier @ 2014-04-23 18:04 UTC (permalink / raw)
To: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 2038 bytes --]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBAgAGBQJTWADBAAoJECoisBQbQ4v0A/0H/25j9bvZaEqfyLJSHNh7PGwC
TpMu0s8D94nX/ipwaOjeY1QMtnWnX9b2H/lDZSnk1rm7IXJTq1c+R/50Uqx5U9QI
oYnsKX1TiB+T5Uv0C5PaIptEMgPkcNyHwsdXyaaUcu2djB0/YhFRlWR7WCH2QyNG
3LR5XWLGJz7v6rDxwvMXEHJWO5950bASP1xCVLc/N0PI7BoEUmeRzAoDa1mGJ9yw
XkVUVDV03B85uTSEriBuQ49ASvv9faAhcehwRwvFFp2krVz6Ov5Jxrv7UN+B61R2
sgZhI3vaTsyRf+8+pkp0dvSpbwwJ7ESBm+BRMPGTnV1AlwJKqjzDYHgowSe01Nw=
=COsH
-----END PGP SIGNATURE-----
[-- Attachment #2: 0x1B438BF4.asc --]
[-- Type: application/pgp-keys, Size: 21521 bytes --]
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
2014-04-23 18:04 ` Justus Ranvier
@ 2014-04-23 18:15 ` Peter Todd
2014-04-23 18:20 ` Justus Ranvier
0 siblings, 1 reply; 90+ messages in thread
From: Peter Todd @ 2014-04-23 18:15 UTC (permalink / raw)
To: Justus Ranvier; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 1515 bytes --]
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.
--
'peter'[:-1]@petertodd.org
000000000000000004af1fb3b77c0f7ffe640982e440ac3eb085fa51d8207838
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 685 bytes --]
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
2014-04-23 18:15 ` Peter Todd
@ 2014-04-23 18:20 ` Justus Ranvier
2014-04-23 18:37 ` Mike Hearn
0 siblings, 1 reply; 90+ messages in thread
From: Justus Ranvier @ 2014-04-23 18:20 UTC (permalink / raw)
To: Peter Todd; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 2179 bytes --]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBAgAGBQJTWARRAAoJECoisBQbQ4v08kkIAKMSSCn9mBCMj6RwWHK6abud
UlaKOAh4LNAaJ+pIQD103EGH3JE9pzeaDouupTbdIHqb8CxVO3dn9UFXdfkDW1cf
YsOOfE0N5crfaODd+NU6jjaf5jXOgmT2ibCU3sSjmphDBMstZfrSaCljtyaj290Y
urnW1pdL5ZA0zLAUjNO2kXSbuHaE3CTz72s4dWsiRBsQLVAD8j5C5o8gxFVeZd7s
Ba4yGtGAsd0HWikUjE2L4G/J8RzbxUrm5w31A4lawkF+SqtJcFiwoxrXX+FVdi/8
rfAY/l0EBoRrkW+cajcj29eq1eOOIER0Zcu2FzpPc45Xywh9RCh8C3zgWitOvcI=
=IR+Y
-----END PGP SIGNATURE-----
[-- Attachment #2: 0x1B438BF4.asc --]
[-- Type: application/pgp-keys, Size: 21191 bytes --]
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
2014-04-23 18:20 ` Justus Ranvier
@ 2014-04-23 18:37 ` Mike Hearn
2014-04-23 18:49 ` Justus Ranvier
2014-04-23 18:58 ` Tier Nolan
0 siblings, 2 replies; 90+ messages in thread
From: Mike Hearn @ 2014-04-23 18:37 UTC (permalink / raw)
To: Justus Ranvier; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 316 bytes --]
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 ;)
[-- Attachment #2: Type: text/html, Size: 342 bytes --]
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
2014-04-23 18:37 ` Mike Hearn
@ 2014-04-23 18:49 ` Justus Ranvier
2014-04-23 19:01 ` Drak
2014-04-23 18:58 ` Tier Nolan
1 sibling, 1 reply; 90+ messages in thread
From: Justus Ranvier @ 2014-04-23 18:49 UTC (permalink / raw)
To: Mike Hearn; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 1758 bytes --]
-----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-----
[-- Attachment #2: 0x1B438BF4.asc --]
[-- Type: application/pgp-keys, Size: 21521 bytes --]
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
2014-04-23 18:49 ` Justus Ranvier
@ 2014-04-23 19:01 ` Drak
0 siblings, 0 replies; 90+ messages in thread
From: Drak @ 2014-04-23 19:01 UTC (permalink / raw)
To: Justus Ranvier; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 3160 bytes --]
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
>
>
[-- Attachment #2: Type: text/html, Size: 4012 bytes --]
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
2014-04-23 18:37 ` Mike Hearn
2014-04-23 18:49 ` Justus Ranvier
@ 2014-04-23 18:58 ` Tier Nolan
1 sibling, 0 replies; 90+ messages in thread
From: Tier Nolan @ 2014-04-23 18:58 UTC (permalink / raw)
To: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 2402 bytes --]
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
>
>
[-- Attachment #2: Type: text/html, Size: 3259 bytes --]
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
2014-04-23 7:55 [Bitcoin-development] Coinbase reallocation to discourage Finney attacks Mike Hearn
` (2 preceding siblings ...)
2014-04-23 14:52 ` Justus Ranvier
@ 2014-04-23 15:04 ` Alex Mizrahi
2014-04-23 15:09 ` Mike Hearn
2014-04-23 15:28 ` Peter Todd
2014-04-23 15:34 ` Kevin
2014-04-23 18:57 ` Gregory Maxwell
5 siblings, 2 replies; 90+ messages in thread
From: Alex Mizrahi @ 2014-04-23 15:04 UTC (permalink / raw)
To: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 933 bytes --]
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
[-- Attachment #2: Type: text/html, Size: 1333 bytes --]
^ permalink raw reply [flat|nested] 90+ messages in thread* Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
2014-04-23 15:04 ` Alex Mizrahi
@ 2014-04-23 15:09 ` Mike Hearn
2014-04-23 15:38 ` Alex Mizrahi
2014-04-24 11:22 ` Jorge Timón
2014-04-23 15:28 ` Peter Todd
1 sibling, 2 replies; 90+ messages in thread
From: Mike Hearn @ 2014-04-23 15:09 UTC (permalink / raw)
To: Alex Mizrahi; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 757 bytes --]
>
> 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.
[-- Attachment #2: Type: text/html, Size: 1406 bytes --]
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
2014-04-23 15:09 ` Mike Hearn
@ 2014-04-23 15:38 ` Alex Mizrahi
2014-04-23 16:04 ` Christophe Biocca
2014-04-24 11:22 ` Jorge Timón
1 sibling, 1 reply; 90+ messages in thread
From: Alex Mizrahi @ 2014-04-23 15:38 UTC (permalink / raw)
To: Mike Hearn; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 841 bytes --]
> 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.
[-- Attachment #2: Type: text/html, Size: 1578 bytes --]
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
2014-04-23 15:38 ` Alex Mizrahi
@ 2014-04-23 16:04 ` Christophe Biocca
2014-04-23 16:19 ` Chris Pacia
` (2 more replies)
0 siblings, 3 replies; 90+ messages in thread
From: Christophe Biocca @ 2014-04-23 16:04 UTC (permalink / raw)
To: Bitcoin Dev
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
>
^ permalink raw reply [flat|nested] 90+ messages in thread* Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
2014-04-23 16:04 ` Christophe Biocca
@ 2014-04-23 16:19 ` Chris Pacia
2014-04-23 16:21 ` Mike Hearn
2014-04-23 16:33 ` Kevin
2 siblings, 0 replies; 90+ messages in thread
From: Chris Pacia @ 2014-04-23 16:19 UTC (permalink / raw)
To: Christophe Biocca; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 4566 bytes --]
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
>
[-- Attachment #2: Type: text/html, Size: 5783 bytes --]
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
2014-04-23 16:04 ` Christophe Biocca
2014-04-23 16:19 ` Chris Pacia
@ 2014-04-23 16:21 ` Mike Hearn
2014-04-23 16:33 ` Kevin
2 siblings, 0 replies; 90+ messages in thread
From: Mike Hearn @ 2014-04-23 16:21 UTC (permalink / raw)
To: Christophe Biocca; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 1406 bytes --]
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.
[-- Attachment #2: Type: text/html, Size: 1665 bytes --]
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
2014-04-23 16:04 ` Christophe Biocca
2014-04-23 16:19 ` Chris Pacia
2014-04-23 16:21 ` Mike Hearn
@ 2014-04-23 16:33 ` Kevin
2 siblings, 0 replies; 90+ messages in thread
From: Kevin @ 2014-04-23 16:33 UTC (permalink / raw)
To: bitcoin-development
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?
--
Kevin
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
2014-04-23 15:09 ` Mike Hearn
2014-04-23 15:38 ` Alex Mizrahi
@ 2014-04-24 11:22 ` Jorge Timón
2014-04-24 11:43 ` Mike Hearn
1 sibling, 1 reply; 90+ messages in thread
From: Jorge Timón @ 2014-04-24 11:22 UTC (permalink / raw)
To: Mike Hearn; +Cc: Bitcoin Dev
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.
--
Jorge Timón
http://freico.in/
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
2014-04-24 11:22 ` Jorge Timón
@ 2014-04-24 11:43 ` Mike Hearn
2014-04-24 13:57 ` Jorge Timón
0 siblings, 1 reply; 90+ messages in thread
From: Mike Hearn @ 2014-04-24 11:43 UTC (permalink / raw)
To: Jorge Timón; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 3848 bytes --]
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?
[-- Attachment #2: Type: text/html, Size: 5148 bytes --]
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
2014-04-24 11:43 ` Mike Hearn
@ 2014-04-24 13:57 ` Jorge Timón
2014-04-24 14:28 ` Mike Hearn
0 siblings, 1 reply; 90+ messages in thread
From: Jorge Timón @ 2014-04-24 13:57 UTC (permalink / raw)
To: Mike Hearn; +Cc: Bitcoin Dev
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.
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
2014-04-24 13:57 ` Jorge Timón
@ 2014-04-24 14:28 ` Mike Hearn
2014-04-24 15:37 ` Jorge Timón
2014-04-25 4:31 ` Gareth Williams
0 siblings, 2 replies; 90+ messages in thread
From: Mike Hearn @ 2014-04-24 14:28 UTC (permalink / raw)
To: Jorge Timón; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 3935 bytes --]
>
> 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.
[-- Attachment #2: Type: text/html, Size: 5711 bytes --]
^ permalink raw reply [flat|nested] 90+ messages in thread* Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
2014-04-24 14:28 ` Mike Hearn
@ 2014-04-24 15:37 ` Jorge Timón
2014-04-24 17:07 ` Justus Ranvier
2014-04-25 4:31 ` Gareth Williams
1 sibling, 1 reply; 90+ messages in thread
From: Jorge Timón @ 2014-04-24 15:37 UTC (permalink / raw)
To: Mike Hearn; +Cc: Bitcoin Dev
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.
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
2014-04-24 15:37 ` Jorge Timón
@ 2014-04-24 17:07 ` Justus Ranvier
0 siblings, 0 replies; 90+ messages in thread
From: Justus Ranvier @ 2014-04-24 17:07 UTC (permalink / raw)
To: bitcoin-development
[-- Attachment #1: Type: text/plain, Size: 1529 bytes --]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBAgAGBQJTWUTWAAoJECoisBQbQ4v0JiwIALQtf4GrNaIdEidJr+f3z8G3
smDgU5xXhN4+1Eo5xU/ZmQy03tU5E00/PRiMTHz1RNXeO+w/iu4PlAJN7pk5oy75
QzDtaCzDjKMCN+1PCQ5VNCL04ws8JifU6QLxSgXgsShBnv19FlxiejgvjNWg+Lzc
uHxyP0PlvfF5BWTiEV68KYcfQPbamOH7Vb8v4tQ4/j/ioA7mYso+Q0jX0Y4ae1FN
XNs4KnTsIFTsXWzBIYFlFPwQ5d+mdG84W7FpmwwcXaRWQxMwdJq8QjlUuFng439B
6OgQqtq4wmvwoPjKS5nOesfdrdH9Scx2zg6uwhaY0zKMtPW/CEzzLFUfq+cZ6q0=
=r+t0
-----END PGP SIGNATURE-----
[-- Attachment #2: 0x1B438BF4.asc --]
[-- Type: application/pgp-keys, Size: 21521 bytes --]
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
2014-04-24 14:28 ` Mike Hearn
2014-04-24 15:37 ` Jorge Timón
@ 2014-04-25 4:31 ` Gareth Williams
2014-04-25 10:17 ` Mike Hearn
1 sibling, 1 reply; 90+ messages in thread
From: Gareth Williams @ 2014-04-25 4:31 UTC (permalink / raw)
To: bitcoin-development
[-- Attachment #1: Type: text/plain, Size: 1275 bytes --]
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
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 555 bytes --]
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
2014-04-25 4:31 ` Gareth Williams
@ 2014-04-25 10:17 ` Mike Hearn
2014-04-25 13:19 ` Gareth Williams
0 siblings, 1 reply; 90+ messages in thread
From: Mike Hearn @ 2014-04-25 10:17 UTC (permalink / raw)
To: Gareth Williams; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 1216 bytes --]
>
> 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.
[-- Attachment #2: Type: text/html, Size: 1615 bytes --]
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
2014-04-25 10:17 ` Mike Hearn
@ 2014-04-25 13:19 ` Gareth Williams
2014-04-25 15:28 ` Mike Hearn
0 siblings, 1 reply; 90+ messages in thread
From: Gareth Williams @ 2014-04-25 13:19 UTC (permalink / raw)
To: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 2621 bytes --]
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.
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 555 bytes --]
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
2014-04-25 13:19 ` Gareth Williams
@ 2014-04-25 15:28 ` Mike Hearn
2014-04-26 12:15 ` Gareth Williams
0 siblings, 1 reply; 90+ messages in thread
From: Mike Hearn @ 2014-04-25 15:28 UTC (permalink / raw)
To: Gareth Williams; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 1836 bytes --]
>
> 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.
[-- Attachment #2: Type: text/html, Size: 2356 bytes --]
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
2014-04-25 15:28 ` Mike Hearn
@ 2014-04-26 12:15 ` Gareth Williams
2014-04-27 1:42 ` Christophe Biocca
0 siblings, 1 reply; 90+ messages in thread
From: Gareth Williams @ 2014-04-26 12:15 UTC (permalink / raw)
To: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 4148 bytes --]
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
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 555 bytes --]
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
2014-04-26 12:15 ` Gareth Williams
@ 2014-04-27 1:42 ` Christophe Biocca
2014-04-27 12:53 ` Gareth Williams
0 siblings, 1 reply; 90+ messages in thread
From: Christophe Biocca @ 2014-04-27 1:42 UTC (permalink / raw)
To: Gareth Williams; +Cc: Bitcoin Dev
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
>
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
2014-04-27 1:42 ` Christophe Biocca
@ 2014-04-27 12:53 ` Gareth Williams
2014-04-27 14:31 ` Mike Hearn
2014-04-28 21:41 ` Adam Back
0 siblings, 2 replies; 90+ messages in thread
From: Gareth Williams @ 2014-04-27 12:53 UTC (permalink / raw)
To: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 2072 bytes --]
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
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 555 bytes --]
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
2014-04-27 12:53 ` Gareth Williams
@ 2014-04-27 14:31 ` Mike Hearn
2014-04-27 23:10 ` Gareth Williams
2014-04-28 21:41 ` Adam Back
1 sibling, 1 reply; 90+ messages in thread
From: Mike Hearn @ 2014-04-27 14:31 UTC (permalink / raw)
To: Gareth Williams; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 993 bytes --]
>
> 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.
[-- Attachment #2: Type: text/html, Size: 1288 bytes --]
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
2014-04-27 14:31 ` Mike Hearn
@ 2014-04-27 23:10 ` Gareth Williams
0 siblings, 0 replies; 90+ messages in thread
From: Gareth Williams @ 2014-04-27 23:10 UTC (permalink / raw)
To: Bitcoin Dev
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.
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
2014-04-27 12:53 ` Gareth Williams
2014-04-27 14:31 ` Mike Hearn
@ 2014-04-28 21:41 ` Adam Back
2014-04-29 14:13 ` Mike Hearn
1 sibling, 1 reply; 90+ messages in thread
From: Adam Back @ 2014-04-28 21:41 UTC (permalink / raw)
To: Gareth Williams; +Cc: Bitcoin Dev
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
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
2014-04-28 21:41 ` Adam Back
@ 2014-04-29 14:13 ` Mike Hearn
2014-04-29 14:21 ` Gregory Maxwell
` (3 more replies)
0 siblings, 4 replies; 90+ messages in thread
From: Mike Hearn @ 2014-04-29 14:13 UTC (permalink / raw)
To: Adam Back; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 1742 bytes --]
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.
[-- Attachment #2: Type: text/html, Size: 2335 bytes --]
^ permalink raw reply [flat|nested] 90+ messages in thread* Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
2014-04-29 14:13 ` Mike Hearn
@ 2014-04-29 14:21 ` Gregory Maxwell
2014-04-29 14:26 ` Mike Hearn
2014-04-29 19:29 ` Justus Ranvier
` (2 subsequent siblings)
3 siblings, 1 reply; 90+ messages in thread
From: Gregory Maxwell @ 2014-04-29 14:21 UTC (permalink / raw)
To: Mike Hearn; +Cc: Bitcoin Dev
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.
^ permalink raw reply [flat|nested] 90+ messages in thread* Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
2014-04-29 14:21 ` Gregory Maxwell
@ 2014-04-29 14:26 ` Mike Hearn
2014-04-30 13:12 ` Gareth Williams
0 siblings, 1 reply; 90+ messages in thread
From: Mike Hearn @ 2014-04-29 14:26 UTC (permalink / raw)
To: Gregory Maxwell; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 343 bytes --]
>
> 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?
[-- Attachment #2: Type: text/html, Size: 640 bytes --]
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
2014-04-29 14:26 ` Mike Hearn
@ 2014-04-30 13:12 ` Gareth Williams
2014-04-30 13:55 ` Mike Hearn
0 siblings, 1 reply; 90+ messages in thread
From: Gareth Williams @ 2014-04-30 13:12 UTC (permalink / raw)
To: bitcoin-development
[-- Attachment #1: Type: text/plain, Size: 618 bytes --]
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.
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 555 bytes --]
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
2014-04-30 13:12 ` Gareth Williams
@ 2014-04-30 13:55 ` Mike Hearn
2014-04-30 14:31 ` Gareth Williams
0 siblings, 1 reply; 90+ messages in thread
From: Mike Hearn @ 2014-04-30 13:55 UTC (permalink / raw)
To: Gareth Williams; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 561 bytes --]
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?
[-- Attachment #2: Type: text/html, Size: 901 bytes --]
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
2014-04-30 13:55 ` Mike Hearn
@ 2014-04-30 14:31 ` Gareth Williams
0 siblings, 0 replies; 90+ messages in thread
From: Gareth Williams @ 2014-04-30 14:31 UTC (permalink / raw)
To: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 1867 bytes --]
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.
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 555 bytes --]
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
2014-04-29 14:13 ` Mike Hearn
2014-04-29 14:21 ` Gregory Maxwell
@ 2014-04-29 19:29 ` Justus Ranvier
2014-04-30 13:00 ` Gareth Williams
2014-04-30 14:08 ` Gareth Williams
3 siblings, 0 replies; 90+ messages in thread
From: Justus Ranvier @ 2014-04-29 19:29 UTC (permalink / raw)
To: bitcoin-development
[-- Attachment #1: Type: text/plain, Size: 2027 bytes --]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBAgAGBQJTX/2dAAoJECoisBQbQ4v0jAoH/R1oNZ1tVp6DJ5BuPg0ZTav0
Dvzq8EfX/uRbRgmxotCHMwY6FJCoXqJTLyOnl2p670t7l5ZXqd91MdKKP2z7jYPY
GsVbqfGreF0dWKCd0mKTG5DM8pxndNWteGIsw9/sYvY/3p2Vopzp6N7fpl8TEf6p
2nyIzEqTD4aK5QkhM+sNnP1Cyh/l5AjJTES23GqSQIMG6vzLgqE8kyze+ANFVg1U
yka6bz4DX7DO7meyJyyOFaMJu6mgY+m6dSVaR7j/QmQMu22SwlSiPgqe6iO//os3
zcmwe/x4+5CmqJOO/PL5Or28iw/Qdf6vNePiaEIFtBzoKnHBhS2nAtL6jnOL928=
=4yIu
-----END PGP SIGNATURE-----
[-- Attachment #2: 0x1B438BF4.asc --]
[-- Type: application/pgp-keys, Size: 22015 bytes --]
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
2014-04-29 14:13 ` Mike Hearn
2014-04-29 14:21 ` Gregory Maxwell
2014-04-29 19:29 ` Justus Ranvier
@ 2014-04-30 13:00 ` Gareth Williams
2014-04-30 17:06 ` Troy Benjegerdes
2014-04-30 14:08 ` Gareth Williams
3 siblings, 1 reply; 90+ messages in thread
From: Gareth Williams @ 2014-04-30 13:00 UTC (permalink / raw)
To: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 1306 bytes --]
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.
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 555 bytes --]
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
2014-04-30 13:00 ` Gareth Williams
@ 2014-04-30 17:06 ` Troy Benjegerdes
2014-04-30 17:13 ` Jameson Lopp
0 siblings, 1 reply; 90+ messages in thread
From: Troy Benjegerdes @ 2014-04-30 17:06 UTC (permalink / raw)
To: Gareth Williams; +Cc: Bitcoin Dev
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.
--
----------------------------------------------------------------------------
Troy Benjegerdes 'da hozer' hozer@hozed•org
7 elements earth::water::air::fire::mind::spirit::soul grid.coop
Never pick a fight with someone who buys ink by the barrel,
nor try buy a hacker who makes money by the megahash
^ permalink raw reply [flat|nested] 90+ messages in thread* Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
2014-04-30 17:06 ` Troy Benjegerdes
@ 2014-04-30 17:13 ` Jameson Lopp
0 siblings, 0 replies; 90+ messages in thread
From: Jameson Lopp @ 2014-04-30 17:13 UTC (permalink / raw)
To: bitcoin-development
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.
>
>
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
2014-04-29 14:13 ` Mike Hearn
` (2 preceding siblings ...)
2014-04-30 13:00 ` Gareth Williams
@ 2014-04-30 14:08 ` Gareth Williams
3 siblings, 0 replies; 90+ messages in thread
From: Gareth Williams @ 2014-04-30 14:08 UTC (permalink / raw)
To: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 1932 bytes --]
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.
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 555 bytes --]
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
2014-04-23 15:04 ` Alex Mizrahi
2014-04-23 15:09 ` Mike Hearn
@ 2014-04-23 15:28 ` Peter Todd
1 sibling, 0 replies; 90+ messages in thread
From: Peter Todd @ 2014-04-23 15:28 UTC (permalink / raw)
To: Alex Mizrahi; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 3435 bytes --]
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?
--
'peter'[:-1]@petertodd.org
0000000000000000278031f86c71265f6eaf1fe9ce6cc831dc4f956676a7a7f7
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 685 bytes --]
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
2014-04-23 7:55 [Bitcoin-development] Coinbase reallocation to discourage Finney attacks Mike Hearn
` (3 preceding siblings ...)
2014-04-23 15:04 ` Alex Mizrahi
@ 2014-04-23 15:34 ` Kevin
2014-04-23 15:41 ` Pieter Wuille
2014-04-23 18:57 ` Gregory Maxwell
5 siblings, 1 reply; 90+ messages in thread
From: Kevin @ 2014-04-23 15:34 UTC (permalink / raw)
To: bitcoin-development
[-- Attachment #1: Type: text/plain, Size: 5936 bytes --]
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?
--
Kevin
[-- Attachment #2: Type: text/html, Size: 8155 bytes --]
^ permalink raw reply [flat|nested] 90+ messages in thread* Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
2014-04-23 15:34 ` Kevin
@ 2014-04-23 15:41 ` Pieter Wuille
2014-04-23 15:55 ` Peter Todd
0 siblings, 1 reply; 90+ messages in thread
From: Pieter Wuille @ 2014-04-23 15:41 UTC (permalink / raw)
To: Kevin; +Cc: Bitcoin Dev
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.
--
Pieter
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
2014-04-23 15:41 ` Pieter Wuille
@ 2014-04-23 15:55 ` Peter Todd
0 siblings, 0 replies; 90+ messages in thread
From: Peter Todd @ 2014-04-23 15:55 UTC (permalink / raw)
To: Pieter Wuille; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 1341 bytes --]
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.
--
'peter'[:-1]@petertodd.org
0000000000000000278031f86c71265f6eaf1fe9ce6cc831dc4f956676a7a7f7
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 685 bytes --]
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
2014-04-23 7:55 [Bitcoin-development] Coinbase reallocation to discourage Finney attacks Mike Hearn
` (4 preceding siblings ...)
2014-04-23 15:34 ` Kevin
@ 2014-04-23 18:57 ` Gregory Maxwell
2014-04-23 19:19 ` Mike Hearn
5 siblings, 1 reply; 90+ messages in thread
From: Gregory Maxwell @ 2014-04-23 18:57 UTC (permalink / raw)
To: Mike Hearn; +Cc: Bitcoin Dev
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.
^ permalink raw reply [flat|nested] 90+ messages in thread* Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
2014-04-23 18:57 ` Gregory Maxwell
@ 2014-04-23 19:19 ` Mike Hearn
2014-04-23 19:47 ` Gregory Maxwell
2014-04-23 22:06 ` Alex Mizrahi
0 siblings, 2 replies; 90+ messages in thread
From: Mike Hearn @ 2014-04-23 19:19 UTC (permalink / raw)
To: Gregory Maxwell; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 3380 bytes --]
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.
[-- Attachment #2: Type: text/html, Size: 4523 bytes --]
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
2014-04-23 19:19 ` Mike Hearn
@ 2014-04-23 19:47 ` Gregory Maxwell
2014-04-23 19:59 ` Mike Hearn
2014-04-23 22:06 ` Alex Mizrahi
1 sibling, 1 reply; 90+ messages in thread
From: Gregory Maxwell @ 2014-04-23 19:47 UTC (permalink / raw)
To: Mike Hearn; +Cc: Bitcoin Dev
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.
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
2014-04-23 19:47 ` Gregory Maxwell
@ 2014-04-23 19:59 ` Mike Hearn
2014-04-23 20:24 ` Gregory Maxwell
2014-04-23 20:41 ` [Bitcoin-development] " Daniel Krawisz
0 siblings, 2 replies; 90+ messages in thread
From: Mike Hearn @ 2014-04-23 19:59 UTC (permalink / raw)
To: Gregory Maxwell; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 2059 bytes --]
>
> 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.
[-- Attachment #2: Type: text/html, Size: 2743 bytes --]
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
2014-04-23 19:59 ` Mike Hearn
@ 2014-04-23 20:24 ` Gregory Maxwell
2014-04-23 20:37 ` Mike Hearn
2014-04-23 20:41 ` [Bitcoin-development] " Daniel Krawisz
1 sibling, 1 reply; 90+ messages in thread
From: Gregory Maxwell @ 2014-04-23 20:24 UTC (permalink / raw)
To: Mike Hearn; +Cc: Bitcoin Dev
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.
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
2014-04-23 20:24 ` Gregory Maxwell
@ 2014-04-23 20:37 ` Mike Hearn
2014-04-23 20:44 ` Adam Ritter
0 siblings, 1 reply; 90+ messages in thread
From: Mike Hearn @ 2014-04-23 20:37 UTC (permalink / raw)
To: Gregory Maxwell; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 1772 bytes --]
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.
[-- Attachment #2: Type: text/html, Size: 2563 bytes --]
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
2014-04-23 20:37 ` Mike Hearn
@ 2014-04-23 20:44 ` Adam Ritter
2014-04-23 20:51 ` Mike Hearn
2014-04-23 20:53 ` Gregory Maxwell
0 siblings, 2 replies; 90+ messages in thread
From: Adam Ritter @ 2014-04-23 20:44 UTC (permalink / raw)
To: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 2679 bytes --]
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
>
>
[-- Attachment #2: Type: text/html, Size: 4016 bytes --]
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
2014-04-23 20:44 ` Adam Ritter
@ 2014-04-23 20:51 ` Mike Hearn
2014-04-24 15:13 ` Sergio Lerner
2014-04-23 20:53 ` Gregory Maxwell
1 sibling, 1 reply; 90+ messages in thread
From: Mike Hearn @ 2014-04-23 20:51 UTC (permalink / raw)
To: Adam Ritter; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 1341 bytes --]
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.
[-- Attachment #2: Type: text/html, Size: 1750 bytes --]
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
2014-04-23 20:51 ` Mike Hearn
@ 2014-04-24 15:13 ` Sergio Lerner
2014-04-24 15:34 ` Mike Hearn
0 siblings, 1 reply; 90+ messages in thread
From: Sergio Lerner @ 2014-04-24 15:13 UTC (permalink / raw)
To: Mike Hearn, bitcoin-development
[-- Attachment #1: Type: text/plain, Size: 2151 bytes --]
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.
[-- Attachment #2: Type: text/html, Size: 4001 bytes --]
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
2014-04-24 15:13 ` Sergio Lerner
@ 2014-04-24 15:34 ` Mike Hearn
0 siblings, 0 replies; 90+ messages in thread
From: Mike Hearn @ 2014-04-24 15:34 UTC (permalink / raw)
To: Sergio Lerner; +Cc: bitcoin-development
[-- Attachment #1: Type: text/plain, Size: 1587 bytes --]
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.
[-- Attachment #2: Type: text/html, Size: 2553 bytes --]
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
2014-04-23 20:44 ` Adam Ritter
2014-04-23 20:51 ` Mike Hearn
@ 2014-04-23 20:53 ` Gregory Maxwell
2014-04-23 21:23 ` Tier Nolan
[not found] ` <CAKuKjyWDniyP503XSw8=tK9XQW-T58j+VD6ajXCxz=HihN93mQ@mail.gmail.com>
1 sibling, 2 replies; 90+ messages in thread
From: Gregory Maxwell @ 2014-04-23 20:53 UTC (permalink / raw)
To: Adam Ritter; +Cc: Bitcoin Dev
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.
^ permalink raw reply [flat|nested] 90+ messages in thread* Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
2014-04-23 20:53 ` Gregory Maxwell
@ 2014-04-23 21:23 ` Tier Nolan
2014-04-23 21:39 ` Gregory Maxwell
2014-04-24 0:55 ` Tom Harding
[not found] ` <CAKuKjyWDniyP503XSw8=tK9XQW-T58j+VD6ajXCxz=HihN93mQ@mail.gmail.com>
1 sibling, 2 replies; 90+ messages in thread
From: Tier Nolan @ 2014-04-23 21:23 UTC (permalink / raw)
To: Gregory Maxwell; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 2727 bytes --]
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
>
[-- Attachment #2: Type: text/html, Size: 3667 bytes --]
^ permalink raw reply [flat|nested] 90+ messages in thread* Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
2014-04-23 21:23 ` Tier Nolan
@ 2014-04-23 21:39 ` Gregory Maxwell
2014-04-23 22:26 ` Tier Nolan
2014-04-24 0:55 ` Tom Harding
1 sibling, 1 reply; 90+ messages in thread
From: Gregory Maxwell @ 2014-04-23 21:39 UTC (permalink / raw)
To: Tier Nolan; +Cc: Bitcoin Dev
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.
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
2014-04-23 21:39 ` Gregory Maxwell
@ 2014-04-23 22:26 ` Tier Nolan
0 siblings, 0 replies; 90+ messages in thread
From: Tier Nolan @ 2014-04-23 22:26 UTC (permalink / raw)
To: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 2652 bytes --]
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.
[-- Attachment #2: Type: text/html, Size: 3878 bytes --]
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
2014-04-23 21:23 ` Tier Nolan
2014-04-23 21:39 ` Gregory Maxwell
@ 2014-04-24 0:55 ` Tom Harding
1 sibling, 0 replies; 90+ messages in thread
From: Tom Harding @ 2014-04-24 0:55 UTC (permalink / raw)
To: bitcoin-development
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
^ permalink raw reply [flat|nested] 90+ messages in thread
[parent not found: <CAKuKjyWDniyP503XSw8=tK9XQW-T58j+VD6ajXCxz=HihN93mQ@mail.gmail.com>]
* [Bitcoin-development] Fwd: Coinbase reallocation to discourage Finney attacks
[not found] ` <CAKuKjyWDniyP503XSw8=tK9XQW-T58j+VD6ajXCxz=HihN93mQ@mail.gmail.com>
@ 2014-04-24 14:52 ` Adam Ritter
0 siblings, 0 replies; 90+ messages in thread
From: Adam Ritter @ 2014-04-24 14:52 UTC (permalink / raw)
To: Bitcoin Development, Gregory Maxwell, Mike Hearn
[-- Attachment #1: Type: text/plain, Size: 1953 bytes --]
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.
>
[-- Attachment #2: Type: text/html, Size: 2562 bytes --]
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
2014-04-23 19:59 ` Mike Hearn
2014-04-23 20:24 ` Gregory Maxwell
@ 2014-04-23 20:41 ` Daniel Krawisz
1 sibling, 0 replies; 90+ messages in thread
From: Daniel Krawisz @ 2014-04-23 20:41 UTC (permalink / raw)
To: bitcoin-development
[-- Attachment #1: Type: text/plain, Size: 4128 bytes --]
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
>
>
[-- Attachment #2: Type: text/html, Size: 5458 bytes --]
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
2014-04-23 19:19 ` Mike Hearn
2014-04-23 19:47 ` Gregory Maxwell
@ 2014-04-23 22:06 ` Alex Mizrahi
2014-04-24 7:58 ` Mike Hearn
1 sibling, 1 reply; 90+ messages in thread
From: Alex Mizrahi @ 2014-04-23 22:06 UTC (permalink / raw)
To: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 1352 bytes --]
>
> 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.
[-- Attachment #2: Type: text/html, Size: 1864 bytes --]
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
2014-04-23 22:06 ` Alex Mizrahi
@ 2014-04-24 7:58 ` Mike Hearn
2014-04-24 8:19 ` Gregory Maxwell
0 siblings, 1 reply; 90+ messages in thread
From: Mike Hearn @ 2014-04-24 7:58 UTC (permalink / raw)
To: Alex Mizrahi; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 3330 bytes --]
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.
[-- Attachment #2: Type: text/html, Size: 5163 bytes --]
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
2014-04-24 7:58 ` Mike Hearn
@ 2014-04-24 8:19 ` Gregory Maxwell
2014-04-24 8:39 ` Mike Hearn
0 siblings, 1 reply; 90+ messages in thread
From: Gregory Maxwell @ 2014-04-24 8:19 UTC (permalink / raw)
To: Mike Hearn; +Cc: Bitcoin Dev
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.
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
2014-04-24 8:19 ` Gregory Maxwell
@ 2014-04-24 8:39 ` Mike Hearn
2014-04-24 9:25 ` Gregory Maxwell
0 siblings, 1 reply; 90+ messages in thread
From: Mike Hearn @ 2014-04-24 8:39 UTC (permalink / raw)
To: Gregory Maxwell; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 2919 bytes --]
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.
[-- Attachment #2: Type: text/html, Size: 4092 bytes --]
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
2014-04-24 8:39 ` Mike Hearn
@ 2014-04-24 9:25 ` Gregory Maxwell
2014-04-24 9:56 ` Mike Hearn
0 siblings, 1 reply; 90+ messages in thread
From: Gregory Maxwell @ 2014-04-24 9:25 UTC (permalink / raw)
To: Mike Hearn; +Cc: Bitcoin Dev
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.
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
2014-04-24 9:25 ` Gregory Maxwell
@ 2014-04-24 9:56 ` Mike Hearn
2014-04-24 13:44 ` Peter Todd
0 siblings, 1 reply; 90+ messages in thread
From: Mike Hearn @ 2014-04-24 9:56 UTC (permalink / raw)
To: Gregory Maxwell; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 1813 bytes --]
>
> 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.
[-- Attachment #2: Type: text/html, Size: 2447 bytes --]
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
2014-04-24 9:56 ` Mike Hearn
@ 2014-04-24 13:44 ` Peter Todd
2014-04-24 14:09 ` Mike Hearn
0 siblings, 1 reply; 90+ messages in thread
From: Peter Todd @ 2014-04-24 13:44 UTC (permalink / raw)
To: Mike Hearn; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 1793 bytes --]
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.
--
'peter'[:-1]@petertodd.org
00000000000000003d5f2a2a68690093cd99f8af1bc8395061251017019cc30a
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 685 bytes --]
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
2014-04-24 13:44 ` Peter Todd
@ 2014-04-24 14:09 ` Mike Hearn
2014-04-24 14:47 ` Christophe Biocca
0 siblings, 1 reply; 90+ messages in thread
From: Mike Hearn @ 2014-04-24 14:09 UTC (permalink / raw)
To: Peter Todd; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 752 bytes --]
>
> 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.
[-- Attachment #2: Type: text/html, Size: 1082 bytes --]
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
2014-04-24 14:09 ` Mike Hearn
@ 2014-04-24 14:47 ` Christophe Biocca
2014-04-24 15:03 ` Peter Todd
0 siblings, 1 reply; 90+ messages in thread
From: Christophe Biocca @ 2014-04-24 14:47 UTC (permalink / raw)
To: Peter Todd; +Cc: Bitcoin Dev
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
>
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
2014-04-24 14:47 ` Christophe Biocca
@ 2014-04-24 15:03 ` Peter Todd
2014-04-24 16:05 ` Christophe Biocca
2014-04-24 16:14 ` Mike Hearn
0 siblings, 2 replies; 90+ messages in thread
From: Peter Todd @ 2014-04-24 15:03 UTC (permalink / raw)
To: Christophe Biocca; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 2296 bytes --]
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
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 685 bytes --]
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
2014-04-24 15:03 ` Peter Todd
@ 2014-04-24 16:05 ` Christophe Biocca
2014-04-24 16:14 ` Mike Hearn
1 sibling, 0 replies; 90+ messages in thread
From: Christophe Biocca @ 2014-04-24 16:05 UTC (permalink / raw)
Cc: Bitcoin Dev
> 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
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
2014-04-24 15:03 ` Peter Todd
2014-04-24 16:05 ` Christophe Biocca
@ 2014-04-24 16:14 ` Mike Hearn
1 sibling, 0 replies; 90+ messages in thread
From: Mike Hearn @ 2014-04-24 16:14 UTC (permalink / raw)
To: Peter Todd; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 219 bytes --]
>
> 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.
[-- Attachment #2: Type: text/html, Size: 450 bytes --]
^ permalink raw reply [flat|nested] 90+ messages in thread