{"type":"rich","version":"1.0","author_name":"npub1nf4hx3yuahf4awyzsdfzh6gelr8ef4d8yqeker5y8sku64k48c7qcgkps5","author_url":"https://nostr.ae/npub1nf4hx3yuahf4awyzsdfzh6gelr8ef4d8yqeker5y8sku64k48c7qcgkps5","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2017-02-24\n📝 Original message:If the 20 byte SHA1 is now considered insecure (with good reason), what about RIPEMD-160 which is the foundation of Bitcoin addresses?\n\nIs that also susceptible to such an attack vector?\n\nWhat does that mean for old addresses?\n\netc\n\n/s\n\n\n\u003e Date: Fri, 24 Feb 2017 11:04:54 +0100\n\u003e From: Tim Ruffing \u003ctim.ruffing at mmci.uni-saarland.de\u003e\n\u003e To: bitcoin-dev at lists.linuxfoundation.org\n\u003e Subject: Re: [bitcoin-dev] SHA1 collisions make Git vulnerable to\n\u003e \tattakcs by third-parties, not just repo maintainers\n\u003e Message-ID: \u003c1487930694.1528.1.camel at mmci.uni-saarland.de\u003e\n\u003e Content-Type: text/plain; charset=\"UTF-8\"\n\u003e \n\u003e On Fri, 2017-02-24 at 00:57 +0100, Aymeric Vitte via bitcoin-dev wrote:\n\u003e\u003e \n\u003e\u003e I have not worked on this since some time, so that's just thoughts,\n\u003e\u003e but maybe it can render things much more difficult\n\u003e\u003e than???????computing two files until the same hash is found\n\u003e\u003e \n\u003e \n\u003e You basically rely on the idea that specific collisions are more\n\u003e difficult to find.?This trick or similar tricks will not help.?(And\n\u003e actually, the more files you add to the hash, the more freedom you give\n\u003e the attacker.)\n\u003e \n\u003e Even if certain collisions are more difficult to find today (which is\n\u003e certainly true), the general rule is that someone will prove you wrong\n\u003e in a year.\n\u003e \n\u003e Even if ignore security entirely, switching to new hash function is\n\u003e much simpler trying to fix the usage of a broken hash function.\n\u003e \n\u003e Relying on SHA1 is hopeless. We have to get rid of it.\n\u003e \n\u003e Best,\n\u003e Tim\n\u003e \n\u003e \n\u003e \n\u003e \n\u003e \n\u003e ------------------------------\n\u003e \n\u003e Message: 2\n\u003e Date: Fri, 24 Feb 2017 16:18:43 +0100\n\u003e From: Aymeric Vitte \u003cvitteaymeric at gmail.com\u003e\n\u003e To: bitcoin-dev at lists.linuxfoundation.org\n\u003e Subject: Re: [bitcoin-dev] SHA1 collisions make Git vulnerable to\n\u003e \tattakcs by third-parties, not just repo maintainers\n\u003e Message-ID: \u003c15848c1b-2873-35e8-0588-c636126257df at gmail.com\u003e\n\u003e Content-Type: text/plain; charset=utf-8\n\u003e \n\u003e Not sure that you really read deeply what I sent, because stating that\n\u003e hashing files continuously instead of hashing the intermediate steps\n\u003e just gives more latitude to the attacker can't be true when the attacker\n\u003e has absolutely no control over the past files\n\u003e \n\u003e I did not write this as a workaround to fix SHA1, which will be dead\n\u003e soon or later but as maybe some general concept that could possibly help\n\u003e whatever hash function you are using for objects that are not frozen but\n\u003e extending (ie the original email stating that trees might be some kind\n\u003e of worse candidates for collisions reminded me this), indeed it makes no\n\u003e sense to patch SHA1 or play around, but this kind of proposal could\n\u003e accompany the defunct\n\u003e \n\u003e The drawback is that you have to keep the hash state when you close the\n\u003e latest hash computation in order to start the next one\n\u003e \n\u003e Then the question is: knowing the hash state, is it as easy to find a\n\u003e collision between two files that will be computed in the next round than\n\u003e finding a collision between two files only?\n\u003e \n\u003e Knowing that you can probably modify the hash state with some\n\u003e unpredictable patterns\n\u003e \n\u003e Most likely the answer is: no, it's (astronomically?) more difficult\n\u003e \n\u003e Please take it as a suggestion that might be explored (ps: I have the\n\u003e code for this if needed) rather than an affirmation, still amazed as\n\u003e shown in the few links provided (among others) that each time I raise\n\u003e this subject nobody really pays attention (what's the use case?, etc)\n\u003e and by the fact that it's apparently used by only one project in the\n\u003e world and not supported by any library\n\u003e \n\u003e \n\u003e Le 24/02/2017 ? 11:04, Tim Ruffing via bitcoin-dev a ?crit :\n\u003e\u003e On Fri, 2017-02-24 at 00:57 +0100, Aymeric Vitte via bitcoin-dev wrote:\n\u003e\u003e\u003e I have not worked on this since some time, so that's just thoughts,\n\u003e\u003e\u003e but maybe it can render things much more difficult\n\u003e\u003e\u003e than       computing two files until the same hash is found\n\u003e\u003e\u003e \n\u003e\u003e You basically rely on the idea that specific collisions are more\n\u003e\u003e difficult to find. This trick or similar tricks will not help. (And\n\u003e\u003e actually, the more files you add to the hash, the more freedom you give\n\u003e\u003e the attacker.)\n\u003e\u003e \n\u003e\u003e Even if certain collisions are more difficult to find today (which is\n\u003e\u003e certainly true), the general rule is that someone will prove you wrong\n\u003e\u003e in a year.\n\u003e\u003e \n\u003e\u003e Even if ignore security entirely, switching to new hash function is\n\u003e\u003e much simpler trying to fix the usage of a broken hash function.\n\u003e\u003e \n\u003e\u003e Relying on SHA1 is hopeless. We have to get rid of it.\n\u003e\u003e \n\u003e\u003e Best,\n\u003e\u003e Tim\n\u003e\u003e \n\u003e\u003e \n\u003e\u003e \n\u003e\u003e _______________________________________________\n\u003e\u003e bitcoin-dev mailing list\n\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e \n\u003e -- \n\u003e Zcash wallets made simple: https://github.com/Ayms/zcash-wallets\n\u003e Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets\n\u003e Get the torrent dynamic blocklist: http://peersm.com/getblocklist\n\u003e Check the 10 M passwords list: http://peersm.com/findmyass\n\u003e Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org\n\u003e Peersm : http://www.peersm.com\n\u003e torrent-live: https://github.com/Ayms/torrent-live\n\u003e node-Tor : https://www.github.com/Ayms/node-Tor\n\u003e GitHub : https://www.github.com/Ayms\n\u003e \n\u003e \n\u003e \n\u003e ------------------------------\n\u003e \n\u003e Message: 3\n\u003e Date: Fri, 24 Feb 2017 17:30:49 +0100\n\u003e From: Tim Ruffing \u003ctim.ruffing at mmci.uni-saarland.de\u003e\n\u003e To: bitcoin-dev at lists.linuxfoundation.org\n\u003e Subject: Re: [bitcoin-dev] SHA1 collisions make Git vulnerable to\n\u003e \tattakcs by third-parties, not just repo maintainers\n\u003e Message-ID: \u003c1487953849.5148.2.camel at mmci.uni-saarland.de\u003e\n\u003e Content-Type: text/plain; charset=\"UTF-8\"\n\u003e \n\u003e On Fri, 2017-02-24 at 16:18 +0100, Aymeric Vitte via bitcoin-dev wrote:\n\u003e\u003e Not sure that you really read deeply what I sent, because stating\n\u003e\u003e that\n\u003e\u003e hashing files continuously instead of hashing the intermediate steps\n\u003e\u003e just gives more latitude to the attacker can't be true when the\n\u003e\u003e attacker\n\u003e\u003e has absolutely no control over the past files\n\u003e What prevents the attacker to provide different past files when talking\n\u003e to parties who are still in the initial state?\n\u003e \n\u003e Then the question is: knowing the hash state, is it as easy to find a\n\u003e\u003e collision between two files that will be computed in the next round\n\u003e\u003e than\n\u003e\u003e finding a collision between two files only?\n\u003e With the original usage of the hash function, the hash state is always\n\u003e the initial state. Now that the attacker has some control over the hash\n\u003e state even. In other words, if the original use of the hash function\n\u003e was vulnerable, then your scheme is vulnerable for the initial state.\n\u003e \n\u003e Concrete attack: If you can find x != y with H(x) = H(y), then you can\n\u003e also find m, x != y, with H(m||x) = H(m||y), just by setting m = \"\". \n\u003e \n\u003e Not sure if this is the right place to discuss that issue though...\n\u003e \n\u003e Best,\n\u003e Tim\n\u003e \n\u003e \n\u003e ------------------------------\n\u003e \n\u003e Message: 4\n\u003e Date: Fri, 24 Feb 2017 18:29:50 +0100\n\u003e From: Aymeric Vitte \u003cvitteaymeric at gmail.com\u003e\n\u003e To: Tim Ruffing \u003ctim.ruffing at mmci.uni-saarland.de\u003e,\tBitcoin Protocol\n\u003e \tDiscussion \u003cbitcoin-dev at lists.linuxfoundation.org\u003e\n\u003e Subject: Re: [bitcoin-dev] SHA1 collisions make Git vulnerable to\n\u003e \tattakcs by third-parties, not just repo maintainers\n\u003e Message-ID: \u003cb557a0de-2492-80a1-eff7-229503ae382d at gmail.com\u003e\n\u003e Content-Type: text/plain; charset=windows-1252\n\u003e \n\u003e ??? apparently we are not discussing the same thing\n\u003e \n\u003e Maybe I did not provide the right links (reading them again I myself\n\u003e don't find them so clear), see maybe again\n\u003e https://github.com/whatwg/streams/issues/33#issuecomment-28045860\n\u003e \n\u003e a - b - c -d\n\u003e \n\u003e hash(a)\n\u003e \n\u003e hash(a+b)\n\u003e \n\u003e etc\n\u003e \n\u003e But you are not going to rehash from the beginning, then:\n\u003e \n\u003e update a --\u003e keep the remaining bytes a_ (+ hash state 1) --\u003e digest\n\u003e a=hash(a)\n\u003e \n\u003e update a_+b from hash state 1--\u003e keep the remaining bytes b_ (+ hash\n\u003e state 2) --\u003e digest a_+b=hash(a+b)\n\u003e \n\u003e etc\n\u003e \n\u003e Basically that's similar to a real time progressive hash of chunks of a\n\u003e file that you are streaming and therefore don't know what will come next\n\u003e (per opposition to hashing a file that you already have), this could\n\u003e apply to trees\n\u003e \n\u003e This is different from something like:\n\u003e \n\u003e hash(a)\n\u003e \n\u003e hash(hash(a) +hash(b))\n\u003e \n\u003e etc\n\u003e \n\u003e There is no initial state, and the attacker can't modify what was\n\u003e already hashed, to make it more difficult you can probably modify the\n\u003e hash state N\n\u003e \n\u003e \n\u003e Le 24/02/2017 ? 17:30, Tim Ruffing via bitcoin-dev a ?crit :\n\u003e\u003e On Fri, 2017-02-24 at 16:18 +0100, Aymeric Vitte via bitcoin-dev wrote:\n\u003e\u003e\u003e Not sure that you really read deeply what I sent, because stating\n\u003e\u003e\u003e that\n\u003e\u003e\u003e hashing files continuously instead of hashing the intermediate steps\n\u003e\u003e\u003e just gives more latitude to the attacker can't be true when the\n\u003e\u003e\u003e attacker\n\u003e\u003e\u003e has absolutely no control over the past files\n\u003e\u003e What prevents the attacker to provide different past files when talking\n\u003e\u003e to parties who are still in the initial state?\n\u003e\u003e \n\u003e\u003e Then the question is: knowing the hash state, is it as easy to find a\n\u003e\u003e\u003e collision between two files that will be computed in the next round\n\u003e\u003e\u003e than\n\u003e\u003e\u003e finding a collision between two files only?\n\u003e\u003e With the original usage of the hash function, the hash state is always\n\u003e\u003e the initial state. Now that the attacker has some control over the hash\n\u003e\u003e state even. In other words, if the original use of the hash function\n\u003e\u003e was vulnerable, then your scheme is vulnerable for the initial state.\n\u003e\u003e \n\u003e\u003e Concrete attack: If you can find x != y with H(x) = H(y), then you can\n\u003e\u003e also find m, x != y, with H(m||x) = H(m||y), just by setting m = \"\". \n\u003e\u003e \n\u003e\u003e Not sure if this is the right place to discuss that issue though...\n\u003e\u003e \n\u003e\u003e Best,\n\u003e\u003e Tim\n\u003e\u003e _______________________________________________\n\u003e\u003e bitcoin-dev mailing list\n\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e \n\u003e -- \n\u003e Zcash wallets made simple: https://github.com/Ayms/zcash-wallets\n\u003e Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets\n\u003e Get the torrent dynamic blocklist: http://peersm.com/getblocklist\n\u003e Check the 10 M passwords list: http://peersm.com/findmyass\n\u003e Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org\n\u003e Peersm : http://www.peersm.com\n\u003e torrent-live: https://github.com/Ayms/torrent-live\n\u003e node-Tor : https://www.github.com/Ayms/node-Tor\n\u003e GitHub : https://www.github.com/Ayms\n\u003e \n\u003e \n\u003e \n\u003e ------------------------------\n\u003e \n\u003e Message: 5\n\u003e Date: Fri, 24 Feb 2017 14:20:19 -0800\n\u003e From: Bram Cohen \u003cbram at bittorrent.com\u003e\n\u003e To: Peter Todd \u003cpete at petertodd.org\u003e\n\u003e Cc: Bitcoin Protocol Discussion\n\u003e \t\u003cbitcoin-dev at lists.linuxfoundation.org\u003e\n\u003e Subject: Re: [bitcoin-dev] A Better MMR Definition\n\u003e Message-ID:\n\u003e \t\u003cCA+KqGkpi4GvgU-K6vt-U5ZN4AkpjZ0rruzddoJS4-V0TcnyqUQ at mail.gmail.com\u003e\n\u003e Content-Type: text/plain; charset=\"utf-8\"\n\u003e \n\u003e So your idea is to cluster entries by entry time because newer things are\n\u003e more likely to leave and updating multiple things near each other is\n\u003e cheaper?\n\u003e \n\u003e That can be done with my tool. Instead of using hashes for the values being\n\u003e stored, you use position entries. The first entry gets a value of all\n\u003e zeros, the next one a one followed by all zeros, then the next two\n\u003e correspond to the first two with the second bit flipped to one, then the\n\u003e next four the first four with the third bit flipped to one, etc. It\n\u003e probably performs a little bit better to do it two bits at a time instead\n\u003e of one so that the entries are 00, 01, 10, 11, 0001, 0010, 0011, 0101,\n\u003e 0110, 0111, 1001, etc. If you were to really use this you'd probably want\n\u003e to to add some optimizations to use the fact that the terminals fit in 64\n\u003e bits instead of 256, but it mostly works unchanged, and gets whatever\n\u003e benefits there are to this clustering plus the high performance\n\u003e implementation tricks I've built which I keep complaining that nobody's\n\u003e giving feedback on.\n\u003e \n\u003e I'm not sold on this being a win: The empirical access patterns are\n\u003e unknown, it requires an extra cache miss per lookup to find the entry\n\u003e number, it may be that everything is optimized well enough without it for\n\u003e there to be no meaningful gains, and it's a bunch of extra complexity. What\n\u003e should be done is that a plain vanilla UTXO set solution is optimized as\n\u003e well as it can be first, and then the insertion ordering trick is tried as\n\u003e an optimization to see if it's an improvement. Without that baseline\n\u003e there's no meaningful basis for comparison, and I'm quite confident that a\n\u003e naive implementation which just allocates individual nodes will\n\u003e underperform the thing I've come up with, even without adding optimizations\n\u003e related to fitting in 64 bits.\n\u003e \n\u003e On Thu, Feb 23, 2017 at 8:36 PM, Peter Todd \u003cpete at petertodd.org\u003e wrote:\n\u003e \n\u003e\u003e On Thu, Feb 23, 2017 at 07:32:43PM -0800, Bram Cohen wrote:\n\u003e\u003e\u003e On Thu, Feb 23, 2017 at 7:15 PM, Peter Todd \u003cpete at petertodd.org\u003e wrote:\n\u003e\u003e\u003e \n\u003e\u003e\u003e\u003e \n\u003e\u003e\u003e\u003e Glad we're on the same page with regard to what's possible in TXO\n\u003e\u003e\u003e\u003e commitments.\n\u003e\u003e\u003e\u003e \n\u003e\u003e\u003e\u003e Secondly, am I correct in saying your UTXO commitments scheme requires\n\u003e\u003e\u003e\u003e random\n\u003e\u003e\u003e\u003e access? While you describe it as a \"merkle set\", obviously to be\n\u003e\u003e merkelized\n\u003e\u003e\u003e\u003e it'll have to have an ordering of some kind. What do you propose that\n\u003e\u003e\u003e\u003e ordering\n\u003e\u003e\u003e\u003e to be?\n\u003e\u003e\u003e\u003e \n\u003e\u003e\u003e \n\u003e\u003e\u003e The ordering is by the bits in the hash. Technically it's a Patricia\n\u003e\u003e Trie.\n\u003e\u003e\u003e I'm using 'merkle tree' to refer to basically anything with a hash root.\n\u003e\u003e \n\u003e\u003e The hash of what? The values in the set?\n\u003e\u003e \n\u003e\u003e\u003e\u003e Maybe more specifically, what exact values do you propose to be in the\n\u003e\u003e set?\n\u003e\u003e\u003e\u003e \n\u003e\u003e\u003e\u003e \n\u003e\u003e\u003e That is unspecified in the implementation, it just takes a 256 bit value\n\u003e\u003e\u003e which is presumably a hash of something. The intention is to nail down a\n\u003e\u003e\u003e simple format and demonstrate good performance and leave those semantics\n\u003e\u003e to\n\u003e\u003e\u003e a higher layer. The simplest thing would be to hash together the txid and\n\u003e\u003e\u003e output number.\n\u003e\u003e \n\u003e\u003e Ok, so let's assume the values in the set are the unspent outpoints.\n\u003e\u003e \n\u003e\u003e Since we're ordering by the hash of the values in the set, outpoints will\n\u003e\u003e be\n\u003e\u003e distributed uniformly in the set, and thus the access pattern of data in\n\u003e\u003e the\n\u003e\u003e set is uniform.\n\u003e\u003e \n\u003e\u003e Now let's fast-forward 10 years. For the sake of argument, assume that for\n\u003e\u003e every 1 UTXO in the set that corresponds to funds in someone's wallet that\n\u003e\u003e are\n\u003e\u003e likely to be spent, there are 2^12 = 4096 UTXO's that have been permanently\n\u003e\u003e lost (and/or created in spam attacks) and thus will never be spent.\n\u003e\u003e \n\u003e\u003e Since lost UTXO's are *also* uniformly distributed, if I'm processing a new\n\u003e\u003e block that spends 2^12 = 4096 UTXO's, on average for each UTXO spent, I'll\n\u003e\u003e have to update log2(4096) = 12 more digests than I would have had those\n\u003e\u003e \"dead\"\n\u003e\u003e UTXO's not existed.\n\u003e\u003e \n\u003e\u003e Concretely, imagine our UTXO set had just 8 values in it, and we were\n\u003e\u003e updating\n\u003e\u003e two of them:\n\u003e\u003e \n\u003e\u003e               #\n\u003e\u003e              / \\\n\u003e\u003e             /   \\\n\u003e\u003e            /     \\\n\u003e\u003e           /       \\\n\u003e\u003e          /         \\\n\u003e\u003e         #           #\n\u003e\u003e        / \\         / \\\n\u003e\u003e       /   \\       /   \\\n\u003e\u003e      #     .     .     #\n\u003e\u003e     / \\   / \\   / \\   / \\\n\u003e\u003e    .   X .   . .   . X   .\n\u003e\u003e \n\u003e\u003e To mark two coins as spent, we've had to update 5 inner nodes.\n\u003e\u003e \n\u003e\u003e \n\u003e\u003e Now let's look at what happens in an insertion-ordered TXO commitment\n\u003e\u003e scheme.\n\u003e\u003e For sake of argument, let's assume the best possible case, where every UTXO\n\u003e\u003e spent in that same block was recently created. Since the UTXO's are\n\u003e\u003e recently\n\u003e\u003e created, chances are almost every single one of those \"dead\" UTXO's will\n\u003e\u003e have\n\u003e\u003e been created in the past. Thus, since this is an insertion-ordered data\n\u003e\u003e structure, those UTXO's exist in an older part of the data structure that\n\u003e\u003e our\n\u003e\u003e new block doesn't need to modify at all.\n\u003e\u003e \n\u003e\u003e Concretely, again let's imagine a TXO commitment with 8 values in it, and\n\u003e\u003e two\n\u003e\u003e of them being spent:\n\u003e\u003e \n\u003e\u003e               #\n\u003e\u003e              / \\\n\u003e\u003e             /   \\\n\u003e\u003e            /     \\\n\u003e\u003e           /       \\\n\u003e\u003e          /         \\\n\u003e\u003e         .           #\n\u003e\u003e        / \\         / \\\n\u003e\u003e       /   \\       /   \\\n\u003e\u003e      .     .     .     #\n\u003e\u003e     / \\   / \\   / \\   / \\\n\u003e\u003e    .   . .   . .   . X   X\n\u003e\u003e \n\u003e\u003e To mark two coins as spent, we've only had to update 3 inner nodes; while\n\u003e\u003e our\n\u003e\u003e tree is higher with those lost coins, those extra inner nodes are amortised\n\u003e\u003e across all the coins we have to update.\n\u003e\u003e \n\u003e\u003e \n\u003e\u003e The situation gets even better when we look at the *new* UTXO's that our\n\u003e\u003e block\n\u003e\u003e creates. Suppose our UTXO set has size n. To mark a single coin as spent,\n\u003e\u003e we\n\u003e\u003e have to update log2(n) inner nodes. We do get to amortise this a bit at\n\u003e\u003e the top\n\u003e\u003e levels in the tree, but even if we assume the amortisation is totally free,\n\u003e\u003e we're updating at least log2(n) - log2(m) inner nodes \"under\" the amortised\n\u003e\u003e nodes at the top of the tree for *each* new node.\n\u003e\u003e \n\u003e\u003e Meanwhile with an insertion-ordered TXO commitment, each new UTXO added to\n\u003e\u003e the\n\u003e\u003e data set goes in the same place - the end. So almost none of the existing\n\u003e\u003e data\n\u003e\u003e needs to be touched to add the new UTXOs. Equally, the hashing required\n\u003e\u003e for the\n\u003e\u003e new UTXO's can be done in an incremental fashion that's very L1/L2 cache\n\u003e\u003e friendly.\n\u003e\u003e \n\u003e\u003e \n\u003e\u003e tl;dr: Precisely because access patterns in TXO commitments are *not*\n\u003e\u003e uniform,\n\u003e\u003e I think we'll find that from a L1/L2/etc cache perspective alone, TXO\n\u003e\u003e commitments will result in better performance than UTXO commitments.\n\u003e\u003e \n\u003e\u003e \n\u003e\u003e Now it is true that Bitcoin's current design means we'll need a map of\n\u003e\u003e confirmed outpoints to TXO insertion order indexes. But it's not\n\u003e\u003e particularly\n\u003e\u003e hard to add that \"metadata\" to transactions on the P2P layer in the same\n\u003e\u003e way\n\u003e\u003e that segwit added witnesses to transactions without modifying how txids\n\u003e\u003e were\n\u003e\u003e calculated; if you only connect to peers who provide you with TXO index\n\u003e\u003e information in blocks and transactions, you don't need to keep that map\n\u003e\u003e yourself.\n\u003e\u003e \n\u003e\u003e Finally, note how this makes transactions *smaller* in many circumstances:\n\u003e\u003e it's\n\u003e\u003e just a 8-byte max index rather than a 40 byte outpoint.\n\u003e\u003e \n\u003e\u003e --\n\u003e\u003e https://petertodd.org 'peter'[:-1]@petertodd.org\n\u003e\u003e \n\u003e -------------- next part --------------\n\u003e An HTML attachment was scrubbed...\n\u003e URL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170224/63ab2731/attachment.html\u003e\n\u003e \n\u003e ------------------------------\n\u003e \n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e \n\u003e \n\u003e End of bitcoin-dev Digest, Vol 21, Issue 34\n\u003e *******************************************"}