[Bitcoin-development] UUID to identify chains (payment protocol and elsewhere)

2013-05-20 Thread Mark Friedenbach
At the developer round-table it was asked if the payment protocol would 
alt-chains, and Gavin noted that it has a UTF-8 encoded string 
identifying the network (main or test). As someone with two 
proposals in the works which also require chain/coin identification (one 
for merged mining, one for colored coins), I am opinionated on this. I 
believe that we need a standard mechanism for identifying chains, and 
one which avoids the trap of maintaining a standard registry of 
string-to-chain mappings.

Any chain can be uniquely identified by its genesis block, 122 random 
bits is more than sufficient for uniquely tagging chains/colored assets, 
and the low-order 16-bytes of the block's hash are effectively random. 
With these facts in mind, I propose that we identify chains by UUID.

So as to remain reasonably compliant with RFC 4122, I recommend that we 
use Version 4 (random) UUIDs, with the random bits extracted from the 
double-SHA256 hash of the genesis block of the chain. (For colored 
coins, the colored coin definition transaction would be used instead, 
but I will address that in a separate proposal and will say just one 
thing about it: adopting this method for identifying chains/coins will 
greatly assist in adopting the payment protocol to colored coins.)

The following Python code illustrates how to construct the chain 
identifier from the serialized genesis block:

 from hashlib import sha256
 from uuid import UUID
 def chain_uuid(serialized_genesis_block):
 h = sha256(serialized_genesis_block).digest()
 h = sha256(h).digest()
 h = h[:16]
 h = ''.join([
 h[:6],
 chr(0x40 | ord(h[6])  0x0f),
 h[7],
 chr(0x80 | ord(h[8])  0x3f),
 h[9:]
 ])
 return UUID(bytes=h)

And some example chain identifiers:

 mainnet:  UUID('6fe28c0a-b6f1-4372-81a6-a246ae63f74f')
 testnet3: UUID('43497fd7-f826-4571-88f4-a30fd9cec3ae')
 namecoin: UUID('70c7a9f0-a2fb-4d48-a635-a70d5b157c80')

As for encoding the chain identifier, the simplest method is to give 
network the bytes type, but defining a UUID message type is also 
possible. In either case bitcoin mainnet would be the default, so the 
extra 12 bytes (vs: main or test) would only be an issue for 
alt-chains or colored coins.

Kind regards,
Mark Friedenbach

--
Try New Relic Now  We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app,  servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Double Spend Notification

2013-05-20 Thread Robert Backhaus
Personally, I agree, but a different decision has been made by the main
devs.

The issue is this: consider two transactions in the unconfirmed pool. One
transaction has 2BTC input, 1.5BTC to one address (the payment), .4995 to
another address (change) and .0005 standard fee. Another transaction
appears - Same input, 1BTC to one address, .999 to another, and .001 fee.
Which one would a miner include? On pure self interest, the second one,
because it has twice the fee. Anyway, the miner has no real way of knowing
which transaction was real, and which the fraudulent double-spend. The
network does not keep accurate timestamps, so it has no way of really
knowing which is first. A bit of artificial DDOS-type overload on the
recipient's system, and the real transaction could easily appear last.

So the decision has been made to make 0-conf double spends trivial, so no
one will ever trust 0-confs. If a later transaction appears with a larger
fee, it will be considered to be the valid one, and the first one dropped,
as long as the first one has not been confirmed. This makes undoing a
mistaken transaction possible.

So anyone needing 0-conf-like speed will have to make other arangements,
such as contracting with enough mining pool power to never drop their
transactions unless confirmed multiple times. Secure 0-confs is an
impossible target with blockchain cyrpto-currencies as the stand. Any ideas
on how to make them work are welcome, of course - as long as we haven't
heard them too many times before.


On 21 May 2013 10:45, Quinn Harris btc...@quinnharris.me wrote:

 The current BitCoin implementation is subject to relatively easy double
 spend attack for 0 confirmation payments.  Yet 0 confirmation payments
 are needed for typical in person transactions like most purchases at a
 local business.

 Notably, it is easy to transmit two transactions from the same output at
 the same time to different sets of nodes on the network by using two
 instances of bitcoind with same wallet file and a spend on each daemon
 initiated by RPC by some easy to implement code.  If the first attempt
 to pay the merchant doesn't go through because they received the wrong
 transaction it could be quickly followed up with another initiated spend
 from a different output switching which daemon sends the transaction the
 merchant is expecting.  This means an unsophisticated attacker can
 reliably get away with this attack and it would be worth while for small
 transactions.  Given this, I would be reluctant to trust 0 confirmation
 transactions at all though I think many do in practice.  Someone could
 write and publish a special daemon to execute this attack further
 reducing the cost.

 Right now a node will drop any second spend of the same output in the
 memory pool.  After the first transaction has propagated through the
 network issuing a second double spend transaction isn't likely to be
 seen by a significant number of miners as most nodes especially non
 miner nodes will drop this transaction.  Today, it is necessary to
 transmit both transactions on the network nearly simultaneously to
 reliably get away with this simple attack.  If in this case, the
 receiving end is quickly notified of the double spend this attack
 becomes more more difficult to get away with.

 If the second transaction is relayed instead of being dropped to notify
 the receiving party of the double spend, most miners will receive both
 transactions and it is possible that some or even many of the miners
 would replace the first transaction with the second if it has a higher
 fee as it would be in their short term interest. This can happen some
 time after the first transaction has propagated through the network so
 the receiving end wouldn't get a timely notification of the double
 spend.  Depending on the choices of the miners, this approach to double
 spend notification could exacerbate the very problem it was attempting
 to fix compared to the current implementation.  While miners might
 continue to drop the second spends, the easy availability of the second
 spends would increase the short term reward for changing this policy.

 This problem can be fixed if instead of sending the second transaction a
 new double spend message is sent with proof of the double spend but not
 the complete transactions.  This would allow the receiving end to be
 quickly notified of a double spend while in no way increase the chance
 over the current implementation that a double spend would be successful.

 The proof of the double spend would include the scriptSig (input) from
 the original transactions and the hashes from the simplified
 transaction used by OP_CHECKSIG of the scriptPubKey (output) but not the
 entire transaction.  This is the hash computed by the SignatureHash
 function in script.cpp.   The double spend notification message should
 contain proofs of both signed transaction spending the same output
 ordered by hash to produce a canonical proof for a specific 

Re: [Bitcoin-development] Double Spend Notification

2013-05-20 Thread Pieter Wuille
On Tue, May 21, 2013 at 3:24 AM, Robert Backhaus rob...@robbak.com wrote:
 So the decision has been made to make 0-conf double spends trivial, so no
 one will ever trust 0-confs. If a later transaction appears with a larger
 fee, it will be considered to be the valid one, and the first one dropped,
 as long as the first one has not been confirmed. This makes undoing a
 mistaken transaction possible.

This has been suggested, but I know of no such decision having been made.

-- 
Pieter

--
Try New Relic Now  We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app,  servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] UUID to identify chains (payment protocol and elsewhere)

2013-05-20 Thread Jeff Garzik
On Mon, May 20, 2013 at 7:59 PM, Mark Friedenbach m...@monetize.io wrote:
 So as to remain reasonably compliant with RFC 4122, I recommend that we
 use Version 4 (random) UUIDs, with the random bits extracted from the
 double-SHA256 hash of the genesis block of the chain. (For colored
 coins, the colored coin definition transaction would be used instead,
 but I will address that in a separate proposal and will say just one
 thing about it: adopting this method for identifying chains/coins will
 greatly assist in adopting the payment protocol to colored coins.)

This proposal seems closer to Version 5 than Version 4, in spirit.
But given that useful content may be deduced from UUID, it is not
truly applicable to either.  A bitcoin-specific version 6, if you
will.


 And some example chain identifiers:

  mainnet:  UUID('6fe28c0a-b6f1-4372-81a6-a246ae63f74f')
  testnet3: UUID('43497fd7-f826-4571-88f4-a30fd9cec3ae')
  namecoin: UUID('70c7a9f0-a2fb-4d48-a635-a70d5b157c80')

Note that, as this example unintentionally implies, humans are going
to want a side-by-side mapping /anyway/, just to make it readable and
usable to humans.

Almost all useful multi-chain software will require a readable
shortname string anyway, the thing this proposal wishes to avoid.

-- 
Jeff Garzik
exMULTI, Inc.
jgar...@exmulti.com

--
Try New Relic Now  We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app,  servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] UUID to identify chains (payment protocol and elsewhere)

2013-05-20 Thread Mike Hearn
Bitcoinj already has such chain id's and we use standard Java style reverse
DNS names: org.bitcoin.main, etc. If we want a more global naming system
that seems like a good compromise between uniqueness and readability.
On 20 May 2013 19:45, Jeff Garzik jgar...@exmulti.com wrote:

 On Mon, May 20, 2013 at 7:59 PM, Mark Friedenbach m...@monetize.io
 wrote:
  So as to remain reasonably compliant with RFC 4122, I recommend that we
  use Version 4 (random) UUIDs, with the random bits extracted from the
  double-SHA256 hash of the genesis block of the chain. (For colored
  coins, the colored coin definition transaction would be used instead,
  but I will address that in a separate proposal and will say just one
  thing about it: adopting this method for identifying chains/coins will
  greatly assist in adopting the payment protocol to colored coins.)

 This proposal seems closer to Version 5 than Version 4, in spirit.
 But given that useful content may be deduced from UUID, it is not
 truly applicable to either.  A bitcoin-specific version 6, if you
 will.


  And some example chain identifiers:
 
   mainnet:  UUID('6fe28c0a-b6f1-4372-81a6-a246ae63f74f')
   testnet3: UUID('43497fd7-f826-4571-88f4-a30fd9cec3ae')
   namecoin: UUID('70c7a9f0-a2fb-4d48-a635-a70d5b157c80')

 Note that, as this example unintentionally implies, humans are going
 to want a side-by-side mapping /anyway/, just to make it readable and
 usable to humans.

 Almost all useful multi-chain software will require a readable
 shortname string anyway, the thing this proposal wishes to avoid.

 --
 Jeff Garzik
 exMULTI, Inc.
 jgar...@exmulti.com


 --
 Try New Relic Now  We'll Send You this Cool Shirt
 New Relic is the only SaaS-based application performance monitoring service
 that delivers powerful full stack analytics. Optimize and monitor your
 browser, app,  servers with just a few lines of code. Try New Relic
 and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development

--
Try New Relic Now  We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app,  servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Double Spend Notification

2013-05-20 Thread Robert Backhaus
That's good - what I had taken away from the replace-by-fee discussions was
that it was finally decided.

My opinion is that we should be doing what we can to make 0-confs as
reliable as possible - which will always be 'not very', but a solid system
to notify on attempted double-spends is a good start.

I'd like to know how Peter Todd's experiment with the 2BTC reward has gone.


On 21 May 2013 13:27, Mike Hearn m...@plan99.net wrote:

 Indeed, that has been proposed but it's a dumb idea and I'm very sceptical
 it will go anywhere.  Certainly no decision was made. The arguments for it
 are based on some quite faulty thinking about economics. Double spend
 notifications have been proposed a long time ago, I believe Matt has
 indicated some interest in implementing them and that is the right way to
 go.
 On 20 May 2013 18:57, Pieter Wuille pieter.wui...@gmail.com wrote:

 On Tue, May 21, 2013 at 3:24 AM, Robert Backhaus rob...@robbak.com
 wrote:
  So the decision has been made to make 0-conf double spends trivial, so
 no
  one will ever trust 0-confs. If a later transaction appears with a
 larger
  fee, it will be considered to be the valid one, and the first one
 dropped,
  as long as the first one has not been confirmed. This makes undoing a
  mistaken transaction possible.

 This has been suggested, but I know of no such decision having been made.

 --
 Pieter


 --
 Try New Relic Now  We'll Send You this Cool Shirt
 New Relic is the only SaaS-based application performance monitoring
 service
 that delivers powerful full stack analytics. Optimize and monitor your
 browser, app,  servers with just a few lines of code. Try New Relic
 and get this awesome Nerd Life shirt!
 http://p.sf.net/sfu/newrelic_d2d_may
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development


--
Try New Relic Now  We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app,  servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Double Spend Notification

2013-05-20 Thread Quinn Harris
A part of my reason for sending this email was a quick discussion I had 
with Gavin at the BitCoin conference.  I was under the strong impression 
that double spend notification was something he approved of and was 
considering implementing himself.


In the case of a double spend, If the receiving end gets a timely 
notification (few seconds) it isn't that important that any one of the 
two (or more) transactions is chosen over another.  The receiving side 
can treat a double spend as a failed transaction as it should be proof 
that the buyer is acting maliciously or has had their private keys 
compromised.


I am aware Peter Todd has implemented replace by fee and is operating a 
node on testnet doing this.  I think he is rightly pointing out that the 
current behaviour of dropping all second spends is based largely on the 
good will of nodes and can absolutly contradict the perceived self 
interest of those running miners.  Accordingly relying on this behaviour 
can be precarious. It was from reading his emails to this list or 
bitcointalk that I recognized how essential it was to not transmit the 
second transaction if double spend notification had any hope of being 
worth much.


This is controversial because reliable 0-conf transactions are desirable 
but as you said there really is no way to ensure significant integrity 
in a decentralized way.  Replace by fee would make what transactions get 
into blocks more predictable and eliminate any expectation of reliable 0 
conf transactions.  The question is if this consistency is a better 
choice than a double spend notification that is far from perfect but 
today its still useful and in practice can probably be trusted as much 
as credit cards.


A more strict version of replace by fee could be implemented that only 
replaces transactions with ones that don't reduce any output quantity 
and accordingly require introducing a new input.  This would allow 
increasing transaction fees on a transaction without hurting someone who 
trusted a 0 conf transaction.  This seems like feature bloat to me but 
it wouldn't reduce 0 conf integrity.


Unfortunately, I don't see a way to make everyone happy on this issue.  
Though, I expect everyone would either prefer double spend notification 
or always replace by higher fee over what we have now.


- Quinn



On 05/20/2013 07:24 PM, Robert Backhaus wrote:
Personally, I agree, but a different decision has been made by the 
main devs.


The issue is this: consider two transactions in the unconfirmed pool. 
One transaction has 2BTC input, 1.5BTC to one address (the payment), 
.4995 to another address (change) and .0005 standard fee. Another 
transaction appears - Same input, 1BTC to one address, .999 to 
another, and .001 fee. Which one would a miner include? On pure self 
interest, the second one, because it has twice the fee. Anyway, the 
miner has no real way of knowing which transaction was real, and which 
the fraudulent double-spend. The network does not keep accurate 
timestamps, so it has no way of really knowing which is first. A bit 
of artificial DDOS-type overload on the recipient's system, and the 
real transaction could easily appear last.


So the decision has been made to make 0-conf double spends trivial, so 
no one will ever trust 0-confs. If a later transaction appears with a 
larger fee, it will be considered to be the valid one, and the first 
one dropped, as long as the first one has not been confirmed. This 
makes undoing a mistaken transaction possible.


So anyone needing 0-conf-like speed will have to make other 
arangements, such as contracting with enough mining pool power to 
never drop their transactions unless confirmed multiple times. Secure 
0-confs is an impossible target with blockchain cyrpto-currencies as 
the stand. Any ideas on how to make them work are welcome, of course - 
as long as we haven't heard them too many times before.



On 21 May 2013 10:45, Quinn Harris btc...@quinnharris.me 
mailto:btc...@quinnharris.me wrote:


The current BitCoin implementation is subject to relatively easy
double
spend attack for 0 confirmation payments.  Yet 0 confirmation payments
are needed for typical in person transactions like most purchases at a
local business.

Notably, it is easy to transmit two transactions from the same
output at
the same time to different sets of nodes on the network by using two
instances of bitcoind with same wallet file and a spend on each daemon
initiated by RPC by some easy to implement code.  If the first attempt
to pay the merchant doesn't go through because they received the
wrong
transaction it could be quickly followed up with another initiated
spend
from a different output switching which daemon sends the
transaction the
merchant is expecting.  This means an unsophisticated attacker can
reliably get away with this attack and it would be worth while for
small
transactions.  Given 

Re: [Bitcoin-development] Double Spend Notification

2013-05-20 Thread Gregory Maxwell
On Mon, May 20, 2013 at 6:56 PM, Pieter Wuille pieter.wui...@gmail.com wrote:
 On Tue, May 21, 2013 at 3:24 AM, Robert Backhaus rob...@robbak.com wrote:
 So the decision has been made to make 0-conf double spends trivial, so no
 one will ever trust 0-confs. If a later transaction appears with a larger
 fee, it will be considered to be the valid one, and the first one dropped,
 as long as the first one has not been confirmed. This makes undoing a
 mistaken transaction possible.
 This has been suggested, but I know of no such decision having been made.

Indeed. I've argued against it pretty aggressively, but I am starting
to find arguments for and against pure fee-based replacement more
equally persuasive.

Regardless of the eventual outcome, fees today aren't a major
motivator vs subsidy and overall network health— and even if some
protection isn't 100% there are plenty of cases where the risk is
averaged across many small transactions and any reduction of risk is a
reduction in operating cost.   (No one is going to double spend your
soda machine at high speed— so you can like increase your prices by
the amount of successful double spends you experience and call it
done)

On the other hand, it's well established that people underestimate the
costs of unlikely risks. More deterministic behavior can result in
safer interactions more than _better_ behavior. If we believe that in
the long term self-interest will result in pure-fee based replacement
being wide spread then it is also good to not build a dependency on
behavior that will not last.

One point that was only recently exposed to me is that replacement
combined with child-pays-for-parent creates a new kind of double spend
_defense_: If someone double spends a payment to an online key of
yours, you can instantly produce a child transaction that pays 100% of
the double spend to fees... so a double spender can hurt you but not
profit from it.  (and if your side of the transaction is
potentially/partially reversible he will lose)...

But then again, a race to burn more money is kinda ... odd and even if
the benefit of resisting the double spends is only a short term
benefit, a short term benefit can be greatly important in encouraging
Bitcoin adoption. ... and the long term behavior is far from certain.

So at least from my position it's far from clear what should be done here.

I've noticed a number of people who seem to be swayed by replace by
fee— or at least its inevitability if not value. So even ignoring
developers there may evolve a community consensus here regardless of
what I think about it.

My SO pointed that that the transaction burning race described above
sounds like an economists wet dream: it's one of those silly cases
they use in experiments to probe human behavior... except it sounds
like a possible eventual outcome in systems used by people.  Perhaps
it would be useful to point some graduate students at this question
and see what they can come up with about it.

--
Try New Relic Now  We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app,  servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development