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 'version prefix Q1 Q2 ...', where prefix 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 prefix verbatim into the OP_RETURN without knowing how many bits of prefix the payee actually wants to see there. If instead, the address is 'version prefix prefixLen Q1 Q2 ...' where prefix is 2 bytes, and prefixLen is 1 byte, representing number of bits of prefix that should be fixed. Then payer will know how much of prefix 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 prefixLen 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 prefix from the reusable address into OP_RETURN when prefixLen is 0, and ending up basically identifying the payee. That's the only reason I can think of to make 'prefix prefixLen' 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=119420431iu=/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=119420431iu=/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 gmaxw...@gmail.com 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 'version prefix Q1 Q2 ...', where prefix 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 prefix verbatim into the OP_RETURN without knowing how many bits of prefix the payee actually wants to see there. If instead, the address is 'version prefix prefixLen Q1 Q2 ...' where prefix is 2 bytes, and prefixLen is 1 byte, representing number of bits of prefix that should be fixed. Then payer will know how much of prefix 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 prefixLen 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 prefix from the reusable address into OP_RETURN when prefixLen is 0, and ending up basically identifying the payee. That's the only reason I can think of to make 'prefix prefixLen' 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=119420431iu=/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 jer...@taplink.co 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=119420431iu=/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 ho...@hozed.org 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 jer...@taplink.co 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=119420431iu=/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=119420431iu=/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=119420431iu=/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 a...@cypherspace.org 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=119420431iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
