"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"
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 a
On Sat, Jun 07, 2014 at 12:02:36AM +0200, Raúl Martínez 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
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 wrote:
> Alice does not intercept the transaction, she only
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-0
>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 wrote:
> I dont know if this attack is even possib
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 no
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 no
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,
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/
-
On Fri, Jun 06, 2014 at 10:10:51AM -0700, Gregory Maxwell wrote:
> On Fri, Jun 6, 2014 at 10:05 AM, Peter Todd 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
On Fri, Jun 6, 2014 at 10:05 AM, Peter Todd 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 deta
On Fri, Jun 06, 2014 at 09:58:19AM -0700, Gregory Maxwell wrote:
> On Fri, Jun 6, 2014 at 9:46 AM, Peter Todd 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)
On Fri, Jun 6, 2014 at 9:46 AM, Peter Todd 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
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 06, 2014 at 05:04:41AM -0400, Peter Todd wrote:
>On Fri, Jun 06, 2014 at 10:48:52AM +0200, Adam Back wrote:
>> 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 propos
On Fri, Jun 06, 2014 at 02:03:29AM -0700, Gregory Maxwell wrote:
> On Fri, Jun 6, 2014 at 1:48 AM, 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 pri
On Fri, Jun 6, 2014 at 1:48 AM, 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 propos
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 addr
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 d
On Fri, Jun 6, 2014 at 10:29 AM, Wladimir wrote:
> On Wed, Jun 4, 2014 at 12:42 PM, Jannis Froese
> 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
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 a
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 vers
23 matches
Mail list logo
