From tomas at bitcrust.org Thu Mar 1 11:23:12 2018 From: tomas at bitcrust.org (Tomas) Date: Thu, 01 Mar 2018 12:23:12 +0100 Subject: [Bitcoin-ml] UTXO Commitments Message-ID: <1519903392.2845560.1287620440.05B1D573@webmail.messagingengine.com> Let me share some progress and ideas related to UTXO commitments. Background ========== Adding a UTXO commitment to the blocks has two major use cases: 1. Allow fast syncing of full nodes as they can download the UTXO set instead of historic blocks 2. Provide UTXO inclusion/exclusion proofs. I believe especially 1. is an enormous gain, as it saves full nodes from downloading the entire chain without compromising trust or security. Let me address three different ways to approach this: A. Flat ECMH commitment ====================== We use an Elliptic Curve Multiset Hash to merge all UTXO's into a single hash. Such multiset hash allows us to add and remove UTXO's to it in place, and can therefore be cheaply maintained. This only solves (1.) fast syncing as it is only possible to verify the *entire* UTXO set against this hash. The current ECMH implementation takes about 10us per operation, which is rather acceptable. Note that adding the commitment is only the first step in fast syncing. The next steps would include providing getutxo/utxo p2p messages, and after that implementing fast sync. Spec: * ECMH: https://github.com/tomasvdw/bips/blob/master/ecmh.mediawiki * Commitment: TODO Code (WIP): * https://github.com/tomasvdw/bitcoin-abc/tree/utxoflat (reviews on reviews.bitcoin-abc.org) More info: * https://github.com/tomasvdw/bitcoin-abc/blob/utxoflat/src/secp256k1/src/modules/multiset/README.md * https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014337.html * https://arxiv.org/pdf/1601.06502.pdf * https://eprint.iacr.org/2009/226.pdf B. Bucketed ECMH commitment ========================= This approach is similar to A, except that we divide the UTXO set in different buckets (or "shards") based on prefix. The different prefixes are than hashed together in a tree. This would allow UTXO inclusion and exclusion proofs, with the size of a single bucket. The drawback is that maintaining a large number of ECMH commitments is considerably more heavy than maintaining a single one. Although the ECMH operations themselves are still 10us, gathering everything into a single hash requires normalizing each ECMH bucket and this takes 150ms-300ms per block depending on the bucket size (and thus proof-size). We will need to look at improvements before this is feasible Spec: * ECMH (same as ^): https://github.com/tomasvdw/bips/blob/master/ecmh.mediawiki * Commitment: https://github.com/tomasvdw/bips/blob/master/BIP-UtxoCommitBucket.mediawiki Code (WIP) * https://github.com/tomasvdw/bitcoin-abc/tree/utxocommit More info: * https://lists.linuxfoundation.org/pipermail/bitcoin-ml/2017-September/000240.html C. Commitment enabled UTXO storage ================================= An alternative to ECMH would be to maintain the UTXO set in a storage that directly provides a commitment, instead of maintaining or calculating it separately. This could be done by hashing the UTXOs in a binary merkle tree based on prefix, or a "merklix" tree. Even if the hash is specified as a binary merklix, its not necessary to use an actual binary tree for storage; an implementation can opt for a much more efficient concurrent hashtree (CTrie) structure, while calculating the root hash *as if* it were a binary tree. The challenge of this approach is that - like for instance LevelDB - such storage does not utilize the MRU access pattern of UTXO's, which makes it rather cache-inefficient. Yet unlike the current implementations we would not be able to easily use a custom cache. I can imagine it may be possible to improve on this by adding a clever block height branch at the right position in the tree, where we trade multiple branch lookups for cache efficiency (which is effectively what the currrent cache does). This however needs more research. More info: * https://www.deadalnix.me/2016/11/06/using-merklix-tree-to-shard-block-validation/ * https://en.wikipedia.org/wiki/Ctrie Versioning and conclusion ====================== It is never easy to come to agreement on the details. Luckily it is trivial to version the commitment by making it optional. We only specify that *if* present it must be correct. Such versioning allows us to start with the simplest "A." flat ECMH solution as "version 1 commitment", and continue our research from there. Progress with A. is being made, and in my opinion including it has major benefits and little drawbacks. Hopefully we can agree on the value of such a first step though if not, feel free to comment. Tomas van der Wansem bitcrust From tomas at bitcrust.org Thu Mar 1 13:55:33 2018 From: tomas at bitcrust.org (Tomas) Date: Thu, 01 Mar 2018 14:55:33 +0100 Subject: [Bitcoin-ml] On the security of fast syncing the UTXO set Message-ID: <1519912533.2944919.1287718528.20F72144@webmail.messagingengine.com> With a UTXO commitment it becomes possible to synchronize a full node using only a few GB. Some seem to think that such a fast-sync is useful for full nodes that do not need to "fully validate history", providing an optional "compromise" between trust and download requirements. After all they would need to trust the commitment? This is incorrect. A UTXO commitment makes syncing from genesis completely obsolete, save for historians. Fast sync doesn't change the trust model. I will explain in two steps, and follow with a rather bold claim. First of all, current full nodes use a hardcoded "assumevalid=X" block by default. Any ancestor of this is assumed valid and signatures aren't verified. This means that the *only* reason for such default full node to download old blocks is to generate the UTXO set. With a UTXO commitment it can do so in 2GB without additional trust. Next, you could doubt "assumevalid". Surely if you really want to "fully validate" you should set "assumevalid=0" to start from the beginning? Not really. Assumevalid=X does not prescribe which chain or blocks to use. This is determined by accumulated work; "Assumevalid=X" is included in the source code *only* to state that all parents of X pass the validity checks of *that very piece of source code*. It is akin to a "compile time" evaluation of the blocks and does not introduce more trust than the trust in the software already required. Now for the bold claim, let us first make a pragmatic assessment: Reorgs of more than 20000 blocks cannot happen. Although in theory reorgs are unlimited, we can "proof" this assessment by contradiction: If a reorg of 20000 blocks *would* happen it immediately becomes clear that the currency is useless, worthless, and that Satoshi's invention doesn't work after all. Now let Y be the block 20000 blocks back. There is a lot of code in the codebase that is only relevant for blocks before Y and not used for blocks after Y and new blocks. If we take above reorg-assumption as fact, and follow the logic laid out we must conclude: ** All this historical validation code is *completely redundant* with a single clause stating Y is valid ! ** This is counter-intuitive as it seemingly contradicts the "verify don't trust" idea some cryptographers have been pushing. But only seemingly so; with the max-20000 reorg assumption, this old validation code serves no purpose and doesn't decrease trust or increase security. I am not proposing that we should rush removing old validation code; it certainly has some elegance to include it. But I wanted to share nonetheless this perspective on security and trust which seems so often misunderstood. Tomas van der Wansem bitcrust From jaredr26 at gmail.com Thu Mar 1 15:14:26 2018 From: jaredr26 at gmail.com (Jared Lee Richardson) Date: Thu, 1 Mar 2018 07:14:26 -0800 Subject: [Bitcoin-ml] On the security of fast syncing the UTXO set In-Reply-To: <1519912533.2944919.1287718528.20F72144@webmail.messagingengine.com> References: <1519912533.2944919.1287718528.20F72144@webmail.messagingengine.com> Message-ID: Nailed it. Completely agree. Also, a UTXO model that allowed the fast sync user to select how far back in time they wished to sync to and then full sync from there would be for all practical purposes trusts and completely protected by the proof of work system. Jared On Mar 1, 2018 5:55 AM, "Tomas via bitcoin-ml" < bitcoin-ml at lists.linuxfoundation.org> wrote: > With a UTXO commitment it becomes possible to synchronize a full node > using only a few GB. > > Some seem to think that such a fast-sync is useful for full nodes that do > not need to "fully validate history", providing an optional "compromise" > between trust and download requirements. After all they would need to trust > the commitment? > > This is incorrect. A UTXO commitment makes syncing from genesis completely > obsolete, save for historians. Fast sync doesn't change the trust model. > > I will explain in two steps, and follow with a rather bold claim. > > First of all, current full nodes use a hardcoded "assumevalid=X" block by > default. Any ancestor of this is assumed valid and signatures aren't > verified. This means that the *only* reason for such default full node to > download old blocks is to generate the UTXO set. With a UTXO commitment it > can do so in 2GB without additional trust. > > Next, you could doubt "assumevalid". Surely if you really want to "fully > validate" you should set "assumevalid=0" to start from the beginning? > > Not really. Assumevalid=X does not prescribe which chain or blocks to use. > This is determined by accumulated work; "Assumevalid=X" is included in the > source code *only* to state that all parents of X pass the validity checks > of *that very piece of source code*. It is akin to a "compile time" > evaluation of the blocks and does not introduce more trust than the trust > in the software already required. > > > Now for the bold claim, let us first make a pragmatic assessment: Reorgs > of more than 20000 blocks cannot happen. Although in theory reorgs are > unlimited, we can "proof" this assessment by contradiction: If a reorg of > 20000 blocks *would* happen it immediately becomes clear that the currency > is useless, worthless, and that Satoshi's invention doesn't work after all. > > Now let Y be the block 20000 blocks back. There is a lot of code in the > codebase that is only relevant for blocks before Y and not used for blocks > after Y and new blocks. If we take above reorg-assumption as fact, and > follow the logic laid out we must conclude: > > ** All this historical validation code is *completely redundant* with a > single clause stating Y is valid ! ** > > This is counter-intuitive as it seemingly contradicts the "verify don't > trust" idea some cryptographers have been pushing. But only seemingly so; > with the max-20000 reorg assumption, this old validation code serves no > purpose and doesn't decrease trust or increase security. > > I am not proposing that we should rush removing old validation code; it > certainly has some elegance to include it. But I wanted to share > nonetheless this perspective on security and trust which seems so often > misunderstood. > > > Tomas van der Wansem > bitcrust > _______________________________________________ > bitcoin-ml mailing list > bitcoin-ml at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-ml > -------------- next part -------------- An HTML attachment was scrubbed... URL: From otaci at protonmail.com Sun Mar 11 00:18:47 2018 From: otaci at protonmail.com (Daniel Connolly) Date: Sat, 10 Mar 2018 19:18:47 -0500 Subject: [Bitcoin-ml] OP_Codes In-Reply-To: References: <319676fd-3797-bc93-a62f-0d3560f5b6e4@mailbox.org> Message-ID: Dear George, the most recent documentation regarding the re-enabled opcodes (OP_CAT etc) is located here: https://github.com/bitcoincashorg/spec/pull/53 You can open an issue here: https://github.com/bitcoincashorg/spec/issues I am interested in what you have spotted, you can also describe it in this group or send it to me directly. Regards, Daniel ??????? Original Message ??????? On February 23, 2018 10:50 PM, George Macoukji via bitcoin-ml wrote: > I've already spotted an issue with the OP_CAT documentation. I'm not hugely familiar with Github. How do we report issues most effectively? With normal code, we can just open an issue or comment directly on the line in question. > > -- > "I got an "A" in philosophy because I proved my professor didn't exist." > -- Judy Tenuta > > On Fri, Feb 23, 2018 at 12:10 PM, G. Andrew Stone via bitcoin-ml wrote: > >> Here are the current opcode specifications. We would certainly appreciate your critical review for security flaws. >> >> OP_CAT, OP_SPLIT, OP_AND, OP_OR, OP_XOR, OP_DIV, OP_MOD, OP_BIN2NUM, OP_NUM2BIN: >> https://github.com/shadders/uahf-spec/blob/reenable-op-codes/reenable-op-codes.md >> >> OP_DATASIGVERIFY: >> https://github.com/gandrewstone/BitcoinUnlimited/blob/op_datasigverify/doc/opdatasigverify.md >> >> OP_GROUP: >> https://github.com/gandrewstone/BitcoinUnlimited/blob/opgroup_fullnode/doc/opgroup-tokens.md >> >> On Fri, Feb 23, 2018 at 4:01 AM, Alexey Eromenko via bitcoin-ml wrote: >> >>> Thats why I requested info per every op code, are there "dangerous " ones, that have downsides? >>> >>> On Fri, 23 Feb 2018 at 6:47 Amaury S?chet wrote: >>> >>>> The downside depends on op_codes. Maybe you have question about specific op_codes ? >>>> >>>> 2018-02-23 1:54 GMT+01:00 Alexey Eromenko via bitcoin-ml : >>>> >>>>> What are the downsides for each OPCODE enablement ? >>>>> >>>>> _______________________________________________ >>>>> bitcoin-ml mailing list >>>>> bitcoin-ml at lists.linuxfoundation.org >>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-ml >>> >>> -- >>> -Alexey Eromenko "Technologov" >>> >>> _______________________________________________ >>> bitcoin-ml mailing list >>> bitcoin-ml at lists.linuxfoundation.org >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-ml >> >> _______________________________________________ >> bitcoin-ml mailing list >> bitcoin-ml at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-ml -------------- next part -------------- An HTML attachment was scrubbed... URL: From wordsgalore at gmail.com Sun Mar 11 10:31:04 2018 From: wordsgalore at gmail.com (Scott Roberts) Date: Sun, 11 Mar 2018 06:31:04 -0400 Subject: [Bitcoin-ml] Full difficulty data? Message-ID: Can someone email me the full difficulty data since the fork? I want to see how it's been doing in order to help select the best N for other coins. I need block number, timestamp, and difficulty. I'm trying to avoid having to startup a full node. From ctpacia at gmail.com Sun Mar 11 14:45:24 2018 From: ctpacia at gmail.com (Chris Pacia) Date: Sun, 11 Mar 2018 10:45:24 -0400 Subject: [Bitcoin-ml] Full difficulty data? In-Reply-To: References: Message-ID: <71a8606f-9505-4a68-3ba0-7d2c11b272b0@gmail.com> Query a block explorer On 03/11/2018 06:31 AM, Scott Roberts via bitcoin-ml wrote: > Can someone email me the full difficulty data since the fork? I want > to see how it's been doing in order to help select the best N for > other coins. I need block number, timestamp, and difficulty. I'm > trying to avoid having to startup a full node. > _______________________________________________ > bitcoin-ml mailing list > bitcoin-ml at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-ml > From grarpamp at gmail.com Tue Mar 20 18:40:03 2018 From: grarpamp at gmail.com (grarpamp) Date: Tue, 20 Mar 2018 14:40:03 -0400 Subject: [Bitcoin-ml] Intercept: NSA MONKEYROCKET: Cryptocurrency / AnonBrowser Service - Full Take Tracking Users, Trojan SW Message-ID: https://theintercept.com/2018/03/20/the-nsa-worked-to-track-down-bitcoin-users-snowden-documents-reveal/ https://www.reddit.com/search?sort=top&t=week&q=nsa+bitcoin https://hn.algolia.com/?sort=byPopularity&dateRange=pastWeek&query=nsa+bitcoin https://slashdot.org/index2.pl?fhfilter=nsa+bitcoin OAKSTAR MONKEYROCKET aka THUNDERISLAND "agency working to unmask Bitcoin users about six months before Ulbricht was arrested, and that it had worked to monitor Liberty Reserve around the same time" "American spies were also working to crack Liberty Reserve" "analysts have .. tracked down senders / receivers of Bitcoin" the agency was interested in surveilling some competing cryptocurrencies, "Bitcoin is #1 priority," "using this ?browsing product,? which ?the NSA can then exploit.? "These programs involve ventures with US companies." Staff travel to "Virginia partner / these extremely patriotic business associates" highly cloaked. " Partner provided first/last name metadata... large influx of traffic... ftp process... causing disk space to fill up " Powers also used for traditional police work ?other targeted users will include those... International / Organised Crime and Narcotics...Follow-The-Money" missions " cyber targets that utilize online e-currency services... There?s no elaboration on who is considered a ?cyber target.? " " that the NSA would ?launch an entire operation ... under false pretenses? just to track targets is ?pernicious,? ... Such a practice could spread distrust of privacy software in general, particularly in areas like Iran where such tools are desperately needed by dissidents. This ?feeds a narrative that the U.S. is untrustworthy,? " "Despite Bitcoin?s reputation for privacy... you should really lower your expectations of privacy on this network.? " financial privacy ?is something that matters incredibly? to the Bitcoin community, and expects that ?people who are privacy conscious will switch to privacy-oriented coins? after learning of the NSA?s work here. " " If the government?s criminal investigations secretly relied on NSA spying, that would be a serious concern. Individuals facing criminal prosecution have a right to know how the government came by its evidence, so that they can challenge whether the government?s methods were lawful. That is a basic principle of due process. The government should not be hiding the true sources for its evidence in court by inventing a different trail. " https://theintercept.com/2017/11/30/nsa-surveillance-fisa-section-702/ " Civil liberties advocates have long suspected that the Justice Department is underreporting Section 702 cases in order to limit court challenges to the controversial law. Some theorize that the government conceals Section 702 use through a process known as ?parallel construction,? in which evidence obtained from the warrantless surveillance authority is reobtained through traditional FISA authorization, and the government only discloses the latter authority in U.S. District Court. One defense lawyer referred to this practice in a court filing as ?laundering? Section 702 evidence. " ? The government intercepts Americans? emails and phone calls in vast quantities using this spying law and stores them in databases for years,? said Patrick Toomey, staff attorney for the American Civil Liberties Union?s National Security Project. ?FBI agents around the country then go searching through that trove of data as a matter of course, including in domestic criminal investigations. " " If the FBI uses parallel construction to conceal intelligence community information, it would not be the only federal law enforcement agency doing so. In 2013, Reuters obtained documents from the U.S. Drug Enforcement Administration that showed how agents were trained to ?recreate? investigative trails to conceal how intelligence intercepts helped to identify criminal targets. " From angkennith606 at gmail.com Tue Mar 20 19:39:40 2018 From: angkennith606 at gmail.com (angkennith606 at gmail.com) Date: Tue, 20 Mar 2018 19:39:40 +0000 Subject: [Bitcoin-ml] Intercept: NSA MONKEYROCKET: Cryptocurrency / AnonBrowser Service - Full Take Tracking Users, Trojan SW In-Reply-To: References: Message-ID: <5ab1637c7a35b_62c43feff1398cf076155825@ip-172-31-22-71.mail> Thanks for emailing me! No, I haven?t been hacked :) I signed up for a spam filtering service called BitBounce. To deliver your email to my inbox, please click the link below. Thanks! https://bitbounce.com/pay_bitbounce_fee/242288785 BitBounce is a product by: Turing Technology, Inc. BitBounce.com San Mateo, CA -------------- next part -------------- An HTML attachment was scrubbed... URL: From info at meetup.com Sun Mar 25 18:11:28 2018 From: info at meetup.com (Saransh Sharma) Date: Sun, 25 Mar 2018 18:11:28 +0000 (UTC) Subject: [Bitcoin-ml] Please accept my invitation to Bitcoin Cash Soft Introduction Message-ID: <103537445.1522001487846.JavaMail.nobody@ecf0c8225fbe> You're invited! -------------------------------------- Join Saransh Sharma at Bitcoin Cash Soft Introduction When: Saturday, April 21, 2018, 4:00 PM Where: Koregaon Park Koregaon Park, Pune This Meetup is hosted by Local Bitcoin Cash. Lets discuss bitcoin cash sound money of internet 1. What is bitcoin cash?2. How to buy and trade in bitcoin cash? Guide.3. Tech behind bitcoin cash.4. Business use cases in bitcoin cash.5. Developme... https://meet.meetup.com/wf/click?upn=pEEcc35imY7Cq0tG1vyTt4Z4gND5RbLM8N-2BuJDsKubhlsuh5g4Jbj0Xb-2Ba7-2BJOrs7eqkf5U07yDualtMk4G9XU8HSPDz-2FOR381TTPPky2K-2FT45NkX6ZmY5pxu1PEBxNilFki1YXQIvlilu-2FJibrEigWBKHvtjtLTKFgDNI32X2eG4NQAMJoBnCkwQ9LTcxwyNGewaoR7LGO4-2BnLnctpEQeFERJ6JXlcLYaIlAsLc6d4NWXGn9KbMGhngHuI8EWFZE-2Bc9ny8f6sPndvPpySU-2ByipIg7dsz9rEgSng20-2Fxa4jSBKAoBKz2Qb2ZiDAzxqe3PRKs6AXrpEeMovedhTImOnB7oqAdyhCmaFk8M17-2Ba6uHjFtHBqTdHyKzIpNebiDqyFoTXGWVy7BPt00eHyKH1Jq6MGoyDrheZdW6Q-2Bszm7u8DwoUiOX-2BrK1UQubCBDz0uDUk9CkYZpgunQ-2BWsgnONH6hXOMTx3gDvHBkDFDmLBL8wAobYIXUe4maE32iwRYFB3tCSbfS2R9hSTMsWzgOAHpoo6wMTpNMIl1EPYyis8pQI9KDXxt4-2B3-2FiofW8aFsUg-2FnvSPkFrBtNxe9HWOSQQZqF-2B2gO2crSM-2FyxyH4k-2BTE2ANLdmsOT9o9-2FXYHLRqdoDExte-2BAh9YestEkQRbHtr0WoN4i5bcqBON1EXCUW7t506y6eeoKE9QuYvrDjqBMatk5D-2FBDCY7VFf6v8RxKY-2B80A-2FUGutRIVZPL4Na8Ma-2Fi-2BNpPyVibBHKlEoYPhLFghjpICtQ6GZ3cHwbaYT6I4pifjot-2Bu-2B9EL9H5zL2tjtlwTvU5p3op6iloZpcErsrTmJfx2YGy99JfSWx-2FhAUeO-2F-2BxkL0t9KjhpVcp1-2FClS0CQbMLndDIlkZBSPEqjRMOcflqGizqa0G2F2KYRDwM1GbA-3D-3D_FPVR34OW0iTCykNVpPzODh2VAegZpmBWPby4P9iLaZw-2B6qiQ557s-2BTbGz3dNvJaQakAdfYbe2E8B1bMeWTXo4hVkPc1-2FibKy-2B87pUH5V8L04F7ipVmJnwiUuW-2FdmUxAkg9Zl6y3-2F-2FrtknNvI8xzTjrl86GnlrblX5Zfqc4c6pzd9LP8VqwKJ9wI24mGiMBgqswcYB0BG07eiwKaSBr2qce-2BxiGTP-2BxFYmt1z6qjW5w3zdZTCm0kxqzt-2B7rvMdVP2 -------------------------------------- ------- This message was sent by Meetup on behalf of Saransh Sharma (https://meet.meetup.com/wf/click?upn=pEEcc35imY7Cq0tG1vyTt4flg9yZ9Zp-2Bo0FW6Np7p6kjFb58qhkeqKnsMIihARM31p67nouv-2F9ArFT0SM7lx5Qjbou3-2BUjfBbCc0V7fN7-2BM-3D_FPVR34OW0iTCykNVpPzODh2VAegZpmBWPby4P9iLaZw-2B6qiQ557s-2BTbGz3dNvJaQakAdfYbe2E8B1bMeWTXo4uDfpvhmBv27zbP1sTrBp-2FNJIzwPvn3QbUSMfq7Y4r1dyhrRSHDn4wRcTDqwWDPP5PiiGBwYoET0d-2FA2I7f05zGcKxDK49U-2FPrpTsoUCJIjLA0icZj-2BSeVTe-2BNCcCDgGyZRX39RO8z5tZI-2F47pVQEPK5cobPl6NByQzPw8uxmSkw from Local Bitcoin Cash. Questions? You can email Meetup Support at support at meetup.com Unsubscribe (https://meet.meetup.com/wf/click?upn=pEEcc35imY7Cq0tG1vyTt4Z4gND5RbLM8N-2BuJDsKubhlsuh5g4Jbj0Xb-2Ba7-2BJOrs7eqkf5U07yDualtMk4G9XXM9AVZBrUeKDq0HbE4ayLXUofWSR5jrzgDpGi4KePNgeIiHLY81A-2FZ5XZXHMP-2B5wd6ElCOq1vuqVAeHj-2Bmkfxx3bzNrYNb3UrRtaQIGFg-2B-2BzXBlLUXd025OiUInkSF6Qrq24fhp8tVqVVzgb60g8RMmxae1MZtRXJB1Pld1SQSFD5yDr907OLKCoaLwDfzl0RTFmKwyxZxEHGoEq4uGWpR0CCKeIs4VqKGGeBUSzpkje3OzbgHyL9gE4VaNQfeMeY-2Bj7Mfur0iGZoa12rQo9D-2FtemiKb7sGx5PHfbB2tsgFZQmf7iF-2FdGkHk9ELTbQn2ex0Hw1H5HqW7rFw6tZ8vdBVb6dVu9mEvaIodqPeLepGLU3VMhFP3yyBSz66XQGQpFAiK-2BH1ZjgHW9Q0KwnNp5jrcHnK6GpZwkX3SNv0NqSdiEgRY3jKBJuHtA4W5-2Fk-2FbgecEO2kN4MBibh9mcVU3WRR54D2ZmAXghMLvPgZcSFpb7EpPW-2FCM67ylABY4PEasqGo4gvGyuqX7eiNfU-2BqaifMO-2Bsr-2B2jxghH7uxcsTL-2BaPbaSExFSP91S8YtTMcRLEA-3D-3D_FPVR34OW0iTCykNVpPzODh2VAegZpmBWPby4P9iLaZw-2B6qiQ557s-2BTbGz3dNvJaQakAdfYbe2E8B1bMeWTXo4kPy3zjbwnsm19xGc1QpRsBL4SJJfu6ktLcb2BIP04-2B9sff-2B3v5vG0qYHTCmCOEehETO34ESwwVGTaCOI7gz-2BGqlyVnvLsRKEpBC9SiN68V-2FLEshdixPuYRmblDrU5ULf-2FsP3XhrMFt5CduTh84P4pAwWjxLhXxh7UZ4MxTswPk0 from this type of email. Meetup Inc. (https://meet.meetup.com/wf/click?upn=pEEcc35imY7Cq0tG1vyTt-2B7KQDdcKC7y-2FRa2MaHHwu32BVPjg98Avxo09r3TPTi7_FPVR34OW0iTCykNVpPzODh2VAegZpmBWPby4P9iLaZw-2B6qiQ557s-2BTbGz3dNvJaQakAdfYbe2E8B1bMeWTXo4murZP7zpuoe7o7aznSsvICwrs-2BSZUIHnJplb8AJ-2FYDSh-2B-2B4j5gqe74KhxAC90WsmFhhl3dvXqKq6eAtbFw-2FQqLPc-2F3JYpHEN7nRSNtf2wTJDmtJ-2FZ2v9O6WW6Cr-2BXQn9IucFnXpwmqjDzX68tQj67R9XiwkrJZRCSB1SfAQiHS-2F POB 4668 #37895 New York NY USA 10163 -------------- next part -------------- An HTML attachment was scrubbed... URL: From nanatthawat at gmail.com Wed Mar 28 08:58:54 2018 From: nanatthawat at gmail.com (=?UTF-8?B?4LiT4LiT4Lix4LiQ4Lin4Lix4LiS4LiZ4LmMIOC4p+C4o+C4oOC4seC4hOC4mOC4meC4p+C4sQ==?= =?UTF-8?B?4LiS4LiZ4LmM?=) Date: Wed, 28 Mar 2018 08:58:54 +0000 Subject: [Bitcoin-ml] (no subject) Message-ID: . -------------- next part -------------- An HTML attachment was scrubbed... URL: