[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

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

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

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

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

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

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

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

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

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

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

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,

[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

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

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:

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

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

[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