Re: [Bitcoin-development] unlinakble static address? & spv-privacy (Re: Stealth Addresses)
On Mon, Jan 20, 2014 at 08:00:05PM -0800, Jeremy Spilman wrote: > Let's say the payee's reusable address is ' > ...', where is 2 bytes. Without any length indicator. What's the > payer going to put on the blockchain? How would they know what the 'rest > of the space' is? They would have to put the whole verbatim into > the OP_RETURN without knowing how many bits of the payee actually > wants to see there. > > If instead, the address is ' ...' > where is 2 bytes, and is 1 byte, representing number > of bits of prefix that should be fixed. > > Then payer will know how much of from the address should be taken > verbatim, and the rest of the two bytes would be replaced with random > data, and exactly two bytes would be put in the OP_RETURN. > > If was zero, the 2 byte prefix in the reusable address must be > ignored, and an entirely random 2 byte prefix would be put into the > OP_RETURN. > > I'm a bit worried about broken implementations copying the from > the reusable address into OP_RETURN when is 0, and ending up > basically identifying the payee. That's the only reason I can think of to > make ' ' optional in the reusable address, to prevent > the opportunity to screw it up. You would *still* put a 2-byte random > prefix in the OP_RETURN, even if the fields weren't in the address at all. > It's just a minor concern though. Something to keep in mind is that it's quite likely that the indexes available will be over H(scriptPubKey). There's really good engineering reasons for doing this: you need to be able to create succinct proofs of fraud in indexes, miner committed and otherwise, and the only way they are succinct is if you limit the length. Hashes naturally do that because it's so expensive to generate partial collisions. If you don't do this on the other hand now you have a situation where the usual case - max 16 level deep tree - and worst case - hundreds or even thousands of levels deep - are vastly different. That's hard to test for and likely to reveal implementation-specific limits in nasty ways. Anyway, grinding nonces isn't much of a burden given it's fast hash functions. The prefixes in question are fairly small and will be small for the forseeable future. As I said elsewhere in this thread, even Javascript has performance that's perfectly adequate for the task. -- 'peter'[:-1]@petertodd.org 3590a8a20ec9ff5b1c1af3f046a1f62dc1ac9a464721fd8f signature.asc Description: Digital signature -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments & Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] unlinakble static address? & spv-privacy (Re: Stealth Addresses)
On Wed, 15 Jan 2014 17:32:31 -0800, Gregory Maxwell wrote: > I'd point out that regardless of how long the desired prefix is, the > encoded prefix should probably always be constant length in all > reusable addresses. I might be misunderstanding, but I think prefix length must be specified in the reusable address, however I agree the prefix actually published to the blockchain should be constant length. > If you don't want a particular prefix then the > sender should just pick random data for the rest of the space. There > is no need to publish any additional distinguishing data in the form > of how long the prefix is. Let's say the payee's reusable address is ' ...', where is 2 bytes. Without any length indicator. What's the payer going to put on the blockchain? How would they know what the 'rest of the space' is? They would have to put the whole verbatim into the OP_RETURN without knowing how many bits of the payee actually wants to see there. If instead, the address is ' ...' where is 2 bytes, and is 1 byte, representing number of bits of prefix that should be fixed. Then payer will know how much of from the address should be taken verbatim, and the rest of the two bytes would be replaced with random data, and exactly two bytes would be put in the OP_RETURN. If was zero, the 2 byte prefix in the reusable address must be ignored, and an entirely random 2 byte prefix would be put into the OP_RETURN. I'm a bit worried about broken implementations copying the from the reusable address into OP_RETURN when is 0, and ending up basically identifying the payee. That's the only reason I can think of to make ' ' optional in the reusable address, to prevent the opportunity to screw it up. You would *still* put a 2-byte random prefix in the OP_RETURN, even if the fields weren't in the address at all. It's just a minor concern though. -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments & Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] unlinakble static address? & spv-privacy (Re: Stealth Addresses)
On Sat, Jan 18, 2014 at 11:44:52AM -0600, Troy Benjegerdes wrote: > > Ignoring prefixes the cost for each reusable address is only a small > > percentage of the full node cost (rational: each transaction has one > > or more ECDSA signatures, and the derivation is no more expensive), so > > I would only expect computation to be an issue for large centralized > > services. (non-full nodes suffer more from just the bandwidth impact). > > I have not seen anyone address my high-level question to (somewhat) > complicated > mechanisms to keep coin flows private. > > Who pays for it? From what I see it's going to double the amount of data > needed per address, further centralizing 'full' nodes. I'm fine if the NSA Actually the exact encoding is still undetermined - other encodings I proposed in my original paper are the same size or even smaller than a standard transaction. -- 'peter'[:-1]@petertodd.org 000190a2900f1a25c507a999fa6f7bd0126618c1ebc4f5fb signature.asc Description: Digital signature -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments & Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] unlinakble static address? & spv-privacy (Re: Stealth Addresses)
Like any other mechanism that puts extra data in the blockchain, the sender pays the fees. This mechanism is to improve privacy for static addresses (donation links on websites and so on). I personally don't think it will be used nearly as much as BIP0032 or the payment protocol (both of which don't need on-blockchain data), precisely because it increases the fees required to send funds, but this doesn't externalize costs anymore than any other use of the blockchain does. People who don't care about privacy and want smallest cost and maximum convenience already use SPV nodes. Their resource usage will not be affected in the least. On Sat, Jan 18, 2014 at 12:44 PM, Troy Benjegerdes wrote: > On Wed, Jan 15, 2014 at 05:32:31PM -0800, Gregory Maxwell wrote: >> On Wed, Jan 15, 2014 at 5:02 PM, Jeremy Spilman wrote: >> > Choosing how many bits to put in the prefix may be difficult, particularly >> > if transaction load changes dramatically over time. 0 or 1 bits may be >> > just fine for a single user running their own node, whereas a central >> > service might want 4 or 5 bits to keep their computation costs scalable. >> >> Ignoring prefixes the cost for each reusable address is only a small >> percentage of the full node cost (rational: each transaction has one >> or more ECDSA signatures, and the derivation is no more expensive), so >> I would only expect computation to be an issue for large centralized >> services. (non-full nodes suffer more from just the bandwidth impact). > > I have not seen anyone address my high-level question to (somewhat) > complicated > mechanisms to keep coin flows private. > > Who pays for it? From what I see it's going to double the amount of data > needed per address, further centralizing 'full' nodes. I'm fine if the NSA > is paying for privacy (I actually trust them more than banks and advertisers), > but let's just be honest, okay? > > If socializing the cost of privacy is Bitcoin's goal, and giving the benefits > to a few that understand it and/or have the resources to determine privacy > providers that won't scam them, then say so, so I can get on with launching > a 'transparencycoin' with a modified code that explicitly ALWAYS re-uses > addresses, and has miners and pools that charge more for addresses they have > never seen before. I bet it will be more distributed and have about half the > average transaction cost of Bitcoin, because most people *just don't care* > about privacy if they get cheap and/or free services. > > > -- Troy, transparency advocate who is quite transparent that if you buy me > farmland, I'll shut up about transparency, because I'll be too busy growing > food and giving part of it away. > > -- > CenturyLink Cloud: The Leader in Enterprise Cloud Services. > Learn Why More Businesses Are Choosing CenturyLink Cloud For > Critical Workloads, Development Environments & Everything In Between. > Get a Quote or Start a Free Trial Today. > http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk > ___ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments & Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] unlinakble static address? & spv-privacy (Re: Stealth Addresses)
On Wed, Jan 15, 2014 at 05:32:31PM -0800, Gregory Maxwell wrote: > On Wed, Jan 15, 2014 at 5:02 PM, Jeremy Spilman wrote: > > Choosing how many bits to put in the prefix may be difficult, particularly > > if transaction load changes dramatically over time. 0 or 1 bits may be > > just fine for a single user running their own node, whereas a central > > service might want 4 or 5 bits to keep their computation costs scalable. > > Ignoring prefixes the cost for each reusable address is only a small > percentage of the full node cost (rational: each transaction has one > or more ECDSA signatures, and the derivation is no more expensive), so > I would only expect computation to be an issue for large centralized > services. (non-full nodes suffer more from just the bandwidth impact). I have not seen anyone address my high-level question to (somewhat) complicated mechanisms to keep coin flows private. Who pays for it? From what I see it's going to double the amount of data needed per address, further centralizing 'full' nodes. I'm fine if the NSA is paying for privacy (I actually trust them more than banks and advertisers), but let's just be honest, okay? If socializing the cost of privacy is Bitcoin's goal, and giving the benefits to a few that understand it and/or have the resources to determine privacy providers that won't scam them, then say so, so I can get on with launching a 'transparencycoin' with a modified code that explicitly ALWAYS re-uses addresses, and has miners and pools that charge more for addresses they have never seen before. I bet it will be more distributed and have about half the average transaction cost of Bitcoin, because most people *just don't care* about privacy if they get cheap and/or free services. -- Troy, transparency advocate who is quite transparent that if you buy me farmland, I'll shut up about transparency, because I'll be too busy growing food and giving part of it away. -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments & Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] unlinakble static address? & spv-privacy (Re: Stealth Addresses)
> >But I think it's great people can choose how to trade privacy for > >computation/bandwidth however they want, and services can compete to > >offer monitoring for 0+ bit prefixes. > > Its not a decision with user localised effect. If most users use it with > parameters giving high elimination probability, that affects everyone else's > privacy also. Also statistical effects are accumulative as more plausibly > related addresses are eliminated at each potentially linked transaction. I > think once the network flow analysis guys are done with incorporating it, > and if reusable addresses saw significant use, my prediction is the result > will be pretty close to privacy game over and it will undo most if not all > of the hard-won privacy benefit of CoinJoin. (Recalling CoinJoin is only > adding a bit or two of entropy per join, this elimination effect could > easily undo more than that). You've got a major social engineering problem here. 1) who is marketing privacy 2) how do you validate 'privacy providers' Just like all the scamcoins, there will be scamprivacy providers, which will drive the market price of privacy down to zero. Who's paying the network/development/bandwidth/etc cost for privacy? I'd guess 85% of real users don't really care about some abstract 'privacy' ideal, they just want payments to work and to download cat pictures. If you say 'regular address re-use is deprecated, and the top 1% in bitcoin weatlh who own 95% of the miners want privacy', well fine. But you just opened yourself up to 'OccupyBitcoin', and an altcoin that ENCOURAGES plain old regular address re-use and transparency. Does this stuff still work if regular address re-use is a transparency feature and not a bug? -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments & Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] unlinakble static address? & spv-privacy (Re: Stealth Addresses)
On Wed, Jan 15, 2014 at 05:02:10PM -0800, Jeremy Spilman wrote: >The second pubKey is useful [...] even just being able to scan for >transactions yourself without keeping bitcoin-encumbered private keys >decrypted in memory. Agreed. >On Wed, 15 Jan 2014 15:09:01 -0800, Adam Back wrote: >>But I think its moderately expensive for the full node because it has to >>do a DH calculation per transaction and its not precomputable so there is >>IO per query. (In the P version in fact only payments which are thereby >>reconizable as unlinkable static need to be processed). > >And of course, if you have multiple reuseable addresses, then you're >doing this calculation separately to check each one. > >So the load on a popular centralized service would be quite high, >which you may consider a feature. Well only a linear increase, which is not any kind of realistic security defense for even an academic researcher analysing flows. More concern is that it could be expensive enough discourage adoption by full-nodes as an open/free service to support SPV clients in finding their reusable address payments. Its possibly an I/O DoS multiplier: send requests to the full nodes at a moderate network rate and and watch as its disk thrashes. >But I think it's great people can choose how to trade privacy for >computation/bandwidth however they want, and services can compete to >offer monitoring for 0+ bit prefixes. Its not a decision with user localised effect. If most users use it with parameters giving high elimination probability, that affects everyone else's privacy also. Also statistical effects are accumulative as more plausibly related addresses are eliminated at each potentially linked transaction. I think once the network flow analysis guys are done with incorporating it, and if reusable addresses saw significant use, my prediction is the result will be pretty close to privacy game over and it will undo most if not all of the hard-won privacy benefit of CoinJoin. (Recalling CoinJoin is only adding a bit or two of entropy per join, this elimination effect could easily undo more than that). >>(And also there is proposed a version of the prefix computed via >>brute-force to make it somewhat stealthy still). > >I think in this case the hash grinding of the prefix would only being >used if thats how transactions are being indexed. I don't think it >adds any privacy, it's just added work we're forced to do in order >for the prefix to work as designed. The point of the stealth security objective is to avoid creating a new and smaller anonymity set. If all reusable addresses are easily recognizable as reusable, thats far more revealing and useful to the network flow analysis. Adam -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments & Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] unlinakble static address? & spv-privacy (Re: Stealth Addresses)
On Wed, Jan 15, 2014 at 5:02 PM, Jeremy Spilman wrote: > Choosing how many bits to put in the prefix may be difficult, particularly > if transaction load changes dramatically over time. 0 or 1 bits may be > just fine for a single user running their own node, whereas a central > service might want 4 or 5 bits to keep their computation costs scalable. Ignoring prefixes the cost for each reusable address is only a small percentage of the full node cost (rational: each transaction has one or more ECDSA signatures, and the derivation is no more expensive), so I would only expect computation to be an issue for large centralized services. (non-full nodes suffer more from just the bandwidth impact). I'd point out that regardless of how long the desired prefix is, the encoded prefix should probably always be constant length in all reusable addresses. If you don't want a particular prefix then the sender should just pick random data for the rest of the space. There is no need to publish any additional distinguishing data in the form of how long the prefix is. -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments & Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] unlinakble static address? & spv-privacy (Re: Stealth Addresses)
On Wed, 15 Jan 2014 15:09:01 -0800, Adam Back wrote: > I was meaning to comment on the SPV privacy properties. > > For full-node use these unlinkable static addresses have quite nice > properties. It also nicely solves the problem of having to educate users > and wallet authors to not reuse addresses. But for SPV nodes they have > no direct-way to find the payments. So then in Peter Todd's variant > (maybe it was suggested by Greg Maxwell?) there is a second address so > that the SPV > client can delegate detection to a full node without giving it the > private key allowing it to spend! (This is something analogous to bloom > filtering). The second pubKey is useful for delegating scanning, or even just being able to scan for transactions yourself without keeping bitcoin-encumbered private keys decrypted in memory. So even while running your own full node there are good reasons to use a second pubKey to derive the shared secret. > But I think its moderately expensive for the full node because it has to > do a DH calculation per transaction and its not precomputable so there > is IO > per query. (In the P version in fact only payments which are thereby > reconizable as unlinkable static need to be processed). And of course, if you have multiple reuseable addresses, then you're doing this calculation separately to check each one. So the load on a popular centralized service would be quite high, which you may consider a feature. > > Then an artificial prefix is proposed to constrain the query to a subset, > however that leaks to everyone so in some ways its a worse privacy leak > than bloom filtering. It can be used to rule out recipients and could be > quite a powerful extra lever for statistical analysis. Choosing how many bits to put in the prefix may be difficult, particularly if transaction load changes dramatically over time. 0 or 1 bits may be just fine for a single user running their own node, whereas a central service might want 4 or 5 bits to keep their computation costs scalable. But I think it's great people can choose how to trade privacy for computation/bandwidth however they want, and services can compete to offer monitoring for 0+ bit prefixes. > (And also there is proposed a version of the prefix computed via > brute-force to make it somewhat stealthy still). I think in this case the hash grinding of the prefix would only being used if thats how transactions are being indexed. I don't think it adds any privacy, it's just added work we're forced to do in order for the prefix to work as designed. Peter, please correct me if I'm wrong. > > Maybe in the payment address case the service should choose the > derivation factor and communicate it and the client with the static > address, as suggested by Alan Reiner because then it can also serve > the function of allowing the service to tie the payment to the users > account. I think any change which requires more than a single published public message (e.g. a posting in a forum, or in a README.me in Github) should be seen as solving an entirely different problem. If you have directed communication from payee->payer, I think there's simply no reason to do it this way. (By "this way" I mean ECDH with OP_RETURN P). We could try to define a different reusable address type, for when you can make a single directed message from payer->payee, and in that case there's probably no need for ECDH or the prefix, like Alan's proposal. But once you admit having that directed communication, then you are swimming very close to the payment protocol. -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments & Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] unlinakble static address? & spv-privacy (Re: Stealth Addresses)
So I like static address name too. In the write up for my variant I called it something less sexy than stealth "unlinkable public address": https://bitcointalk.org/index.php?topic=317835.msg4103530#msg4103530 (there are 3 variants that are approximately the same thing). Maybe we could call it an unlinkable static address. Otherwise static addresses are maybe too synonymous with reused addresses a bad practice we have been complaining about users and wallet authors incorrectly doing. But to explain, in Peter Todds (and Amir Taaki also?) variant stealth refers to an actual useful security criteria. Stealth objective actually means "looks like a normal bitcoin payment to the outside observer". You generally want that to be the case for fungibility reasons. Its like browser cookie state, the more things that are unusual about your transaction, the more your transactions identify you in the public block-chain. Statistics are cumulative so it matters. And is an actual element of stealthiness (hence the name) in this variant that Peter Todd proposed, at least as an objective, though I think the stealthiness somewhat fails because the P parameter is extra and not present in a normal transaction. Unfortunately so far removing P and using an input in its stead breaks CoinJoin which is also necessary for fungibility. Maybe there is another way to make an extended CoinJoin that can mix inputs and unlinkable static addresses. I was meaning to comment on the SPV privacy properties. For full-node use these unlinkable static addresses have quite nice properties. It also nicely solves the problem of having to educate users and wallet authors to not reuse addresses. But for SPV nodes they have no direct-way to find the payments. So then in Peter Todd's variant (maybe it was suggested by Greg Maxwell?) there is a second address so that the SPV client can delegate detection to a full node without giving it the private key allowing it to spend! (This is something analogous to bloom filtering). But I think its moderately expensive for the full node because it has to do a DH calculation per transaction and its not precomputable so there is IO per query. (In the P version in fact only payments which are thereby reconizable as unlinkable static need to be processed). Then an artificial prefix is proposed to constrain the query to a subset, however that leaks to everyone so in some wayts its a worse privacy leak than bloom filtering. It can be used to rule out recipients and could be quite a powerful extra lever for statistical analysis. (And also there is proposed a version of the prefix computed via brute-force to make it somewhat stealthy still). So I also am quite enthusiastic about the possiblity to fix this address reuse problem, but there remain a few open problems in my view, for SPV uses. Not nay-saying, I spent quite a bit of time trying to solve this for my variant, its a tricky problem, or basically we wouldnt have one-use addresses and bloom filtering. But maybe its intereting enough already for full-node uses. Many processors and businesses are full nodes. Many power users run full-nodes The data isnt lost, you just need to scan a full-node. It could help the related problem of paying the wrong person. Ie deposit address given by merchant. If the deposit address is static, and the used address user derived from it, then that itself is an assurance to the user that they are paying an address at least owned by the service. (As opposed to someone who hacked the web site or MITM the link). Of course for users probably the main likelihood is they have malware on their machine, but that is what offline wallets are for. A smartphone is maybe a little less hackable and could be trained to store the static address and warn if its not the same as the last time they used the site. (TOFU for bitcoin addresses, or at least be able to call someone you know who also uses the service and compare static addresses). Maybe in the payment address case the service should choose the derivation factor and communicate it and the client with the static address, as suggeste by Alan Reiner because then it can also serve the function of allowing the service to tie the payment to the users account. People also mention payment protocol for certifying addresses however I think it is useful to have address level TOFU / static to principal verification because it is simpler for harware wallets, maps to account number concept users understand, and doesnt rely on the CA infrastructure. Also the typical payment protcol is talking about a message constructed by a web app. Thats millions of lines of web server, script language, db code etc in play on an online server. The static address private key would be airgapped from that mess. Mike Hearn proposed if I understand that you could something analogous and upload in batches signed payment protocol sub-messages from a different CA certificate key. But I thi
