Re: [Bitcoin-development] replace-by-fee v0.10.0rc4
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 have a wide, negative >> impact on present day bitcoin payments, thus "scorched earth" > And maybe by maintaining first seen policies we're harming the system > in the long term by encouraging people to widely deploy systems based > on extremely weak assumptions. Lacking a coded, reviewed alternative, that's only a platitude. Widely used 0-conf payments are where we're at today. Simply ceasing the "maintaining [of] first seen policies" alone is simply not a realistic option. The negative impact to today's userbase would be huge. Instant payments need a security upgrade, yes. -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] replace-by-fee v0.10.0rc4
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 the concept was referred to as "scorched earth" http://sourceforge.net/p/bitcoin/mailman/message/32264039/ Like I said I don't like the name and would prefer "stag hunting" which is more formal and precise. Some people seem to use the same term for "the potential undesirable consequences of widely deployed replace-by-fee policies". I'm not sure that concept deserves its own term. > All payment processors AFAIK process transactions through some scoring > system, then accept 0-conf transactions for payments. > > 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 have a wide, negative > impact on present day bitcoin payments, thus "scorched earth" And maybe by maintaining first seen policies we're harming the system in the long term by encouraging people to widely deploy systems based on extremely weak assumptions. -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] replace-by-fee v0.10.0rc4
-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... Replace-by-fee is called "replace-by-fee" because it considers whether to replace or not based on fee; the idea came about in an discussion about replacement based on nSequence. I forget whether it was myself or John Dillon who came up with the name "scorched earth", but it just refers to the game theory behind the *specific* idea of the receiver combating a zeroconf double-spend by sending all the funds to fees. Scorched earth as in "You're trying to defraud me, so I'm not going yo play this game or negotiate, I'm just going to immediately do what is most likely to make you lose the maximum amount of money to punish you for your vandalism." >All payment processors AFAIK process transactions through some scoring >system, then accept 0-conf transactions for payments. > >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 have a wide, negative >impact on present day bitcoin payments, thus "scorched earth" I'm not so convinced, precisely because we've seen zeroconf fail in pretty bad ways; the people most vulnerable to losses have generally changed the way they operate. (e.g. ATM's that no longer rely on zeroconf security, instead waiting for confirmations, installing cameras, etc.) My #1 concern right now is person-to-person trading, and people doing that tend to wait for confirmations or otherwise protect themselves. (e.g. reputation systems) >Without adequate decentralized solutions for instant payments, >deploying replace-by-fee widely would simply push instant transactions >even more into the realm of centralized, walled-garden services. Agreed. Deploying it has been something I've made into a long, drawn out, protracted process for precisely that reason. OTOH I sometimes wonder if I've gone too far with that - the services that themselves try to guarantee zeroconf right now through metrics are themselves highly centralised, and there's a big risk of them driving mining centralisation itself when they fail. -BEGIN PGP SIGNATURE- iQE9BAEBCAAnIBxQZXRlciBUb2RkIDxwZXRlQHBldGVydG9kZC5vcmc+BQJU6S2N AAoJEMCF8hzn9LncrFUH/1xhuPhYJnjTCxhpv2h5ZJOT3wLsrU1oEDmD5fWy/4wG 7ppr3EiHNX7nB42fgeSGZF8fW1VuBjivJa9ra3IvFysFfaD40Kyre2FTnN03+vTC Upa5ykPzOMqZIHkSf8N1xMbz4SXHHPWu8wPMzj/QGvUpllNiOWn/6Vooqrcp7f6Y NJFykSq+vDNMOUWCiJG8hhoKiOcZhTH0Aj9qPcGs9WhgsF7wDAX7pg6iO6Y5qmt5 LdFcut2caL6mIxpExm0F9V+lyeam/3gvAU3eecHY77KOxRxFTO1xfQXEJFTWN92h +M9BXQZ1UifjTZWMzK0kp3SRJuVSXg4KOAapQFBLTzU= =3Mmw -END PGP SIGNATURE- -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] replace-by-fee v0.10.0rc4
"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. Like it or not many use insecure 0-conf transactions for rapid payments. Deploying something that makes 0-conf transactions unusable would have a wide, negative impact on present day bitcoin payments, thus "scorched earth" Without adequate decentralized solutions for instant payments, deploying replace-by-fee widely would simply push instant transactions even more into the realm of centralized, walled-garden services. On Sat, Feb 21, 2015 at 3:30 PM, Mark Friedenbach wrote: > 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 "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 payment protocol. >> Even if that protocol didn't existed or didn't worked, replace-by-fee >> is purely part of a node's policy, not part of consensus. >> >From the whitepaper, 0 conf transactions being secure by the good will >> of miners was never an assumption, and it is clear to me that the >> system cannot provide those guaranties based on such a weak scheme. I >> believe thinking otherwise is naive. >> As to consider non-standard policies "an attack to bitcoin" because >> "that's not how bitcoin used to work", then I guess minimum relay fee >> policies can also be considered "an attack to bitcoin" on the same >> grounds. >> Lastly, "first-seen-wins" was just a simple policy to bootstrap the >> system, but I expect that most nodes will eventually move to policies >> that are economically rational for miners such as replace-by-fee. >> Not only I disagree this will be "the end of bitcoin" or "will push >> the price of the btc miners are mining down", I believe it will be >> something good for bitcoin. >> Since this is apparently controversial I don't want to push for >> replace-by-fee to become the new standard policy (something that would >> make sense to me). But once the policy code is sufficiently modular as >> to support several policies I would like bitcoin core to have a >> CReplaceByFeePolicy alongside CStandardPolicy and a CNullPolicy (no >> policy checks at all). >> One step at a time I guess... >> >> >> On Thu, Feb 19, 2015 at 9:56 AM, Troy Benjegerdes wrote: >> > On Sun, Feb 15, 2015 at 11:40:24PM +0200, Adam Gibson wrote: >> >> >> >> >> >> On 02/15/2015 11:25 PM, Troy Benjegerdes wrote: >> >> > >> >> > Most money/payment systems include some method to reverse or undo >> >> > payments made in error. In these systems, the longer settlement >> >> > times you mention below are a feature, not a bug, and give more >> >> > time for a human to react to errors and system failures. >> >> > >> >> >> >> Settlement has to be final somewhere. That is the whole point of it. >> >> Transfer costs in current electronic payment systems are a direct >> >> consequence of their non-finality. That's the point Satoshi was making >> >> in the introduction to the whitepaper: "With the possibility of >> >> reversal, the need for trust spreads". >> > >> > The problem with that statement is I trust a merchant that I went into >> > a store and made a payment with personally more than I trust the >> > firmware >> > on my hard drive [1]. >> > >> > The attack surface of devices in your computer is huge. A motivated >> > attacker >> > just needs to get an intern into a company that makes some kind of >> > component >> > or system that's in your computer, cloud server, hardware wallet, or >> > what >> > have you that has firmware capable of reading your private keys. >> > >> > With the possibility of mass trojaned hardware, if we are going to trust >> > the system, it must somehow allow reversal through a human-in-the-loop. >> > >> >> There is nothing wrong with having reversible mechanisms built on top >> >> of Bitcoin, and indeed it makes sense for most activity to happen at >> >> those higher layers. It's easy to build things that way, but >> >> impossible to build them the other way: you can't build a >> >> non-reversible layer on top of a reversible layer. >> > >> > We built 'reliable' TCP on top of unreliable ethernet networks. My >> > experience >> > with networking was if you tried to guarantee message delivery at the >> > lowest >> > level, the system got exceedingly complicated, expensive, and brittle. >> > >> > Most applications, in particular paying someone you already trust, are >> > quite >> > happy running on reversible systems, and in some cases
Re: [Bitcoin-development] replace-by-fee v0.10.0rc4
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 "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 payment protocol. > Even if that protocol didn't existed or didn't worked, replace-by-fee > is purely part of a node's policy, not part of consensus. > >From the whitepaper, 0 conf transactions being secure by the good will > of miners was never an assumption, and it is clear to me that the > system cannot provide those guaranties based on such a weak scheme. I > believe thinking otherwise is naive. > As to consider non-standard policies "an attack to bitcoin" because > "that's not how bitcoin used to work", then I guess minimum relay fee > policies can also be considered "an attack to bitcoin" on the same > grounds. > Lastly, "first-seen-wins" was just a simple policy to bootstrap the > system, but I expect that most nodes will eventually move to policies > that are economically rational for miners such as replace-by-fee. > Not only I disagree this will be "the end of bitcoin" or "will push > the price of the btc miners are mining down", I believe it will be > something good for bitcoin. > Since this is apparently controversial I don't want to push for > replace-by-fee to become the new standard policy (something that would > make sense to me). But once the policy code is sufficiently modular as > to support several policies I would like bitcoin core to have a > CReplaceByFeePolicy alongside CStandardPolicy and a CNullPolicy (no > policy checks at all). > One step at a time I guess... > > > On Thu, Feb 19, 2015 at 9:56 AM, Troy Benjegerdes wrote: > > On Sun, Feb 15, 2015 at 11:40:24PM +0200, Adam Gibson wrote: > >> > >> > >> On 02/15/2015 11:25 PM, Troy Benjegerdes wrote: > >> > > >> > Most money/payment systems include some method to reverse or undo > >> > payments made in error. In these systems, the longer settlement > >> > times you mention below are a feature, not a bug, and give more > >> > time for a human to react to errors and system failures. > >> > > >> > >> Settlement has to be final somewhere. That is the whole point of it. > >> Transfer costs in current electronic payment systems are a direct > >> consequence of their non-finality. That's the point Satoshi was making > >> in the introduction to the whitepaper: "With the possibility of > >> reversal, the need for trust spreads". > > > > The problem with that statement is I trust a merchant that I went into > > a store and made a payment with personally more than I trust the firmware > > on my hard drive [1]. > > > > The attack surface of devices in your computer is huge. A motivated > attacker > > just needs to get an intern into a company that makes some kind of > component > > or system that's in your computer, cloud server, hardware wallet, or what > > have you that has firmware capable of reading your private keys. > > > > With the possibility of mass trojaned hardware, if we are going to trust > > the system, it must somehow allow reversal through a human-in-the-loop. > > > >> There is nothing wrong with having reversible mechanisms built on top > >> of Bitcoin, and indeed it makes sense for most activity to happen at > >> those higher layers. It's easy to build things that way, but > >> impossible to build them the other way: you can't build a > >> non-reversible layer on top of a reversible layer. > > > > We built 'reliable' TCP on top of unreliable ethernet networks. My > experience > > with networking was if you tried to guarantee message delivery at the > lowest > > level, the system got exceedingly complicated, expensive, and brittle. > > > > Most applications, in particular paying someone you already trust, are > quite > > happy running on reversible systems, and in some cases more reliable and > > lower risk. (carrying non-reversible cash is generally considered risky) > > > > The problem is that if the base currency is assumed to be non-reversible, > > then it's brittle and becomes 'too big to fail'. > > > > Where the blockchain improves on everything else is in transparency. If > you > > reverse transactions a lot, it will be obvious from an analysis. I would > much > > rather deal with a known, predictable, and relatively continous > transaction > > reversal rate (percentage) than have to deal with sudden failures where > > some anonymous bad actor makes off with a fortune. > > > > We already have zero-conf double-spend transaction reversal, why not > explicitly > > extend that a little in a way that senders and receivers have a choice to > > use it, or not? > > > > > > [1] > http://www.reuters.com/article/2015/02/16/us-usa-cyberspying-idUSKBN0LK1QV2
Re: [Bitcoin-development] replace-by-fee v0.10.0rc4
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 payment protocol. Even if that protocol didn't existed or didn't worked, replace-by-fee is purely part of a node's policy, not part of consensus. >From the whitepaper, 0 conf transactions being secure by the good will of miners was never an assumption, and it is clear to me that the system cannot provide those guaranties based on such a weak scheme. I believe thinking otherwise is naive. As to consider non-standard policies "an attack to bitcoin" because "that's not how bitcoin used to work", then I guess minimum relay fee policies can also be considered "an attack to bitcoin" on the same grounds. Lastly, "first-seen-wins" was just a simple policy to bootstrap the system, but I expect that most nodes will eventually move to policies that are economically rational for miners such as replace-by-fee. Not only I disagree this will be "the end of bitcoin" or "will push the price of the btc miners are mining down", I believe it will be something good for bitcoin. Since this is apparently controversial I don't want to push for replace-by-fee to become the new standard policy (something that would make sense to me). But once the policy code is sufficiently modular as to support several policies I would like bitcoin core to have a CReplaceByFeePolicy alongside CStandardPolicy and a CNullPolicy (no policy checks at all). One step at a time I guess... On Thu, Feb 19, 2015 at 9:56 AM, Troy Benjegerdes wrote: > On Sun, Feb 15, 2015 at 11:40:24PM +0200, Adam Gibson wrote: >> >> >> On 02/15/2015 11:25 PM, Troy Benjegerdes wrote: >> > >> > Most money/payment systems include some method to reverse or undo >> > payments made in error. In these systems, the longer settlement >> > times you mention below are a feature, not a bug, and give more >> > time for a human to react to errors and system failures. >> > >> >> Settlement has to be final somewhere. That is the whole point of it. >> Transfer costs in current electronic payment systems are a direct >> consequence of their non-finality. That's the point Satoshi was making >> in the introduction to the whitepaper: "With the possibility of >> reversal, the need for trust spreads". > > The problem with that statement is I trust a merchant that I went into > a store and made a payment with personally more than I trust the firmware > on my hard drive [1]. > > The attack surface of devices in your computer is huge. A motivated attacker > just needs to get an intern into a company that makes some kind of component > or system that's in your computer, cloud server, hardware wallet, or what > have you that has firmware capable of reading your private keys. > > With the possibility of mass trojaned hardware, if we are going to trust > the system, it must somehow allow reversal through a human-in-the-loop. > >> There is nothing wrong with having reversible mechanisms built on top >> of Bitcoin, and indeed it makes sense for most activity to happen at >> those higher layers. It's easy to build things that way, but >> impossible to build them the other way: you can't build a >> non-reversible layer on top of a reversible layer. > > We built 'reliable' TCP on top of unreliable ethernet networks. My experience > with networking was if you tried to guarantee message delivery at the lowest > level, the system got exceedingly complicated, expensive, and brittle. > > Most applications, in particular paying someone you already trust, are quite > happy running on reversible systems, and in some cases more reliable and > lower risk. (carrying non-reversible cash is generally considered risky) > > The problem is that if the base currency is assumed to be non-reversible, > then it's brittle and becomes 'too big to fail'. > > Where the blockchain improves on everything else is in transparency. If you > reverse transactions a lot, it will be obvious from an analysis. I would much > rather deal with a known, predictable, and relatively continous transaction > reversal rate (percentage) than have to deal with sudden failures where > some anonymous bad actor makes off with a fortune. > > We already have zero-conf double-spend transaction reversal, why not > explicitly > extend that a little in a way that senders and receivers have a choice to > use it, or not? > > > [1] > http://www.reuters.com/article/2015/02/16/us-usa-cyberspying-idUSKBN0LK1QV20150216 > > -- > Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server > from Actuate! Instantly Supercharge Your Business Reports and Dashboards > with Interactivity, Sharing, Native Excel Exports, App Integration & more > Get technology previously reserved for billion-dollar cor
Re: [Bitcoin-development] bloom filtering, privacy
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 it's less efficient (for the client).
>
> Quick sums: blocks with 1500 transactions in them are common today. But
> Bitcoin is growing. Let's imagine a system 10x larger than today. Doesn't
> seem implausible to reach that in the next 5-10 years, so 15,000
> transactions. Each transaction has multiple elements we might want to match
> (addresses, keys, etc).
>
> Let's say the average tx contains 5 unique keys/elements. That's the base
> case of {1 input, 2 outputs} without address reuse, plus fudged up a bit
> for multi-sends then down a bit again for address reuse.
>
> 15,000*5=75,000 unique elements per block. With an FP rate of 0.1% we get:
>
> http://hur.st/bloomfilter?n=75000&p=0.001
>
> 131.63KB per block extra overhead.
>
> 144 blocks in a day, so that's 18mb of data per day's worth of sync to
> pull down over the network. If you don't start your wallet for a week
> that's 126 megabytes of data just to get started.
>
> Affordable, yes (in the west). Fast enough to be competitive? Doubtful. I
> don't believe that even in five years mobiles will be pulling down and
> processing that much data within a few seconds, not even in developed
> countries.
>
> But like I said, I don't see why it matters. Anyone who is watching the
> wire close to you learns which transactions are yours, still, so it doesn't
> stop intelligence agencies. Anyone who is running a node learns which
> transactions in the requested block were yours and thus can follow the tx
> chain to learn which other transactions might be yours too, no different to
> today. If you connect to a single node and say "give me the transactions
> sending money to key A in block N", it doesn't matter if you then don't
> request block N+6 from the same peer - they know you will request it
> eventually anyway, just by virtue of the fact that one of the transactions
> they gave you was spent in that block.
>
>
>
--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] bloom filtering, privacy
>
> 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. Let's imagine a system 10x larger than today. Doesn't
seem implausible to reach that in the next 5-10 years, so 15,000
transactions. Each transaction has multiple elements we might want to match
(addresses, keys, etc).
Let's say the average tx contains 5 unique keys/elements. That's the base
case of {1 input, 2 outputs} without address reuse, plus fudged up a bit
for multi-sends then down a bit again for address reuse.
15,000*5=75,000 unique elements per block. With an FP rate of 0.1% we get:
http://hur.st/bloomfilter?n=75000&p=0.001
131.63KB per block extra overhead.
144 blocks in a day, so that's 18mb of data per day's worth of sync to pull
down over the network. If you don't start your wallet for a week that's 126
megabytes of data just to get started.
Affordable, yes (in the west). Fast enough to be competitive? Doubtful. I
don't believe that even in five years mobiles will be pulling down and
processing that much data within a few seconds, not even in developed
countries.
But like I said, I don't see why it matters. Anyone who is watching the
wire close to you learns which transactions are yours, still, so it doesn't
stop intelligence agencies. Anyone who is running a node learns which
transactions in the requested block were yours and thus can follow the tx
chain to learn which other transactions might be yours too, no different to
today. If you connect to a single node and say "give me the transactions
sending money to key A in block N", it doesn't matter if you then don't
request block N+6 from the same peer - they know you will request it
eventually anyway, just by virtue of the fact that one of the transactions
they gave you was spent in that block.
--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] bloom filtering, privacy
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 broadcasting for example). And on a related note, if we eventually do end up receiving bip70 payments directly, we still need to query for block inclusion and that would seem to be an easy way to do it. On 02/20/2015 12:53 PM, Mike Hearn wrote: > > This is talking about a committed bloom filter. Not a committed > UTXO set. > > > I read the following comment to mean it requires the UTXO commitments. > Otherwise I'm not sure how you prove absence of withholding with just > current block structures+an extra filter included in the block: > > but with the bloom commitment (and UTXO trie organised commitment) he > can verify that the positive hits are correct via the merkle path, and > that the false positives are not being wrongly withheld by obtaining > merkle path proof that they are not in the trie > > > > > > -- > Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server > from Actuate! Instantly Supercharge Your Business Reports and Dashboards > with Interactivity, Sharing, Native Excel Exports, App Integration & more > Get technology previously reserved for billion-dollar corporations, FREE > http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk > > > ___ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] bloom filtering, privacy
> > 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 rates, but even with those rates we're applying them to hundreds of thousands of transactions per sync. So it's still enough FPs to trigger at least one per block, often several, yet people tell us this isn't enough to give meaningful privacy. > Relatedly I think bitcoin could do with a store-and-forward message > bus with privacy and strong reliability via redundancy (but less > redundancy maybe than consensus all-nodes must receiving and agree and > store forever). > Yup, see here: https://www.bitcoinauthenticator.org/subspace/ https://groups.google.com/forum/#!topic/bitcoinj/_S15jo5mcDI Subspace looks like it's developing into what we need. > You seem to be saying at one point that Tor is useless against > pervasive eavesdropper threat model No, Tor is effective against in that threat model. What I meant is that without Tor, someone doing wire intercepts isn't going to be fazed by using multiple peers together, and with Tor it's not clear that syncing from multiple peers in parallel gives much an additional win. Also, getting Tor practical enough to activate by default is tricky. Though the same people who are doing Subspace are trying it out to see what happens. secondly that other types of attackers are disinterested (how do we know > that?) or maybe that you > dont care about privacy vs them (maybe some users do!) > Some of my opinions are based on experience of HTTPS deployments, where many of the same issues apply. > It would certainly be nice to get real privacy from a wider range of > attackers but nothing (current situation) is clearly worse; using > block bloom filters we'd make the pervasive case harder work, and the > nosy full node learn nothing. Yes, but what's the best way to fix that? The calculation goes like this: we have ~80 hours of hacking time to spend on privacy this quarter. Do we: a) Do wire encryption b) Make Bloom filter clients smarter c) Optimise Tor d) Do a new PIR protocol from scratch and possibly run out of time having failed to launch Of these (d) is the least appealing to me, especially because I don't feel like submitting SPV related stuff to Bitcoin Core any more. If I were to work on the protocol it'd be in the context of Bitcoin XT, which rules out consensus changes or other things that rely on miners. Wire encryption would probably raise the bar for our spooky friends quite a lot, with minimal effort. The ROI looks good, compared to more complex PIR. -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] bloom filtering, privacy
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 transactions, there is no harm downloading headers & bloom filters without Tor - there is no identity nor addresses revealed by doing so. So over Tor you would just be fetching transactions that match the address. 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. Mid-term I'd say you want some basic request tunneling as part of bitcoin, that maybe isnt Tor, to avoid sharing their fate if Tor controversies are a risk to Tor service. Some of the bitcoin-Tor specific weak points could maybe then be addressed. Relatedly I think bitcoin could do with a store-and-forward message bus with privacy and strong reliability via redundancy (but less redundancy maybe than consensus all-nodes must receiving and agree and store forever). That provides an efficient store-and-forward SPV receivable stealth-address solution that doesnt suck: send the recipient their payment, if they like it they broadcast it themselves. As a bonus store-and-forward message mixes are better able to provide meaningful network privacy than interactive privacy networks. You could spend over the same channel You seem to be saying at one point that Tor is useless against pervasive eavesdropper threat model (which I am not sure I agree with, minimally it makes them work for the info and adds uncertainty; and not been paying super close attention but I think some of the Snowden releases suggest Tor is a net win) and secondly that other types of attackers are disinterested (how do we know that?) or maybe that you dont care about privacy vs them (maybe some users do!) It would certainly be nice to get real privacy from a wider range of attackers but nothing (current situation) is clearly worse; using block bloom filters we'd make the pervasive case harder work, and the nosy full node learn nothing. Adam On 21 February 2015 at 13:28, Mike Hearn wrote: > 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 respective individual transactions from the full node. > > > ... > >> About privacy the node can make different random connections to >> different nodes to fetch addresses . The full node cant >> correlate the addresses as belonging to the same person by correlating >> the download requests for them, because they are made via different >> nodes. > > > Apologies for the wall of text, but I don't think this will work nor solve > any real problem. And I must justify such a strong statement clearly. > > First: technical issues > > When you download the per-block Bloom filter and test, what you get back is > a set of script elements (addresses, keys, OP_RETURN tags etc). But then in > the next step you are saying that you connect to random peers and request > individual transactions. We don't know that at this point. All we know are a > set of addresses that possibly matched. So I think what you mean is "wallets > connect to random peers and request transactions in block N that match a > given set of addresses". > > This is what Bloom filtering already does, of course. Doing the test against > the per-block filter first doesn't seem to buy us much because with > thousands of transactions per block, even a very tiny FP rate will still > trigger a match on every single one. > > The second problem I see is that we can't do this in parallel because of the > following edge case: wallet contains key K and someone sends it money using > an OP_CHECKSIG output. The input which spends this output does not contain > any predictable data, thus we do not know what to look for in the following > blocks to detect a spend of it until we have seen the first transaction and > know its hash. > > In practice this means we must either scan through the chain in sequence and > update our matching criteria if we see such an output (this is what the > Bloom filtering protocol already does server-side), or we must constrain the > user such that output scripts always force repetition of predictable data - > this is what mostly happens today due to pay-to-address outputs, but not > always, and correctness is more important than completeness. > > If we can't do it in parallel then we must suffer a node round-trip for > every single block we traverse, because we can't request long runs of blocks > with a single command. That latency will kill performance dead. It's a non
Re: [Bitcoin-development] Request for a new BIP number (and discussion): Improved HD wallet generation.
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 my specifications, you can not derive the associated extended private key to the ancestor extended public key. If you think it still compromises the entire wallet, please show me in pseudo code / explanation. > Under what circumstances would anyone ever be passing around private keys without your a,b? I just added a Motivation section showing one example called Reality Keys. They send bitcoins to Yes/No bet addresses and the result of the bet's private key is revealed to award the winners via special P2SH scripts. So they would need to give out "smaller" keys (aka normal private keys) and it would be better to manage them hierarchically instead of just generating millions of keys ahead of time and storing them on USBs or something. Thanks, Jona 2015-02-21 22:57 GMT+09:00 Bob Mcelrath : > But this just makes the private HD key longer, effectively. And compromise > of that longer key still compromises the entire wallet. > > Under what circumstances would anyone ever be passing around private keys > without your a,b? The longer privkey is a wallet backup and has a reason to > be copied. I can't think of a scenario where anyone would use or compromise > the shorter privkey. > > On February 21, 2015 8:32:30 AM EST, "木ノ下じょな" > wrote: >> >> 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 it at 2 keys protecting 1 leak, >> and then using convention to prevent calculating the master private key by >> requiring all private keys AND all extended private keys (aka "nodes" in my >> proposal) to be derived alone under their respective parents. >> >> In theory this will prevent leakage of private keys from destroying the >> entire HD wallet entirely. >> >> Services like "Reality Keys" could be a perfect use case (he must release >> private keys relating to the outcome, so he has decided against using BIP32 >> to generate addresses for! the bets. >> >> Any Cryptographers that would like to take a look at the math and see if >> it's sound, I think I am properly breaking any linear relationships between >> keys... but I would like a second opinion. >> >> Thank you for your reply, >> Jona >> >> 2015-02-21 22:23 GMT+09:00 Adam Back : >> >>> 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 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 secure. >>> > >>> > If some of my pseudo code / English is off I apologize, I am not good >>> with >>> > words. >>> > >>> > If this is deemed worthy enough to be drafted into a BIP, I would >>> appreciate >>> > if someone could tell me what the overall step by step flow would be. >>> > >>> > Thank you, I will paste the link to the proposal below. >>> > Jona >>> > >>> > https://gist.github.com/dabura667/875bb2c159b219c18885 >>> > >>> > -- >>> > -BEGIN PGP PUBLIC KEY BLOCK- >>> > Comment: http://openpgpjs.org >>> > >>> > xsBNBFTmJ8oBB/9rd+7XLxZG/x/KnhkVK2WBG8ySx91fs+qQfHIK1JrakSV3 >>> > x6x0cK3XLClASLLDomm7Od3Q/fMFzdwCEqj6z60T8wgKxsjWYSGL3mq8ucdv >>> > iBjC3wGauk5dQKtT7tkCFyQQbX/uMsBM4ccGBICoDmIJlwJIj7fAZVqGxGOM >>> > bO1RhYb4dbQA2qxYP7wSsHJ6/ZNAXyEphOj6blUzdqO0exAbCOZWWF+E/1SC >>> > EuKO4RmL7Imdep7uc2Qze1UpJCZx7ASHl2IZ4UD0G3Qr3pI6/jvNlaqCTa3U >>> > 3/YeJwEubFsd0AVy0zs809RcKKgX3W1q+hVDTeWinem9RiOG/vT+Eec/ABEB >>> > AAHNI2tpbm9zaGl0YSA8a2lub3NoaXRham9uYUBnbWFpbC5jb20+wsByBBAB >>> > CAAmBQJU5ifRBgsJCAcDAgkQRB9iZ30dlisEFQgCCgMWAgECGwMCHgEAAC6Z >>> > B/9otobf0ASHYdlUBeIPXdDopyjQhR2RiZGYaS0VZ5zzHYLDDMW6ZIYm5CjO >>> > Fc09ETLGKFxH2RcCOK2dzwz+KRU4xqOrt/l5gyd50cFE1nOhUN9+/XaPgrou >>> > WhyT9xLeGit7Xqhht93z2+VanTtJAG6lWbAZLIZAMGMuLX6sJDCO0GiO5zxa >>> > 02Q2D3kh5GL57A5+oVOna12JBRaIA5eBGKVCp3KToT/z48pxBe3WAmLo0zXr >>> > hEgTSzssfb2zTwtB3Ogoedj+cU2bHJvJ8upS/jMr3TcdguySmxJlGpocVC/e >>> > qxq12Njv+LiETOrD8atGmXCnA+nFNljBkz+l6ADl93jHzsBNBFTmJ9EBCACu >>> > Qq9ZnP+aLU/Rt6clAfiHfTFBsJvLKsdIKeE6qHzsU1E7A7bGQKTtLEnhCCQE >>> > W+OQP+sgbOWowIdH9PpwLJ3Op+NhvLlMxRvbT36LwCmBL0yD7bMqxxmmVj8n >>> > vlMMRSe4wDSIG19Oy7701imnHZPm/pnPlneg/Meu/UffpcDWYBbAFX8nrXPY >>> > vkVULcI/qTcCxW/+S9fwoXjQhWHaiJJ6y3cYOSitN31W
Re: [Bitcoin-development] Request for a new BIP number (and discussion): Improved HD wallet generation.
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 Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Request for a new BIP number (and discussion): Improved HD wallet generation.
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 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 implementation until these > two questions are answered. > > -- > Best Regards / S pozdravom, > > Pavol Rusnak > -- -BEGIN PGP PUBLIC KEY BLOCK- Comment: http://openpgpjs.org xsBNBFTmJ8oBB/9rd+7XLxZG/x/KnhkVK2WBG8ySx91fs+qQfHIK1JrakSV3 x6x0cK3XLClASLLDomm7Od3Q/fMFzdwCEqj6z60T8wgKxsjWYSGL3mq8ucdv iBjC3wGauk5dQKtT7tkCFyQQbX/uMsBM4ccGBICoDmIJlwJIj7fAZVqGxGOM bO1RhYb4dbQA2qxYP7wSsHJ6/ZNAXyEphOj6blUzdqO0exAbCOZWWF+E/1SC EuKO4RmL7Imdep7uc2Qze1UpJCZx7ASHl2IZ4UD0G3Qr3pI6/jvNlaqCTa3U 3/YeJwEubFsd0AVy0zs809RcKKgX3W1q+hVDTeWinem9RiOG/vT+Eec/ABEB AAHNI2tpbm9zaGl0YSA8a2lub3NoaXRham9uYUBnbWFpbC5jb20+wsByBBAB CAAmBQJU5ifRBgsJCAcDAgkQRB9iZ30dlisEFQgCCgMWAgECGwMCHgEAAC6Z B/9otobf0ASHYdlUBeIPXdDopyjQhR2RiZGYaS0VZ5zzHYLDDMW6ZIYm5CjO Fc09ETLGKFxH2RcCOK2dzwz+KRU4xqOrt/l5gyd50cFE1nOhUN9+/XaPgrou WhyT9xLeGit7Xqhht93z2+VanTtJAG6lWbAZLIZAMGMuLX6sJDCO0GiO5zxa 02Q2D3kh5GL57A5+oVOna12JBRaIA5eBGKVCp3KToT/z48pxBe3WAmLo0zXr hEgTSzssfb2zTwtB3Ogoedj+cU2bHJvJ8upS/jMr3TcdguySmxJlGpocVC/e qxq12Njv+LiETOrD8atGmXCnA+nFNljBkz+l6ADl93jHzsBNBFTmJ9EBCACu Qq9ZnP+aLU/Rt6clAfiHfTFBsJvLKsdIKeE6qHzsU1E7A7bGQKTtLEnhCCQE W+OQP+sgbOWowIdH9PpwLJ3Op+NhvLlMxRvbT36LwCmBL0yD7bMqxxmmVj8n vlMMRSe4wDSIG19Oy7701imnHZPm/pnPlneg/Meu/UffpcDWYBbAFX8nrXPY vkVULcI/qTcCxW/+S9fwoXjQhWHaiJJ6y3cYOSitN31W9zgcMvLwLX3JgDxE flkwq/M+ZkfCYnS3GAPEt8GkVKy2eHtCJuNkGFlCAmKMX0yWzHRAkqOMN5KP LFbkKY2GQl13ztWp82QYJZpj5af6dmyUosurn6AZABEBAAHCwF8EGAEIABMF AlTmJ9QJEEQfYmd9HZYrAhsMAABKbgf/Ulu5JAk4fXgH0DtkMmdkFiKEFdkW 0Wkw7Vhd5eZ4NzeP9kOkD01OGweT9hqzwhfT2CNXCGxh4UnvEM1ZMFypIKdq 0XpLLJMrDOQO021UjAa56vHZPAVmAM01z5VzHJ7ekjgwrgMLmVkm0jWKEKaO n/MW7CyphG7QcZ6cJX2f6uJcekBlZRw9TNYRnojMjkutlOVhYJ3J78nc/k0p kcgV63GB6D7wHRF4TVe4xIBqKpbBhhN+ISwFN1z+gx3lfyRMSmiTSrGdKEQe XSIQKG8XZQZUDhLNkqPS+7EMV1g7+lOfT4GhLL68dUXDa1e9YxGH6zkpVECw Spe3vsHZr6CqFg== =/vUJ -END PGP PUBLIC KEY BLOCK- -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Request for a new BIP number (and discussion): Improved HD wallet generation.
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 implementation until these two questions are answered. -- Best Regards / S pozdravom, Pavol Rusnak -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Request for a new BIP number (and discussion): Improved HD wallet generation.
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 it at 2 keys protecting 1 leak, and then using convention to prevent calculating the master private key by requiring all private keys AND all extended private keys (aka "nodes" in my proposal) to be derived alone under their respective parents. In theory this will prevent leakage of private keys from destroying the entire HD wallet entirely. Services like "Reality Keys" could be a perfect use case (he must release private keys relating to the outcome, so he has decided against using BIP32 to generate addresses for the bets. Any Cryptographers that would like to take a look at the math and see if it's sound, I think I am properly breaking any linear relationships between keys... but I would like a second opinion. Thank you for your reply, Jona 2015-02-21 22:23 GMT+09:00 Adam Back : > 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 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 secure. > > > > If some of my pseudo code / English is off I apologize, I am not good > with > > words. > > > > If this is deemed worthy enough to be drafted into a BIP, I would > appreciate > > if someone could tell me what the overall step by step flow would be. > > > > Thank you, I will paste the link to the proposal below. > > Jona > > > > https://gist.github.com/dabura667/875bb2c159b219c18885 > > > > -- > > -BEGIN PGP PUBLIC KEY BLOCK- > > Comment: http://openpgpjs.org > > > > xsBNBFTmJ8oBB/9rd+7XLxZG/x/KnhkVK2WBG8ySx91fs+qQfHIK1JrakSV3 > > x6x0cK3XLClASLLDomm7Od3Q/fMFzdwCEqj6z60T8wgKxsjWYSGL3mq8ucdv > > iBjC3wGauk5dQKtT7tkCFyQQbX/uMsBM4ccGBICoDmIJlwJIj7fAZVqGxGOM > > bO1RhYb4dbQA2qxYP7wSsHJ6/ZNAXyEphOj6blUzdqO0exAbCOZWWF+E/1SC > > EuKO4RmL7Imdep7uc2Qze1UpJCZx7ASHl2IZ4UD0G3Qr3pI6/jvNlaqCTa3U > > 3/YeJwEubFsd0AVy0zs809RcKKgX3W1q+hVDTeWinem9RiOG/vT+Eec/ABEB > > AAHNI2tpbm9zaGl0YSA8a2lub3NoaXRham9uYUBnbWFpbC5jb20+wsByBBAB > > CAAmBQJU5ifRBgsJCAcDAgkQRB9iZ30dlisEFQgCCgMWAgECGwMCHgEAAC6Z > > B/9otobf0ASHYdlUBeIPXdDopyjQhR2RiZGYaS0VZ5zzHYLDDMW6ZIYm5CjO > > Fc09ETLGKFxH2RcCOK2dzwz+KRU4xqOrt/l5gyd50cFE1nOhUN9+/XaPgrou > > WhyT9xLeGit7Xqhht93z2+VanTtJAG6lWbAZLIZAMGMuLX6sJDCO0GiO5zxa > > 02Q2D3kh5GL57A5+oVOna12JBRaIA5eBGKVCp3KToT/z48pxBe3WAmLo0zXr > > hEgTSzssfb2zTwtB3Ogoedj+cU2bHJvJ8upS/jMr3TcdguySmxJlGpocVC/e > > qxq12Njv+LiETOrD8atGmXCnA+nFNljBkz+l6ADl93jHzsBNBFTmJ9EBCACu > > Qq9ZnP+aLU/Rt6clAfiHfTFBsJvLKsdIKeE6qHzsU1E7A7bGQKTtLEnhCCQE > > W+OQP+sgbOWowIdH9PpwLJ3Op+NhvLlMxRvbT36LwCmBL0yD7bMqxxmmVj8n > > vlMMRSe4wDSIG19Oy7701imnHZPm/pnPlneg/Meu/UffpcDWYBbAFX8nrXPY > > vkVULcI/qTcCxW/+S9fwoXjQhWHaiJJ6y3cYOSitN31W9zgcMvLwLX3JgDxE > > flkwq/M+ZkfCYnS3GAPEt8GkVKy2eHtCJuNkGFlCAmKMX0yWzHRAkqOMN5KP > > LFbkKY2GQl13ztWp82QYJZpj5af6dmyUosurn6AZABEBAAHCwF8EGAEIABMF > > AlTmJ9QJEEQfYmd9HZYrAhsMAABKbgf/Ulu5JAk4fXgH0DtkMmdkFiKEFdkW > > 0Wkw7Vhd5eZ4NzeP9kOkD01OGweT9hqzwhfT2CNXCGxh4UnvEM1ZMFypIKdq > > 0XpLLJMrDOQO021UjAa56vHZPAVmAM01z5VzHJ7ekjgwrgMLmVkm0jWKEKaO > > n/MW7CyphG7QcZ6cJX2f6uJcekBlZRw9TNYRnojMjkutlOVhYJ3J78nc/k0p > > kcgV63GB6D7wHRF4TVe4xIBqKpbBhhN+ISwFN1z+gx3lfyRMSmiTSrGdKEQe > > XSIQKG8XZQZUDhLNkqPS+7EMV1g7+lOfT4GhLL68dUXDa1e9YxGH6zkpVECw > > Spe3vsHZr6CqFg== > > =/vUJ > > -END PGP PUBLIC KEY BLOCK- > > > > > -- > > Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server > > from Actuate! Instantly Supercharge Your Business Reports and Dashboards > > with Interactivity, Sharing, Native Excel Exports, App Integration & more > > Get technology previously reserved for billion-dollar corporations, FREE > > > http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk > > ___ > > Bitcoin-development mailing list > > Bitcoin-development@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > > -- -BEGIN PGP PUBLIC KEY BLOCK- Comment: http://openpgpjs.org xsBNBFTmJ8oBB/9rd+7XLxZG/x/KnhkVK2WBG8ySx91fs+qQfHIK1JrakSV3 x6x0cK3XLClASLLDomm7Od3Q/fMFzdwCEqj6z60T8wgKxsjWYSGL3mq8ucdv iBjC3wGauk5dQKtT7tkCFyQQbX/uMsBM4ccGBICoDmIJlwJIj7fAZVqGxGOM bO1RhYb4dbQA2qxYP7wSsHJ6/ZNAXyEphOj6blUzdqO0exAbCOZWWF+E/1SC EuKO4RmL7Imdep7uc2Qze1UpJCZx7ASHl2IZ4UD0G3Qr3pI6/jvNlaqCTa3U 3/YeJwEubFsd0AVy0zs809RcKKgX3W1q+hVDTeWinem9RiOG/vT+Eec/ABEB AAHNI2tpbm
Re: [Bitcoin-development] bloom filtering, privacy
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 respective individual transactions from the full node. > ... About privacy the node can make different random connections to > different nodes to fetch addresses . The full node cant > correlate the addresses as belonging to the same person by correlating > the download requests for them, because they are made via different > nodes. Apologies for the wall of text, but I don't think this will work nor solve any real problem. And I must justify such a strong statement clearly. *First: technical issues* When you download the per-block Bloom filter and test, what you get back is a set of script elements (addresses, keys, OP_RETURN tags etc). But then in the next step you are saying that you connect to random peers and request individual transactions. We don't know that at this point. All we know are a set of addresses that possibly matched. So I think what you mean is "wallets connect to random peers and request transactions in block N that match a given set of addresses". This is what Bloom filtering already does, of course. Doing the test against the per-block filter first doesn't seem to buy us much because with thousands of transactions per block, even a very tiny FP rate will still trigger a match on every single one. The second problem I see is that we can't do this in parallel because of the following edge case: wallet contains key K and someone sends it money using an OP_CHECKSIG output. The input which spends this output does not contain any predictable data, thus we do not know what to look for in the following blocks to detect a spend of it until we have seen the first transaction and know its hash. In practice this means we must either scan through the chain in sequence and update our matching criteria if we see such an output (this is what the Bloom filtering protocol already does server-side), or we must constrain the user such that output scripts always force repetition of predictable data - this is what mostly happens today due to pay-to-address outputs, but not always, and correctness is more important than completeness. If we can't do it in parallel then we must suffer a node round-trip for every single block we traverse, because we can't request long runs of blocks with a single command. That latency will kill performance dead. It's a non starter. But let's imagine we don't care about OP_CHECKSIG outputs and are willing to ignore them. There are cases where they are the best and most efficient technical solution, but let's put that to one side. The primary difference after making the above changes are that no one node gets a filter containing *all* our keys and addresses. I don't think a per block pre-test filter would gain us much efficiency so from a privacy perspective this is what it boils down to - sharding of the scan. But we can already do this with the current Bloom filtering protocol. BitcoinJ doesn't do so because having multiple parallel scans uses up network IOPs which are a resource of unknown quantity, and because stepping through the chain in parallel with multiple peers complicates the chain sync implementation quite a bit. *Second: this doesn't solve any real problem* Who cares about collecting Bloom filters off the wire? Commercial fraudsters? Doubtful. There are much easier ways to steal money. Spies? Yes! Without a doubt NSA/GCHQ are building or have built databases of IP addresses to Bitcoin addresses and are correlating it via XKEYSCORE with other identifiable information. However, just requesting data from different nodes doesn't help with that, because they are doing DPI and can still see all the connections, so can still combine all the filters or received transactions. Ah, you say, but we're requesting everything via Tor. Yes, about that. We've implemented that already. Some wallets even use it by default, like Alon & Chris' Bitcoin Authenticator wallet. It's just one line of code to activate. Unfortunately there are severe practical problems to using Tor: 1. If you don't have a warm consensus then booting it up is very slow. We're already slower than our competitors like blockchain.info and VISA/MasterCard, we can't make this any worse. This one is possibly not that big a deal and can be solved with more technical tricks. 2. Bitcoin Core's DoS strategy means anyone can block all of Tor quite trivially. So we'd need some complicated fallback mechanism to disable Tor remotely, in case someone did this. 3. Bitcoin wire traffic isn't encrypted or authenticated so it makes it much easier for trolls to tamper with lots of wire traffic at once, whereas without Tor it's much harder. Let's ignore the fact that the Tor pro
Re: [Bitcoin-development] Request for a new BIP number (and discussion): Improved HD wallet generation.
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 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 secure. > > If some of my pseudo code / English is off I apologize, I am not good with > words. > > If this is deemed worthy enough to be drafted into a BIP, I would appreciate > if someone could tell me what the overall step by step flow would be. > > Thank you, I will paste the link to the proposal below. > Jona > > https://gist.github.com/dabura667/875bb2c159b219c18885 > > -- > -BEGIN PGP PUBLIC KEY BLOCK- > Comment: http://openpgpjs.org > > xsBNBFTmJ8oBB/9rd+7XLxZG/x/KnhkVK2WBG8ySx91fs+qQfHIK1JrakSV3 > x6x0cK3XLClASLLDomm7Od3Q/fMFzdwCEqj6z60T8wgKxsjWYSGL3mq8ucdv > iBjC3wGauk5dQKtT7tkCFyQQbX/uMsBM4ccGBICoDmIJlwJIj7fAZVqGxGOM > bO1RhYb4dbQA2qxYP7wSsHJ6/ZNAXyEphOj6blUzdqO0exAbCOZWWF+E/1SC > EuKO4RmL7Imdep7uc2Qze1UpJCZx7ASHl2IZ4UD0G3Qr3pI6/jvNlaqCTa3U > 3/YeJwEubFsd0AVy0zs809RcKKgX3W1q+hVDTeWinem9RiOG/vT+Eec/ABEB > AAHNI2tpbm9zaGl0YSA8a2lub3NoaXRham9uYUBnbWFpbC5jb20+wsByBBAB > CAAmBQJU5ifRBgsJCAcDAgkQRB9iZ30dlisEFQgCCgMWAgECGwMCHgEAAC6Z > B/9otobf0ASHYdlUBeIPXdDopyjQhR2RiZGYaS0VZ5zzHYLDDMW6ZIYm5CjO > Fc09ETLGKFxH2RcCOK2dzwz+KRU4xqOrt/l5gyd50cFE1nOhUN9+/XaPgrou > WhyT9xLeGit7Xqhht93z2+VanTtJAG6lWbAZLIZAMGMuLX6sJDCO0GiO5zxa > 02Q2D3kh5GL57A5+oVOna12JBRaIA5eBGKVCp3KToT/z48pxBe3WAmLo0zXr > hEgTSzssfb2zTwtB3Ogoedj+cU2bHJvJ8upS/jMr3TcdguySmxJlGpocVC/e > qxq12Njv+LiETOrD8atGmXCnA+nFNljBkz+l6ADl93jHzsBNBFTmJ9EBCACu > Qq9ZnP+aLU/Rt6clAfiHfTFBsJvLKsdIKeE6qHzsU1E7A7bGQKTtLEnhCCQE > W+OQP+sgbOWowIdH9PpwLJ3Op+NhvLlMxRvbT36LwCmBL0yD7bMqxxmmVj8n > vlMMRSe4wDSIG19Oy7701imnHZPm/pnPlneg/Meu/UffpcDWYBbAFX8nrXPY > vkVULcI/qTcCxW/+S9fwoXjQhWHaiJJ6y3cYOSitN31W9zgcMvLwLX3JgDxE > flkwq/M+ZkfCYnS3GAPEt8GkVKy2eHtCJuNkGFlCAmKMX0yWzHRAkqOMN5KP > LFbkKY2GQl13ztWp82QYJZpj5af6dmyUosurn6AZABEBAAHCwF8EGAEIABMF > AlTmJ9QJEEQfYmd9HZYrAhsMAABKbgf/Ulu5JAk4fXgH0DtkMmdkFiKEFdkW > 0Wkw7Vhd5eZ4NzeP9kOkD01OGweT9hqzwhfT2CNXCGxh4UnvEM1ZMFypIKdq > 0XpLLJMrDOQO021UjAa56vHZPAVmAM01z5VzHJ7ekjgwrgMLmVkm0jWKEKaO > n/MW7CyphG7QcZ6cJX2f6uJcekBlZRw9TNYRnojMjkutlOVhYJ3J78nc/k0p > kcgV63GB6D7wHRF4TVe4xIBqKpbBhhN+ISwFN1z+gx3lfyRMSmiTSrGdKEQe > XSIQKG8XZQZUDhLNkqPS+7EMV1g7+lOfT4GhLL68dUXDa1e9YxGH6zkpVECw > Spe3vsHZr6CqFg== > =/vUJ > -END PGP PUBLIC KEY BLOCK- > > -- > Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server > from Actuate! Instantly Supercharge Your Business Reports and Dashboards > with Interactivity, Sharing, Native Excel Exports, App Integration & more > Get technology previously reserved for billion-dollar corporations, FREE > http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk > ___ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Request for a new BIP number (and discussion): Improved HD wallet generation.
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 secure. If some of my pseudo code / English is off I apologize, I am not good with words. If this is deemed worthy enough to be drafted into a BIP, I would appreciate if someone could tell me what the overall step by step flow would be. Thank you, I will paste the link to the proposal below. Jona https://gist.github.com/dabura667/875bb2c159b219c18885 -- -BEGIN PGP PUBLIC KEY BLOCK- Comment: http://openpgpjs.org xsBNBFTmJ8oBB/9rd+7XLxZG/x/KnhkVK2WBG8ySx91fs+qQfHIK1JrakSV3 x6x0cK3XLClASLLDomm7Od3Q/fMFzdwCEqj6z60T8wgKxsjWYSGL3mq8ucdv iBjC3wGauk5dQKtT7tkCFyQQbX/uMsBM4ccGBICoDmIJlwJIj7fAZVqGxGOM bO1RhYb4dbQA2qxYP7wSsHJ6/ZNAXyEphOj6blUzdqO0exAbCOZWWF+E/1SC EuKO4RmL7Imdep7uc2Qze1UpJCZx7ASHl2IZ4UD0G3Qr3pI6/jvNlaqCTa3U 3/YeJwEubFsd0AVy0zs809RcKKgX3W1q+hVDTeWinem9RiOG/vT+Eec/ABEB AAHNI2tpbm9zaGl0YSA8a2lub3NoaXRham9uYUBnbWFpbC5jb20+wsByBBAB CAAmBQJU5ifRBgsJCAcDAgkQRB9iZ30dlisEFQgCCgMWAgECGwMCHgEAAC6Z B/9otobf0ASHYdlUBeIPXdDopyjQhR2RiZGYaS0VZ5zzHYLDDMW6ZIYm5CjO Fc09ETLGKFxH2RcCOK2dzwz+KRU4xqOrt/l5gyd50cFE1nOhUN9+/XaPgrou WhyT9xLeGit7Xqhht93z2+VanTtJAG6lWbAZLIZAMGMuLX6sJDCO0GiO5zxa 02Q2D3kh5GL57A5+oVOna12JBRaIA5eBGKVCp3KToT/z48pxBe3WAmLo0zXr hEgTSzssfb2zTwtB3Ogoedj+cU2bHJvJ8upS/jMr3TcdguySmxJlGpocVC/e qxq12Njv+LiETOrD8atGmXCnA+nFNljBkz+l6ADl93jHzsBNBFTmJ9EBCACu Qq9ZnP+aLU/Rt6clAfiHfTFBsJvLKsdIKeE6qHzsU1E7A7bGQKTtLEnhCCQE W+OQP+sgbOWowIdH9PpwLJ3Op+NhvLlMxRvbT36LwCmBL0yD7bMqxxmmVj8n vlMMRSe4wDSIG19Oy7701imnHZPm/pnPlneg/Meu/UffpcDWYBbAFX8nrXPY vkVULcI/qTcCxW/+S9fwoXjQhWHaiJJ6y3cYOSitN31W9zgcMvLwLX3JgDxE flkwq/M+ZkfCYnS3GAPEt8GkVKy2eHtCJuNkGFlCAmKMX0yWzHRAkqOMN5KP LFbkKY2GQl13ztWp82QYJZpj5af6dmyUosurn6AZABEBAAHCwF8EGAEIABMF AlTmJ9QJEEQfYmd9HZYrAhsMAABKbgf/Ulu5JAk4fXgH0DtkMmdkFiKEFdkW 0Wkw7Vhd5eZ4NzeP9kOkD01OGweT9hqzwhfT2CNXCGxh4UnvEM1ZMFypIKdq 0XpLLJMrDOQO021UjAa56vHZPAVmAM01z5VzHJ7ekjgwrgMLmVkm0jWKEKaO n/MW7CyphG7QcZ6cJX2f6uJcekBlZRw9TNYRnojMjkutlOVhYJ3J78nc/k0p kcgV63GB6D7wHRF4TVe4xIBqKpbBhhN+ISwFN1z+gx3lfyRMSmiTSrGdKEQe XSIQKG8XZQZUDhLNkqPS+7EMV1g7+lOfT4GhLL68dUXDa1e9YxGH6zkpVECw Spe3vsHZr6CqFg== =/vUJ -END PGP PUBLIC KEY BLOCK- -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
