On Sat, Feb 21, 2015 at 10:25 PM, Jorge Timón wrote:
> On Sat, Feb 21, 2015 at 11:47 PM, Jeff Garzik 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 transactions unusable would h
On Sat, Feb 21, 2015 at 11:47 PM, Jeff Garzik 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 clarified that t
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 21 February 2015 17:47:28 GMT-05:00, Jeff Garzik 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 much into the name
"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.
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" wrote:
> I agree "scorched hearth" is a really bad name for the 0 conf protocol
> based on game theory. I would have preferred
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 pay
Yeah that overhead is pretty high. I wasn't thinking about 10 years out.
On Sat, Feb 21, 2015, 11:47 AM Mike Hearn 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, I think i
>
> 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 growin
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 bro
>
> 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
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 t
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:49, 木ノ下じょな wrote:
> Thank you for your feedback. I have written the Abstract and Motivation.
Much better. Thanks!
--
Best Regards / S pozdravom,
Pavol Rusnak
--
Download BIRT iHub F-Type - The Free Ente
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 :
> On 21/02/15 14:20, 木ノ下じょな wrote:
> > I have put together
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 im
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 leave
Let's put the UTXO commitments/anti-fraud proofs to one side for a moment.
I would like to see them happen one day, but they aren't critical to these
protocols and are just proving to be a distraction.
> Then they make fresh random connections to different nodes and request
> download of the res
Whats the objective? Is it to require accidental disclosure of two
private keys to compute the master private key?
Adam
On 21 February 2015 at 13:20, 木ノ下じょな wrote:
> Hello All,
>
> I have put together a proposal for a new generation methodology of HD
> wallets.
>
> The method is a modification
Hello All,
I have put together a proposal for a new generation methodology of HD
wallets.
The method is a modification of BIP32, so if something is unclear or not
explicit, please assume it follows BIP32.
I am looking forward to any and all criticism and help with writing /
making the BIP more s
19 matches
Mail list logo
