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
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
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
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
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
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
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
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
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
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
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/
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,
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
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
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:
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
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
17 matches
Mail list logo
