scorched earth refers to the _real world_ impact such policies would
have on present-day 0-conf usage within the bitcoin community.
All payment processors AFAIK process transactions through some scoring
system, then accept 0-conf transactions for payments.
This isn't some theoretical exercise.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 21 February 2015 17:47:28 GMT-05:00, Jeff Garzik jgar...@bitpay.com wrote:
scorched earth refers to the _real world_ impact such policies would
have on present-day 0-conf usage within the bitcoin community.
I think you guys are reading too
On Sat, Feb 21, 2015 at 11:47 PM, Jeff Garzik jgar...@bitpay.com wrote:
scorched earth refers to the _real world_ impact such policies would
have on present-day 0-conf usage within the bitcoin community.
When I posted this: http://sourceforge.net/p/bitcoin/mailman/message/32263765/
Peter Todd
On Sat, Feb 21, 2015 at 10:25 PM, Jorge Timón jti...@jtimon.cc wrote:
On Sat, Feb 21, 2015 at 11:47 PM, Jeff Garzik jgar...@bitpay.com wrote:
This isn't some theoretical exercise. Like it or not many use
insecure 0-conf transactions for rapid payments. Deploying something
that makes 0-conf
Adam seems to be making sense to me. Only querying a single node when an
address in my wallet matches the block filter seems to be pretty
efficient. The downside is it relies entirely on Tor for privacy, but
then again it's not the only aspect of spv clients that require it for
privacy (there's
Adam seems to be making sense to me. Only querying a single node when an
address in my wallet matches the block filter seems to be pretty efficient.
No, I think it's less efficient (for the client).
Quick sums: blocks with 1500 transactions in them are common today. But
Bitcoin is growing.
Yeah that overhead is pretty high. I wasn't thinking about 10 years out.
On Sat, Feb 21, 2015, 11:47 AM Mike Hearn m...@plan99.net wrote:
Adam seems to be making sense to me. Only querying a single node when an
address in my wallet matches the block filter seems to be pretty efficient.
No,
On 21/02/15 14:49, 木ノ下じょな wrote:
Thank you for your feedback. I have written the Abstract and Motivation.
Much better. Thanks!
--
Best Regards / S pozdravom,
Pavol Rusnak st...@gk2.sk
--
Download BIRT iHub F-Type -
Hello Bob,
And compromise of that longer key still compromises the entire wallet.
No, in fact I could give you any node (derived extended private key) or key
(derived normal bitcoin address private key) AND any node's extended public
key above them, and as long as the keys are generated within
On 21/02/15 14:20, 木ノ下じょな wrote:
I have put together a proposal for a new generation methodology of HD
wallets.
Your proposal is missing Abstract and Motivation sections. Abstract
tells us WHAT are trying to achieve, Motivation tells WHY. It's not
worth to dig into technical details of your
Thank you for your feedback. I have written the Abstract and Motivation.
If my English is poor please let me know. Also let me know any other
comments or criticism you may have.
Thank you,
Jona
2015-02-21 22:34 GMT+09:00 Pavol Rusnak st...@gk2.sk:
On 21/02/15 14:20, 木ノ下じょな wrote:
I have put
For downloading transactions unless you frequently receive
transactions you wont be fetching every block. Or are you assuming
bloom filters dialled up to the point of huge false positives? You
said otherwise.
Well, what I mean is, bitcoinj already gets criticised for having very low
FP
Yes.
That is similar to an idea at FC15 (
http://fc15.ifca.ai/preproceedings/paper_15.pdf) but instead of increasing
the number of keys needed up to m, and protecting against m-1 leaks. (so if
you have to give keys out to 10 departments you must store 11 keys, or 363
bytes, I have decided to
If you want to be constructive and index transactions that are not
p2sh but non-simple and contain checksig so the address is visible,
you could do that with a block bloom filter also.
I wasnt sure if the comments about the need to batch requests was
about downloading headers filters, or about
Thank you Jorge for the contribution of the Stag Hunt terminology. It is
much better than a politically charged scorched earth.
On Feb 21, 2015 11:10 AM, Jorge Timón jti...@jtimon.cc wrote:
I agree scorched hearth is a really bad name for the 0 conf protocol
based on game theory. I would have
I agree scorched hearth is a really bad name for the 0 conf protocol
based on game theory. I would have preferred stag hunt since that's
basically what it's using (see http://en.wikipedia.org/wiki/Stag_hunt)
but I like the protocol and I think it would be interesting to
integrate it in the
16 matches
Mail list logo
