Re: [Bitcoin-development] Bait for reusable addresses
I've thought about [ab]using Tor as a STUN replacement before, but the issue is a lot of people don't have computers that are switched on all the time anymore except for their smartphones, which are too weak to calculate the UTXO set. The trend has been for a while towards laptops, phones and tablets, all of which are relatively weak. I think there might be a market for a one-click "bring up an amazon VPS, sync a full node and make it accessible only to me" type service though! On Fri, Jan 24, 2014 at 10:58 PM, Jeremy Spilman wrote: > > > > > > > > I think we need to provide users with better options than that. > > > > Perfect privacy without extraordinary computational overhead today means > downloading everything. But we could provide better tools to *shift* > bandwidth requirements rather than try to reduce them. > > I've been thinking about a setup where user runs a UTXO only, and maybe > even outbound-connect only (like bitcoinj), full node at home. Then using > Tor, mostly for tunneling, they host a hidden service they can connect back > to from their smartphone to see balances, manage receive addresses, send > funds, etc. > > The smartphone is not doing SPV, it's like a web client for the wallet > running at home. The initial connection between the smartphone and home > wallet has the phone learn two codes, one is the hidden service name, > another is an access token which is revocable. You may require further > authentication from that point. > > With fast bootstrapping / checkpointing of the UTXO I think usability > could be as good as SPV, and you would get push-notification of relevant > transactions with zero privacy trade-off. > > I wonder if people would want to run such an app, if they would run it on > their desktop, a dedicated machine, or an old smartphone or other cheap ARM > device. > -- 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] Bait for reusable addresses
> > > > I think we need to provide users with better options than that. > Perfect privacy without extraordinary computational overhead today means downloading everything. But we could provide better tools to *shift* bandwidth requirements rather than try to reduce them. I've been thinking about a setup where user runs a UTXO only, and maybe even outbound-connect only (like bitcoinj), full node at home. Then using Tor, mostly for tunneling, they host a hidden service they can connect back to from their smartphone to see balances, manage receive addresses, send funds, etc. The smartphone is not doing SPV, it's like a web client for the wallet running at home. The initial connection between the smartphone and home wallet has the phone learn two codes, one is the hidden service name, another is an access token which is revocable. You may require further authentication from that point. With fast bootstrapping / checkpointing of the UTXO I think usability could be as good as SPV, and you would get push-notification of relevant transactions with zero privacy trade-off. I wonder if people would want to run such an app, if they would run it on their desktop, a dedicated machine, or an old smartphone or other cheap ARM device. -- 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] BIP0039: Final call
Le 24/01/2014 10:05, Peter Todd a écrit : > On Tue, Jan 21, 2014 at 01:00:43AM +0100, Thomas Voegtlin wrote: >> Hi slush, >> >> Thank you for your new proposal; it seems to be a compromise. >> >> @Christophe Biocca: >> If the wordlist becomes part of the standard, then we will run into >> problems of collisions once users ask for wordlists in every language. >> >> IMO the right approach is to implement checksums that do not depend >> on the wordlist (eg the 'brute force' method, Hash(mnemonic||1) mod >> 2^k == 0 ) >> this would also allow us to implement sipa's variable stretching proposal. >> >> I understand this is not possible because of the computational >> requirements of devices such as trezor. > Is it? Surely the trezor can bruteforce, say, 8 bits == 0. How many > SHA256/sec can the trezor hardware do? Generating your seed is a > one-time thing after all - that taking 10-30s doesn't seem like a big > deal to me. > > Even a 1/256th "checksum" will really cut down on the number of mistakes > made and money lost. slush, correct me if I'm wrong, but I don't think that's the only reason: They want to generate a seed by combining entropy from the trezor device and from the user's computer; In addition, they want the computer to be able to check that the seed actually was derived from the entropy it provided, using only a master public key (the computer does not have access to the seed) This is why they designed bip39 that way. I think the new bip39 proposal could be used in Electrum as an option for trezor, but I am reluctant to make it default, because it imposes its own dictionary. -- 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] Bait for reusable addresses
On Fri, Jan 24, 2014 at 04:42:35PM +0100, Adam Back wrote: > I think prefix has analysis side effects. There are (at least) 4 things > that link payments: the graph of payment flows, timing, precise amounts, IP > addresses, but with prefix a 5th: the prefix allows public elmination of > candidates connections, I think that may make network flow analysis even > more effective than it has been. You know, we've made this discussion rather confusing because we're using the term "prefix" for both prefix filters - which are equivalent to bloom filters but with better scalability - and the act of forcing a scriptPubKey to match some given prefix. I suggest we call the latter concept 'wallet clustering' as it can just as easily be applied to bloom filters, as well as Gregory Maxwell's candidate bait scheme, and for that matter, prefix filters with a tweak option, e.g. H(scriptPubKey | nTweak) So yeah, clustering schemes make network flow analysis easier if the attacker only has blockchain data to work from. But they can also make network flow analysis significantly harder for attackers that have query logs from attackers running nodes, and as we know sybiling the network to get query logs is very easy. I'd rather develop systems that don't fail catastrophically against sybil attack. > So SPV can be tuned as Mike just said, and as Greg pointed out somewhere > bloom is more private than prefix because its a wallet to node connection, > not a node broadcast, and Mike mentioned embedded Tor in another post to > boost node-capture issues with hostile network. The hostile network is likely to have a significant percentage of hostile, query-logging nodes. For one thing, running nodes is expensive and would be even more so in a blocksize limit raising scenario, and a easy way to pay those costs is by selling query data. > So reusable addresses are cool for full node recipients (0-bit prefix) or > trusted server offload (your own desktop, VPS, or trusted service provider > node, and solve real problems for the use case of static and donation > addresses particularly with this second delegatable key for no-funds at risk > search (which is even good as Jeremey said for your own node, in a offline > wallet use case). Sure, in some cases you can use zero-length prefixes with trusted nodes; not many users have access to such nodes. > Now while it would be clearly a very nice win if reusable addresses could be > made SPV-like in network characteristics and privacy, but we dont have a > plausible mechanism yet IMO. Close as we got was Greg's enhancement of > my/your "bloom bait"/"prefix" concept to make multiple candidate baits to > provide some ambiguity (still allows elimination, just slightly less of it). > > If we can find some efficient crypto to solve that last one, we could even > adopt them generally if it was efficient enough without needing interactive > one-use address release. Conversely, it'd be interesting if someone can dig up a proof showing that doing much better than Gregory's ambiguity tradeoff is impossible. My gut feeling is that it is, especially if you take into account the desire for scalability - if we're to make the blocksize bigger assuming all nodes have all data for every block just isn't going to happen. > Maybe we should ask some math/theoretical crypto people if there is anything > like public key watermarking or something that could solve this problem > efficiently. Yes, and I think such schemes should be pursued. But in the near-term what can we offer users? Remember that making stealth addresses and similar clustering-using schemes capable of backward compatible upgrades isn't hard; if the crypto is found later it can be adopted. What is harder is that people want miners to commit to various types of indexes - changing those indexes would require a soft-fork and there's much pressure for those indexes to have very good performance properties. > For the related but different case of transaction level authenticity I like > Alan's server derived but communicated scalar & base to allow the client to > do at least TOFU. > > Payment protocol may add another level of identity framework on top of TOFU > addresses (at a lower level than the payment messages defined now), and > without then needing a batch upload of offline signed secondary address > sigature that Mike described a while back, at least in person, maybe online > somewhere (an add on with similar purpose and effect to Alan's TOFU, but > then with revocation, identity and certification for merchants). Note how well the OpenPGP + bitcoin address UID ideas I and others have been talking about meshes with TOFU: the logic for "Do I trust this address to send money?" and "Do I trust this PGP key to send more encrypted mail/verify signatures?" is just different questions about the same human identity, so combining the two is synergistic. For instance I might want to communicate securely with a friend via email and also send funds
Re: [Bitcoin-development] Bait for reusable addresses
I think prefix has analysis side effects. There are (at least) 4 things that link payments: the graph of payment flows, timing, precise amounts, IP addresses, but with prefix a 5th: the prefix allows public elmination of candidates connections, I think that may make network flow analysis even more effective than it has been. So SPV can be tuned as Mike just said, and as Greg pointed out somewhere bloom is more private than prefix because its a wallet to node connection, not a node broadcast, and Mike mentioned embedded Tor in another post to boost node-capture issues with hostile network. So reusable addresses are cool for full node recipients (0-bit prefix) or trusted server offload (your own desktop, VPS, or trusted service provider node, and solve real problems for the use case of static and donation addresses particularly with this second delegatable key for no-funds at risk search (which is even good as Jeremey said for your own node, in a offline wallet use case). Now while it would be clearly a very nice win if reusable addresses could be made SPV-like in network characteristics and privacy, but we dont have a plausible mechanism yet IMO. Close as we got was Greg's enhancement of my/your "bloom bait"/"prefix" concept to make multiple candidate baits to provide some ambiguity (still allows elimination, just slightly less of it). If we can find some efficient crypto to solve that last one, we could even adopt them generally if it was efficient enough without needing interactive one-use address release. Maybe we should ask some math/theoretical crypto people if there is anything like public key watermarking or something that could solve this problem efficiently. For the related but different case of transaction level authenticity I like Alan's server derived but communicated scalar & base to allow the client to do at least TOFU. Payment protocol may add another level of identity framework on top of TOFU addresses (at a lower level than the payment messages defined now), and without then needing a batch upload of offline signed secondary address sigature that Mike described a while back, at least in person, maybe online somewhere (an add on with similar purpose and effect to Alan's TOFU, but then with revocation, identity and certification for merchants). I have not talked about payment protocols main app level function I think we all understand and agree on the purpose and use of the server and optional client certs in that. People may wish to add other cert types later (eg PGP, SSH etc) but this version covers the common merchant tech, and allows client-side certs to be experimented with for identity also (eg imagine as a way to enrol with regulated entities like exchanges.) Tell me if I am misunderstanding anything :) Adam On Fri, Jan 24, 2014 at 12:26:19PM +, Mike Hearn wrote: > brittleness. The real world experience is that users, or to be exact > wallet authors, turn down SPV privacy parameters until bloom filters > have almost no privacy in exchange for little bandwidth usage. > > That's not fundamental though, it just reflects that the only > implementation of this is used on a wide range of devices and doesn't > yet have any notion of bandwidth modes or monitoring. It can and will > be resolved at some point. -- 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] Bait for reusable addresses
On Fri, Jan 24, 2014 at 12:26:19PM +, Mike Hearn wrote: > > > > brittleness. The real world experience is that users, or to be exact > > wallet authors, turn down SPV privacy parameters until bloom filters > > have almost no privacy in exchange for little bandwidth usage. > > > That's not fundamental though, it just reflects that the only > implementation of this is used on a wide range of devices and doesn't yet > have any notion of bandwidth modes or monitoring. It can and will be > resolved at some point. Resolved for some users, not for all. The underlying trade-off will always be there; less bandwidth makes it harder, more addresses to check makes it harder; an HD wallet used properly without re-using addresses will quickly lead to a fairly full bloom filter unless addresses are expired, and expiration leads to scenarios where funds can be lost. I think we need to provide users with better options than that. -- 'peter'[:-1]@petertodd.org 64ddd387d7548c97c4d42f4df1008d180f306c59e0440f4f 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] Bait for reusable addresses
> > brittleness. The real world experience is that users, or to be exact > wallet authors, turn down SPV privacy parameters until bloom filters > have almost no privacy in exchange for little bandwidth usage. That's not fundamental though, it just reflects that the only implementation of this is used on a wide range of devices and doesn't yet have any notion of bandwidth modes or monitoring. It can and will be resolved at some point. -- 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 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] BIP0039: Final call
On Tue, Jan 21, 2014 at 01:00:43AM +0100, Thomas Voegtlin wrote: > Hi slush, > > Thank you for your new proposal; it seems to be a compromise. > > @Christophe Biocca: > If the wordlist becomes part of the standard, then we will run into > problems of collisions once users ask for wordlists in every language. > > IMO the right approach is to implement checksums that do not depend > on the wordlist (eg the 'brute force' method, Hash(mnemonic||1) mod > 2^k == 0 ) > this would also allow us to implement sipa's variable stretching proposal. > > I understand this is not possible because of the computational > requirements of devices such as trezor. Is it? Surely the trezor can bruteforce, say, 8 bits == 0. How many SHA256/sec can the trezor hardware do? Generating your seed is a one-time thing after all - that taking 10-30s doesn't seem like a big deal to me. Even a 1/256th "checksum" will really cut down on the number of mistakes made and money lost. -- 'peter'[:-1]@petertodd.org 0001d8b9d438c18e856735ddae5b1d918416010350d19794aab6 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] Bait for reusable addresses
On Wed, Jan 15, 2014 at 05:23:04PM -0800, Gregory Maxwell wrote: > It also has a downside of not being indexable for the server, the > server must do O(clients * reusable-address-txn) work and the work > includes an ECC multiply. > > An idea that Adam Back had originally proposed was including optional > "bloom bait", a small token— say 8 bits— that distinguished > transactions which allowed an anonymity set vs filtering trade off. > Such a bait would be indexable, enabling faster lookup too. > > But bloom bait has privacy problems more severe than the current SPV > bloom filtering. While you leak information to your SPV servers today > if you use bloom filtering the leak usually goes no further. So a > compromise requires both a statistical attack _and_ using SPV servers > that log data against your interest. With bloom bait the whole > network can see the relation. That is unfortunate. Yes, but remember I proposed prefixing in my blockchain data query paper because it's a trade-off between theoretical good privacy and brittleness. The real world experience is that users, or to be exact wallet authors, turn down SPV privacy parameters until bloom filters have almost no privacy in exchange for little bandwidth usage. (though load on the server is unchanged of course) The brittleness comes in because the moment you connect to a malicious, data-collecting peer, the contents of your wallet are all revealed. Frankly that'd be a disaster for CoinJoin too, and I think it'd be a bigger disaster than the poor specificity patterns leaked by prefix usage. If anyone wants to deanonymize CoinJoin there will be a lot of incentives to do so, and you only need wallet content data to do that. > I suggest instead that with optional bait is included in an address > that the sender compute H(nonce-pubkey) and then pick one byte at > random out of the first 16 and xor it with the specified bait and > store the result in the transaction. An SPV server can now index the > bait as it comes in by extracting 16 8-bit keys from each transaction > (the 16 bytes xored with the bait in the transaction). When the > client wants to search for transactions it can give the server a list > of keys its interested in— including their real key and number of > random number of cover keys. > > I didn't give any though into the parameters 8-bits and 16 dimensions. > Some reasoning should be done to fix the parameters in order to make > them the most useful: e.g. > > Systems derived from more complex linear codes might give better > performance, e.g. two secret bloom baits, two prefixes in the > transaction bait0^random_char[0-8], bait1^random_char[0-8], server > extracts 16 keys.. and returns to the client transactions which have > at least two key matches with their list. > > Obviously whatever is used needs to be easy to implement, but schemes > loosely based on fountain codes should only require picking some > things and xoring... so they should be simple enough. Well, that's the big question: How much extra data do we need and what's the chance that this will get turned into miner-committed indexes? Or even just provided at all? We keep on saying that miner-commitments may next happen at all because of performance issues, and adding n extra indexes doesn't exactly help that situation. I really suspect that the moment that gets implemented we'll see wallet software use that for simple security reasons, so plan ahead for that. In the short term without miner-commitments it's just a question of how much extra load we subject servers to. Again, getting people to even implement prefixes isn't a trivial argument to make, yet bloom has some serious scalability problems. (though does do roughly what you're proposing) In any case, your "bait" proposal is stealth address specific - how would you propose applying the same principle to all addresses? Again, it's a tradeoff between brittleness - connecting to a malicious peer reveals your wallet - and blockchain stats data. -- 'peter'[:-1]@petertodd.org 0001315c71472fdce344f85f794a7135e25554f2b51dfa6b83c4 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
