[Bitcoin-development] NODE_BLOOM service bit

2014-06-06 Thread Peter Todd
BIP: 
https://github.com/petertodd/bips/blob/bip-node-bloom/bip-node-bloom.mediawiki

Pull-req: https://github.com/bitcoin/bitcoin/pull/2900

Pretty simple really: service bit NODE_BLOOM is defined to allow nodes
to advertise to their peers that they support bloom filters. The network
protocol version number is also bumped. Recommended behavior for nodes
that do not support bloom is to simply disconnect peers who send a
filter* message anyway to let them quickly find another peer.

Rational: Bloom filters are not always supported or appropriate. For
instance no node implementation other than Bitcoin Core supports them,
e.g btcd and obelisk. (which ironically implement this BIP already,
modulo the version number bump) In the long term bloom filters will be
obsoleted eventually as they have poor scaling properties - problematic
with blocksize increases - and are incompatible with UTXO/TXO
commitments, which will use prefix-based filtering instead. (already
being implemented in electrum and obelisk)

In the short term bloom filters have high IO loads, which have lead to
DoS attacks, and are not an optimal use of resources for nodes which are
IO constrained rather than bandwidth constrained. (common in VPS setups
which could better help the network by serving full blocks)

Adding NODE_BLOOM as a service bit now will save us some hassle later
down the road, reflects what actual implementations do anyway, has been
already deployed on Litecoin, Dogecoin, and a zillion other alts with no
issues, (including SPV client support) and is a trivial patch.


Gregory Maxwell: Please assign a BIP #

-- 
'peter'[:-1]@petertodd.org
49066dab2483c9e069656239f5782da204bd4995bd92c19f


signature.asc
Description: Digital signature
--
Learn Graph Databases - Download FREE O'Reilly Book
Graph Databases is the definitive new guide to graph databases and their 
applications. Written by three acclaimed leaders in the field, 
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] # error Bitcoin cannot be compiled without assertions. NOT

2014-06-06 Thread Wladimir
On Wed, Jun 4, 2014 at 12:42 PM, Jannis Froese 
s9jaf...@stud.uni-saarland.de wrote:

I think most concerns about the current use of asserts would be resolved if
 the currently used asserts would be changed to a nicer definition which is
 independent of NDEBUG, and a second class of debugging asserts would be
 introduced, which is exclusively for expensive, redundant checks and is
 disabled by NDEBUG.


Also, most assertion errors that happen to people running Bitcoin Core are
not caused by software bugs but database corruption errors (usually due to
unclean shutdown).

For example in case we detect missing/truncated block files or UTXO db
consistency we should, instead of raising an assertion error, propose a
-reindex - see also https://github.com/bitcoin/bitcoin/issues/2202 .

So instead of using assertions we need a fatal error function for those
problems which are probably recoverable in a certain specific way. In
principle starting a reindex wouldn't even need to take down the entire
process (though that's easier for implementation due to cleanup and
assumptions made).

Wladimir
--
Learn Graph Databases - Download FREE O'Reilly Book
Graph Databases is the definitive new guide to graph databases and their 
applications. Written by three acclaimed leaders in the field, 
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] NODE_BLOOM service bit

2014-06-06 Thread Peter Todd
On Fri, Jun 06, 2014 at 10:48:52AM +0200, Adam Back wrote:
 Advertising NODE BLOOM as a service sounds good.
 
 But the critique of bloom filters, I am not so sure prefix filters are
 better.  Prefix filters offer questionable privacy tradeoffs in my
 opinion. Same problem as with stealth address proposed use of
 prefixes.

That's assuming you're doing the proposed prefix brute forcing - if you
don't do that they have privacy equal or better than bloom filters, but
with better scalability. In particular that better scalability lets you
efficiently query multiple servers for blockchain data, only giving up
info on a subset of the addresses in your wallet to each server. This
can be a significant improvement to bloom filters if your attacker is
running logging nodes to try to, say, deanonymize CoinJoin transactions.

 All for scalability, efficiency and decentralization but not ideally at the
 expense of nuking privacy.  The effects on privacy are cumulative, and
 affect everyone not just the user.  Same pattern of local decision, global
 effect as with reused addresses.

Indeed. But again, remember that the existing systems suck too;
prefix-brute forcing is a engineering tradeoff implementable with
existing and well understood technology.

Now if you want to come up with something better and write code, please
do! I'm sure the math exists; what doesn't exist is robust and well
tested code in multiple languages. Stealth addresses at least have been
designed so that future blockchain filter upgrades can be added in a
backwards compatible way.

-- 
'peter'[:-1]@petertodd.org
3a68ee16d702ca5dd5547fb4aead910a004747cb06241dd6


signature.asc
Description: Digital signature
--
Learn Graph Databases - Download FREE O'Reilly Book
Graph Databases is the definitive new guide to graph databases and their 
applications. Written by three acclaimed leaders in the field, 
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] NODE_BLOOM service bit

2014-06-06 Thread Gregory Maxwell
On Fri, Jun 6, 2014 at 1:48 AM, Adam Back a...@cypherspace.org wrote:
 Advertising NODE BLOOM as a service sounds good.

 But the critique of bloom filters, I am not so sure prefix filters are
 better.  Prefix filters offer questionable privacy tradeoffs in my opinion.
 Same problem as with stealth address proposed use of prefixes.

 All for scalability, efficiency and decentralization but not ideally at the
 expense of nuking privacy.  The effects on privacy are cumulative, and
 affect everyone not just the user.  Same pattern of local decision, global
 effect as with reused addresses.

The performance Bytecoin/Monero/Fantom/etc. systems that use ECDH
addresses for all transactions seem to be suggesting that the prefixes
aren't really needed.

At least with current system rules doing the ECDH for each transaction
seems pretty reasonable.

--
Learn Graph Databases - Download FREE O'Reilly Book
Graph Databases is the definitive new guide to graph databases and their 
applications. Written by three acclaimed leaders in the field, 
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] NODE_BLOOM service bit

2014-06-06 Thread Peter Todd
On Fri, Jun 06, 2014 at 02:03:29AM -0700, Gregory Maxwell wrote:
 On Fri, Jun 6, 2014 at 1:48 AM, Adam Back a...@cypherspace.org wrote:
  Advertising NODE BLOOM as a service sounds good.
 
  But the critique of bloom filters, I am not so sure prefix filters are
  better.  Prefix filters offer questionable privacy tradeoffs in my opinion.
  Same problem as with stealth address proposed use of prefixes.
 
  All for scalability, efficiency and decentralization but not ideally at the
  expense of nuking privacy.  The effects on privacy are cumulative, and
  affect everyone not just the user.  Same pattern of local decision, global
  effect as with reused addresses.
 
 The performance Bytecoin/Monero/Fantom/etc. systems that use ECDH
 addresses for all transactions seem to be suggesting that the prefixes
 aren't really needed.
 
 At least with current system rules doing the ECDH for each transaction
 seems pretty reasonable.

Yup. Obelisk's indexing is sufficiently fast that they hadn't even
bothered making Dark Wallet store transaction information between
sessions until recently. Prefix brute-forcing isn't yet implemented,
although prefix filters is being implemented for lookups in general. (at
the very least it gives the server operators some valuable plausible
deniability)

-- 
'peter'[:-1]@petertodd.org
3a68ee16d702ca5dd5547fb4aead910a004747cb06241dd6


signature.asc
Description: Digital signature
--
Learn Graph Databases - Download FREE O'Reilly Book
Graph Databases is the definitive new guide to graph databases and their 
applications. Written by three acclaimed leaders in the field, 
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Bloom bait

2014-06-06 Thread Peter Todd
On Fri, Jun 06, 2014 at 12:45:43PM +0200, Adam Back wrote:

(changed subject line as this discussion has nothing to do with
NODE_BLOOM)

 As I recall prefix brute forcing was a bit twiddle saving, ie searching for
 EDH key that has the users public prefix.  That does not improve privacy
 over an explicit prefix, it saves a byte or so at the expense of average 128
 EDH exchanges to send and provides also some probably relatively ineffective
 plausible deniability by enabling the transaction to be indistinguishable
 from some other (not very common) types of transaction.

I think you should re-read my original proposal; there's a whole host of
misunderstandings above, for instance I have no idea where you got the
idea that it has anything to do with saving a byte came from, or where
the number 128 came from.

 don't do that they have privacy equal or better than bloom filters, but
 with better scalability.
 
 either its full node only where prefixes are not used, which is less
 scalable than bloom; or prefixes are used explicitly or implicitly
 (brute-force) and either way privacy is weakened by the extra correlation
 hook provided by elimination from the network graph of payments with
 mismatched prefixes.

Again, you have a misunderstanding. Both bloom filters and prefix
filters are just ways of giving a peer a probabalistic filter to match
transactions against. Where they differ is that bloom filters has O(n)
scaling, where n is the size of a block, and prefix filters have O(log n)
scaling with slightly(1) higher k. Again, if you *don't* use brute forcing
in conjunction with prefixes they have no different transactional graph
privacy than bloom filters, but the better scalability lets you do
things like split your queries across multiple peers that give you
better protection against hostile nodes.  Additionally prefix filters
are compatible with future miner committed indexes to make the data
authenticated.

1) see Amir's experience implementing prefix lookup in Obelisk

 We need to consider the two types of privacy involved.  Privacy from the
 full node an SPV client is relying on to find its payments, vs privacy from
 analysis of the public transaction graph.

Agreed

 The latter is more damaging.

Maybe! If adversaries are operating a significant fraction of the peers
you are connecting to the current design of bloom filters + HD wallets
results in situations where those adversaries have better transactional
graph information than the alternative.

 Better to design for privacy against future analysis of
 public info, than
 privacy by argument to select non-hostile nodes.  Tor has changed recently
 to account for the fact that chosing fresh random nodes is actually
 worse. ie you have a probability of identity/address identification
 per route/node,
 and repeatedly selecting routes/nodes just cumulatively increases the chance
 you'll be identified.  Better to pick a random node, identify it and stick
 to it and hope you chose well.

That's basically what Electrum and Obelisk already do - by default you
connect to a relatively small set of blockchain data servers operated by
well known people and use the same server repeatedly.

Applying that to the P2P network however is tricky as there is a huge
amount of churn in the nodes:

#bitcoin-dev/14/06/14-06-06.log:11:18  hearn bitcoinj can't use
[service bits] as it relies on DNS seeds and that is unlikely to change
any time soon due to the general churn rate in the network making it
hard to bootstrap quickly using just remembered sets of IPs.

 Maybe other simpler, but yes there was the proof of concept that the math
 exists in the form of the weil pairing.
 
 https://bitcointalk.org/index.php?topic=431756.new

I know, where can I find running code? Remember that a bug can easily
lose thousands of dollars worth of Bitcoins.

-- 
'peter'[:-1]@petertodd.org
1d2af1653c415b7801ce4c9b18ac7e87bef597e652b203e6


signature.asc
Description: Digital signature
--
Learn Graph Databases - Download FREE O'Reilly Book
Graph Databases is the definitive new guide to graph databases and their 
applications. Written by three acclaimed leaders in the field, 
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Bloom bait

2014-06-06 Thread Gregory Maxwell
On Fri, Jun 6, 2014 at 9:46 AM, Peter Todd p...@petertodd.org wrote:
 transactions against. Where they differ is that bloom filters has O(n)
 scaling, where n is the size of a block, and prefix filters have O(log n)
 scaling with slightly(1) higher k. Again, if you *don't* use brute forcing
 in conjunction with prefixes they have no different transactional graph
 privacy than bloom filters,

Huh? How are you thinking that something that gets put in transactions
and burned forever into the blockchain that lets you (statically) link
txout ownership is no different from something which is shared
directly with a couple peers, potentially peers you trust and which
are run by yourself or your organization?

--
Learn Graph Databases - Download FREE O'Reilly Book
Graph Databases is the definitive new guide to graph databases and their 
applications. Written by three acclaimed leaders in the field, 
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Bloom bait

2014-06-06 Thread Peter Todd
On Fri, Jun 06, 2014 at 09:58:19AM -0700, Gregory Maxwell wrote:
 On Fri, Jun 6, 2014 at 9:46 AM, Peter Todd p...@petertodd.org wrote:
  transactions against. Where they differ is that bloom filters has O(n)
  scaling, where n is the size of a block, and prefix filters have O(log n)
  scaling with slightly(1) higher k. Again, if you *don't* use brute forcing
  in conjunction with prefixes they have no different transactional graph
  privacy than bloom filters,
 
 Huh? How are you thinking that something that gets put in transactions
 and burned forever into the blockchain that lets you (statically) link
 txout ownership is no different from something which is shared
 directly with a couple peers, potentially peers you trust and which
 are run by yourself or your organization?

Again, you *don't* have to use brute-force prefix selection. You can
just as easily give your peer multiple prefixes, each of which
corresponds at least one address in your wallet with some false positive
rate. I explained all this in detail in my original blockchain data
privacy writeup months ago.

-- 
'peter'[:-1]@petertodd.org
29d945c3832c7f4afabce11e6cb1c27b6f5e8c0f2bbb356c


signature.asc
Description: Digital signature
--
Learn Graph Databases - Download FREE O'Reilly Book
Graph Databases is the definitive new guide to graph databases and their 
applications. Written by three acclaimed leaders in the field, 
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Bloom bait

2014-06-06 Thread Gregory Maxwell
On Fri, Jun 6, 2014 at 10:05 AM, Peter Todd p...@petertodd.org wrote:
 Again, you *don't* have to use brute-force prefix selection. You can
 just as easily give your peer multiple prefixes, each of which
 corresponds at least one address in your wallet with some false positive
 rate. I explained all this in detail in my original blockchain data
 privacy writeup months ago.

I'm not trying to pick nits about all the options,  I just found it
surprising that you were saying that data published in a super public
manner is no different than something used between nodes.

 I explained all this in detail in my original blockchain data privacy writeup 
 months ago.

Communication is a two way street, Adam and I (and others) are
earnestly trying— that we're not following your arguments may be a
suggestion that they need to be communicated somewhat differently.

I'm still failing to see the usefulness of having any prefix filtering
for DH-private outputs. It really complicates the security story— in
particular you don't know _now_ what activities will turn your prior
information leaks into compromising ones retrospectivelly, and doesn't
seem at very necessary for scanning performance.

--
Learn Graph Databases - Download FREE O'Reilly Book
Graph Databases is the definitive new guide to graph databases and their 
applications. Written by three acclaimed leaders in the field, 
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Bloom bait

2014-06-06 Thread Peter Todd
On Fri, Jun 06, 2014 at 10:10:51AM -0700, Gregory Maxwell wrote:
 On Fri, Jun 6, 2014 at 10:05 AM, Peter Todd p...@petertodd.org wrote:
  Again, you *don't* have to use brute-force prefix selection. You can
  just as easily give your peer multiple prefixes, each of which
  corresponds at least one address in your wallet with some false positive
  rate. I explained all this in detail in my original blockchain data
  privacy writeup months ago.
 
 I'm not trying to pick nits about all the options,  I just found it
 surprising that you were saying that data published in a super public
 manner is no different than something used between nodes.

Because I was designing a system under the assumption that you were
highly likely to connect to an attacker at some point, and the trade-off
available with the available math was to either give very detailed info
to that attacker, or give away some probabalistic info to everyone.

  I explained all this in detail in my original blockchain data privacy 
  writeup months ago.
 
 Communication is a two way street, Adam and I (and others) are
 earnestly trying— that we're not following your arguments may be a
 suggestion that they need to be communicated somewhat differently.

Quite likely - I think most of this disagreement stems from the fact
that we have different starting assumptions. In particular my assumption
that you are likely to end up connecting to an attacker logging data,
and my desire to have a standard that can be implemented with existing
cryptographic primatives. Remember that I'm spending a lot of time
working with wallet authors; they have approximately zero interest in
standards that require crypto any more fancy than HD wallets do.

 I'm still failing to see the usefulness of having any prefix filtering
 for DH-private outputs. It really complicates the security story— in
 particular you don't know _now_ what activities will turn your prior
 information leaks into compromising ones retrospectivelly, and doesn't
 seem at very necessary for scanning performance.

Scanning performance is different from bandwidth performance. Prefix
brute-forcing was designed to address the latter concern for cases where
you are bandwidth limited and don't have a trusted peer to do the
scanning for you.

-- 
'peter'[:-1]@petertodd.org
1c5e0fca7bd6d96211a37543c1d0cc2f594c15423ee3cdd8


signature.asc
Description: Digital signature
--
Learn Graph Databases - Download FREE O'Reilly Book
Graph Databases is the definitive new guide to graph databases and their 
applications. Written by three acclaimed leaders in the field, 
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[Bitcoin-development] Wallet nLockTime best practices

2014-06-06 Thread Jeff Garzik
We are considering pulling in https://github.com/bitcoin/bitcoin/pull/2340
Discourage fee sniping with nLockTime

Comments from other wallet implementors in particular are welcomed.

-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.  https://bitpay.com/

--
Learn Graph Databases - Download FREE O'Reilly Book
Graph Databases is the definitive new guide to graph databases and their 
applications. Written by three acclaimed leaders in the field, 
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Wallet nLockTime best practices

2014-06-06 Thread Aaron Voisine
I'll implement it in breadwallet (oss SPV wallet, hopefully about to
be in the app store) if other wallet authors are planning to.

Aaron
https://github.com/voisine/breadwallet

There's no trick to being a humorist when you have the whole
government working for you -- Will Rodgers


On Fri, Jun 6, 2014 at 12:00 PM, Jeff Garzik jgar...@bitpay.com wrote:
 We are considering pulling in https://github.com/bitcoin/bitcoin/pull/2340
 Discourage fee sniping with nLockTime

 Comments from other wallet implementors in particular are welcomed.

 --
 Jeff Garzik
 Bitcoin core developer and open source evangelist
 BitPay, Inc.  https://bitpay.com/

 --
 Learn Graph Databases - Download FREE O'Reilly Book
 Graph Databases is the definitive new guide to graph databases and their
 applications. Written by three acclaimed leaders in the field,
 this first edition is now available. Download your free book today!
 http://p.sf.net/sfu/NeoTech
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development

--
Learn Graph Databases - Download FREE O'Reilly Book
Graph Databases is the definitive new guide to graph databases and their 
applications. Written by three acclaimed leaders in the field, 
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[Bitcoin-development] Possible attack: Keeping unconfirmed transactions

2014-06-06 Thread Raúl Martínez
I dont know if this attack is even possible, it came to my mind and I will
try to explain it as good as possible.

Some transacions keep unconfirmed forever and finally they are purged by
Bitcoin nodes, mostly due to the lack of fees.


Example:
-

Alice is selling a pizza to Bob, Bob is now making the payment with Bitcoin.
The main goal of this attack is to store a unconfirmed transaction send by
Bob for a few days (it will not be included in the blockchain because it
has no fee or due to other reason), Bob might resend the payment or might
just cancel the deal with Alice.

Bob forgets about that failed trade but a couple of days later, Alice, who
has stored the signed transacion, relays the transaction to the network (or
mines it directly with his own hashpower).
Bob does not know what is happening, he believed that that transaction was
canceled forever, he even does not remember the failed pizza deal.

Alice has now the bitcoins and Bob does not know what happened with his
money.

-

This might also work with the Payment Protocol because when using it Bob
does not relay the transaction to the network, its Alices job to do it,
Alice stores it and tells Bob to resend the payment, Bob creates another
transaction (If has the same inputs as the first TX this does not work)
(this one is relayed by Alice to the network).

Alice comes back a couple of days later and mines with his hashrate the
first transaction (the one she didnt relayed to the network).

Alice now has two payments, Bob does not know what happened.


---

I hope that I explained well this possible attack, I dont know if there is
already a fix for this problem or if it is simply impossible to execute
this kind of attack.

Thanks for your time.
--
Learn Graph Databases - Download FREE O'Reilly Book
Graph Databases is the definitive new guide to graph databases and their 
applications. Written by three acclaimed leaders in the field, 
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Possible attack: Keeping unconfirmed transactions

2014-06-06 Thread Toshi Morita
From what I know, Alice does not know to which node Bob will broadcast the
transaction. Therefore, Alice cannot intercept the transaction and prevent
the rest of the network from seeing it.

Toshi



On Fri, Jun 6, 2014 at 3:02 PM, Raúl Martínez r...@i-rme.es wrote:

 I dont know if this attack is even possible, it came to my mind and I will
 try to explain it as good as possible.

 Some transacions keep unconfirmed forever and finally they are purged by
 Bitcoin nodes, mostly due to the lack of fees.


 Example:
 -

 Alice is selling a pizza to Bob, Bob is now making the payment with
 Bitcoin.
 The main goal of this attack is to store a unconfirmed transaction send by
 Bob for a few days (it will not be included in the blockchain because it
 has no fee or due to other reason), Bob might resend the payment or might
 just cancel the deal with Alice.

 Bob forgets about that failed trade but a couple of days later, Alice, who
 has stored the signed transacion, relays the transaction to the network (or
 mines it directly with his own hashpower).
 Bob does not know what is happening, he believed that that transaction was
 canceled forever, he even does not remember the failed pizza deal.

 Alice has now the bitcoins and Bob does not know what happened with his
 money.

 -

 This might also work with the Payment Protocol because when using it Bob
 does not relay the transaction to the network, its Alices job to do it,
 Alice stores it and tells Bob to resend the payment, Bob creates another
 transaction (If has the same inputs as the first TX this does not work)
 (this one is relayed by Alice to the network).

 Alice comes back a couple of days later and mines with his hashrate the
 first transaction (the one she didnt relayed to the network).

 Alice now has two payments, Bob does not know what happened.


 ---

 I hope that I explained well this possible attack, I dont know if there is
 already a fix for this problem or if it is simply impossible to execute
 this kind of attack.

 Thanks for your time.






 --
 Learn Graph Databases - Download FREE O'Reilly Book
 Graph Databases is the definitive new guide to graph databases and their
 applications. Written by three acclaimed leaders in the field,
 this first edition is now available. Download your free book today!
 http://p.sf.net/sfu/NeoTech
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development


--
Learn Graph Databases - Download FREE O'Reilly Book
Graph Databases is the definitive new guide to graph databases and their 
applications. Written by three acclaimed leaders in the field, 
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Possible attack: Keeping unconfirmed transactions

2014-06-06 Thread Raúl Martínez
Alice does not intercept the transaction, she only saves it and expect that
it will not be confirmed (because has 0 fee for example).

Also using the Payment Protocol I believe that Alice is the only person
that can relay Bob's transaction.

Source: https://github.com/bitcoin/bips/blob/master/bip-0070.mediawiki

*When the merchant's server receives the Payment message, it must determine
 whether or not the transactions satisfy conditions of payment. If and only
 if they do, if should broadcast the transaction(s) on the Bitcoin p2p
 network.*



2014-06-07 0:11 GMT+02:00 Toshi Morita to...@peernova.com:

 From what I know, Alice does not know to which node Bob will broadcast the
 transaction. Therefore, Alice cannot intercept the transaction and prevent
 the rest of the network from seeing it.

 Toshi



 On Fri, Jun 6, 2014 at 3:02 PM, Raúl Martínez r...@i-rme.es wrote:

 I dont know if this attack is even possible, it came to my mind and I
 will try to explain it as good as possible.

 Some transacions keep unconfirmed forever and finally they are purged by
 Bitcoin nodes, mostly due to the lack of fees.


 Example:
 -

 Alice is selling a pizza to Bob, Bob is now making the payment with
 Bitcoin.
 The main goal of this attack is to store a unconfirmed transaction send
 by Bob for a few days (it will not be included in the blockchain because it
 has no fee or due to other reason), Bob might resend the payment or might
 just cancel the deal with Alice.

 Bob forgets about that failed trade but a couple of days later, Alice,
 who has stored the signed transacion, relays the transaction to the network
 (or mines it directly with his own hashpower).
 Bob does not know what is happening, he believed that that transaction
 was canceled forever, he even does not remember the failed pizza deal.

 Alice has now the bitcoins and Bob does not know what happened with his
 money.

 -

 This might also work with the Payment Protocol because when using it Bob
 does not relay the transaction to the network, its Alices job to do it,
 Alice stores it and tells Bob to resend the payment, Bob creates another
 transaction (If has the same inputs as the first TX this does not work)
 (this one is relayed by Alice to the network).

 Alice comes back a couple of days later and mines with his hashrate the
 first transaction (the one she didnt relayed to the network).

 Alice now has two payments, Bob does not know what happened.


 ---

 I hope that I explained well this possible attack, I dont know if there
 is already a fix for this problem or if it is simply impossible to execute
 this kind of attack.

 Thanks for your time.






 --
 Learn Graph Databases - Download FREE O'Reilly Book
 Graph Databases is the definitive new guide to graph databases and their
 applications. Written by three acclaimed leaders in the field,
 this first edition is now available. Download your free book today!
 http://p.sf.net/sfu/NeoTech
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development



--
Learn Graph Databases - Download FREE O'Reilly Book
Graph Databases is the definitive new guide to graph databases and their 
applications. Written by three acclaimed leaders in the field, 
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Possible attack: Keeping unconfirmed transactions

2014-06-06 Thread Pieter Wuille
Whenever you do a reissuing of a transaction that didn't go through
earlier, you should make sure to reuse one of the inputs for it. That
guarantees that both cannot confirm simultaneously.

On Sat, Jun 7, 2014 at 12:21 AM, Raúl Martínez r...@i-rme.es wrote:
 Alice does not intercept the transaction, she only saves it and expect that
 it will not be confirmed (because has 0 fee for example).

 Also using the Payment Protocol I believe that Alice is the only person that
 can relay Bob's transaction.

 Source: https://github.com/bitcoin/bips/blob/master/bip-0070.mediawiki

 When the merchant's server receives the Payment message, it must determine
 whether or not the transactions satisfy conditions of payment. If and only
 if they do, if should broadcast the transaction(s) on the Bitcoin p2p
 network.



 2014-06-07 0:11 GMT+02:00 Toshi Morita to...@peernova.com:

 From what I know, Alice does not know to which node Bob will broadcast the
 transaction. Therefore, Alice cannot intercept the transaction and prevent
 the rest of the network from seeing it.

 Toshi



 On Fri, Jun 6, 2014 at 3:02 PM, Raúl Martínez r...@i-rme.es wrote:

 I dont know if this attack is even possible, it came to my mind and I
 will try to explain it as good as possible.

 Some transacions keep unconfirmed forever and finally they are purged by
 Bitcoin nodes, mostly due to the lack of fees.


 Example:
 -

 Alice is selling a pizza to Bob, Bob is now making the payment with
 Bitcoin.
 The main goal of this attack is to store a unconfirmed transaction send
 by Bob for a few days (it will not be included in the blockchain because it
 has no fee or due to other reason), Bob might resend the payment or might
 just cancel the deal with Alice.

 Bob forgets about that failed trade but a couple of days later, Alice,
 who has stored the signed transacion, relays the transaction to the network
 (or mines it directly with his own hashpower).
 Bob does not know what is happening, he believed that that transaction
 was canceled forever, he even does not remember the failed pizza deal.

 Alice has now the bitcoins and Bob does not know what happened with his
 money.

 -

 This might also work with the Payment Protocol because when using it Bob
 does not relay the transaction to the network, its Alices job to do it,
 Alice stores it and tells Bob to resend the payment, Bob creates another
 transaction (If has the same inputs as the first TX this does not work)
 (this one is relayed by Alice to the network).

 Alice comes back a couple of days later and mines with his hashrate the
 first transaction (the one she didnt relayed to the network).

 Alice now has two payments, Bob does not know what happened.


 ---

 I hope that I explained well this possible attack, I dont know if there
 is already a fix for this problem or if it is simply impossible to execute
 this kind of attack.

 Thanks for your time.






 --
 Learn Graph Databases - Download FREE O'Reilly Book
 Graph Databases is the definitive new guide to graph databases and
 their
 applications. Written by three acclaimed leaders in the field,
 this first edition is now available. Download your free book today!
 http://p.sf.net/sfu/NeoTech
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development




 --
 Learn Graph Databases - Download FREE O'Reilly Book
 Graph Databases is the definitive new guide to graph databases and their
 applications. Written by three acclaimed leaders in the field,
 this first edition is now available. Download your free book today!
 http://p.sf.net/sfu/NeoTech
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development


--
Learn Graph Databases - Download FREE O'Reilly Book
Graph Databases is the definitive new guide to graph databases and their 
applications. Written by three acclaimed leaders in the field, 
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] # error Bitcoin cannot be compiled without assertions. NOT

2014-06-06 Thread Jeff Garzik
Speaking very generally, the Linux kernel wisdom on this tends to be,

* Compile in as many cheap, compiler-predictable asserts as possible
into the production runtime.
* Debug builds are of limited value.  Users do not recompile software,
just to provide better bug reports/diagnostics.
* Make it as easy as possible for users to send reports that are
useful to programmers.
* Expensive diagnostics are fine. Compile in, but disable by default
at runtime (and make sure these features, when turned off, do not slow
down the system).
* Make sure the assert/dump provides a high level of diagnostics.
Stack trace of each thread + multi-threaded core dump are a good
start.

-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.  https://bitpay.com/

--
Learn Graph Databases - Download FREE O'Reilly Book
Graph Databases is the definitive new guide to graph databases and their 
applications. Written by three acclaimed leaders in the field, 
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[Bitcoin-development] Bitcoin miner heads-up: getwork RPC going away

2014-06-06 Thread Jeff Garzik
getwork has long been unused on mainnet, and mostly unused elsewhere
as well.  It generates work by a method that cannot keep up with the
demands of the modern network.

As such, it is planned to remove getwork in the next release.  Most
if not all pool servers have switched away from getwork years ago.

-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.  https://bitpay.com/

--
Learn Graph Databases - Download FREE O'Reilly Book
Graph Databases is the definitive new guide to graph databases and their 
applications. Written by three acclaimed leaders in the field, 
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development