Re: [Bitcoin-development] Double Spend Notification

[Gavin Andresen]

I'm very much in favor of double-spend propagation across the network.

Most of the arguments about replace-based-on-fee /
child-pays-burn-coins / etc are orthogonal.

Letting a merchant know ASAP that their customer is trying to cheat
them is, in my opinion, strictly better than what we have now.

-- 
--
Gavin Andresen

--
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)

[Mark Friedenbach]

This was meant to go to everyone:

On 5/20/13 7:45 PM, Jeff Garzik wrote:
> On Mon, May 20, 2013 at 7:59 PM, Mark Friedenbach  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.
That is true, and perhaps we have enough clout to push an RFC specifying 
a double-SHA256 Version 6, or at least get it reserved. I proposed 
Version 4 (random) because any UUID library should allow you to specify 
the 122 supposedly random bits of that version, whereas conceivably 
there might exist UUID libraries that require a SHA1 pre-image to create 
a Version 5 UUID (I know of no examples though). Regardless, making an 
official double-SHA256 UUID version RFC is an option worth considering.
> 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.
I think there are perhaps two issues being conflated here (and in Mike's 
response): the UI identifying the network/coin to the user, and the 
matching of the protocol-supplied value to the underlying network/coin 
by the client/daemon. The former necessarily involves manual adjustments 
(e.g, localization), but it's preferable for the latter to be a 
self-validating reference to the block chain. This is a trivial 
difference for multi-chain wallets (what are you doing receiving 
requests for coins in chains you don't know about?), but is important 
for colored coins. Let me explain:

I will be proposing soon a colored coin architecture that allows 
issuance of new coins by anyone for a fee, by means of a special 
category of transaction. The hash of that issuing transaction would then 
be used to generate a UUID identifying the asset for the payment 
protocol and other purposes as well, analogous to how the hash of the 
genesis block identifies the host currency, bitcoin. It is expected that 
there will be many such coins issued, as they can be used to represent 
individual loans or lines of credit. In this context, any colored-coin 
aware client could scan the block chain (or lookup a maintained index) 
to discover the UUID -> coin mapping with absolute certainty. However 
the mechanism for mapping the text "mtgoxUSD" to a specific coin is not 
clear, and using some sort of DNS-resolution system adds huge external 
dependencies. IMHO it is much better to have the identifier derived from 
block chain data directly (and therefore accessible and trusted by all 
nodes), and then carry out optional UI mappings like UUID(...) -> 
"mtgoxUSD" at a higher level.

Does that make sense?

--
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)

[Luke-Jr]

Bitcoin currently uses raw hashes extensively as UUIDs; whether the payment 
protocol should be influence by that or not, I've not given thought to yet.

Some alt coins may share a blockchain, or even merely the genesis block (two 
currently do; despite one of those being a scamcoin, I think the possibility 
should not be dismissed). Because of this, requiring a 1:1 mapping between 
genesis block and chain or coin seems non-ideal.

On Monday, May 20, 2013 11:59:39 PM Mark Friedenbach wrote:
> 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

--
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

[Gregory Maxwell]

On Mon, May 20, 2013 at 6:56 PM, Pieter Wuille  wrote:
> On Tue, May 21, 2013 at 3:24 AM, Robert Backhaus  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

Re: [Bitcoin-development] Double Spend Notification

[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 > 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 rel

Re: [Bitcoin-development] Double Spend Notification

[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  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"  wrote:
>
>> On Tue, May 21, 2013 at 3:24 AM, Robert Backhaus 
>> 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] UUID to identify chains (payment protocol and elsewhere)

[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"  wrote:

> On Mon, May 20, 2013 at 7:59 PM, Mark Friedenbach 
> 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

[Mike Hearn]

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"  wrote:

> On Tue, May 21, 2013 at 3:24 AM, Robert Backhaus 
> 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] UUID to identify chains (payment protocol and elsewhere)

[Jeff Garzik]

On Mon, May 20, 2013 at 7:59 PM, Mark Friedenbach  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] Double Spend Notification

[Pieter Wuille]

On Tue, May 21, 2013 at 3:24 AM, Robert Backhaus  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] Double Spend Notification

[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  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 produ

[Bitcoin-development] Double Spend Notification

[Quinn Harris]

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 two 
transactions.  To reduce DOS potential, the proof should not be relayed 
unless one of the original transactions has been received to ensure 
there is some commitment to the block chain and different double spend 
proofs of the same output should not be relayed.  The forwarding of 
transactions should remain exactly the same as it is now where the 
second transaction is dropped but a double spend message is transmitted 
if appropriate.

The existing block chain needs to be checked to make sure the proof of 
double spend couldn't have been derived from the block chain and a 
single spend in the memory pool.  This could happen if there was already 
an identical transaction in the block chain.  This would typically only 
happen if someone was paying someone else the same amount they had 
before and neither side changed addresses.  In this case double spend 
detection wouldn't be reliable as it could be generated by anyone, but 
both the sending and receiving client could detect this situation and 
warn the user.

It would still be possible for an attacker to send the second 
transaction directly to powerful miners but this is a distinctly less 
viable attack than the current double spend attack.

I would expect this double spend notification implementation to make 
double spends more costly than they are worth for most cases today that 
0 confirmation acceptance is needed.  That said over time this provision 
might become less effective.  As the reward for each block mined 
decreases, transactions fees will become a more significant part of the 
mining reward 

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

[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] is there a way to do bitcoin-staging?

[Luke-Jr]

This sounds similar to the "bitcoin2" branch I created a while back - 
basically a "next"-like branch, but for hardforking changes that refused to 
run without the -testnet option. There's so much non-hardforking code that can 
be written/tested, at this point, that I think it was and maybe is premature 
to be writing hardforking code outside of necessity. But perhaps if you want 
to play around, it might be a good starting point (it can probably merge up to 
latest master, and trivial to rebase if not).

On Sunday, May 19, 2013 1:23:59 PM Adam Back wrote:
> Is there a way to experiment with new features - eg committed coins - that
> doesnt involve an altcoin in the conventional sense, and also doesnt impose
> a big testing burden on bitcoin main which is a security and testing risk?
> 
> eg lets say some form of merged mine where an alt-coin lets call it
> bitcoin-staging?  where the coins are the same coins as on bitcoin, the
> mining power goes to bitcoin main, so some aspect of merged mining, but no
> native mining.  and ability to use bitcoins by locking them on bitcoin to
> move them to bitcoin-staging and vice versa (ie exchange them 1:1
> cryptographically, no exchange).
> 
> Did anyone figure anything like that out?  Seems vaguely doable and
> maybe productive.  The only people with coins at risk of defects in a new
> feature, or insufficiently well tested novel feature are people with coins
> on bitcoin-staging.
> 
> Yes I know about bitcoin-test this is not it.  I mean a real live system,
> with live value, but that is intentionally wanting to avoid forking
> bitcoins parameters, nor value, nor mindshare dillution.  In this way
> something potentially interesting could move forward faster, and be les
> risky to the main bitcoin network.  eg particularly defenses against
> 
> It might also be a more real world test test (after bitcoin-test) because
> some parameters are different on test, and some issues may not manifest
> without more real activity.
> 
> Then also bitcoin could cherry pick interesting patches and merge them
> after extensive real-world validation with real-money at stake (by early
> adopters).
> 
> Adam
> 
> ---
> --- AlienVault Unified Security Management (USM) platform delivers complete
> security visibility with the essential security capabilities. Easily and
> efficiently configure, manage, and operate all of your security controls
> from a single console and one unified framework. Download a free trial.
> http://p.sf.net/sfu/alienvault_d2d
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

--
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unified framework. Download a free trial.
http://p.sf.net/sfu/alienvault_d2d
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development