Re: [bitcoin-dev] Taproot proposal
Good morning Greg and John, I am not as sanguine here; SegWit activation was already delayed relative to commonly-broadcast expectations, yet many services *still* do not support sending to SegWit v0 addresses even now. On the other hand, the major benefit of taproot is the better privacy and homogeneity afforded by Taproot, and supporting both P2SH-wrapped and non-wrapped SegWit v1 addresses simply increases the number of places that a user may be characterized and potentially identified. Thus while I disagree with your reasoning, I do agree with your conclusion: no P2SH-wrapped SegWit v1. Regards, ZmnSCPxj Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Tuesday, September 17, 2019 12:18 AM, Greg Sanders via bitcoin-dev wrote: > > I'd prefer to not support P2SH-nested TR. P2SH wrapping was useful for > > segwit > v0 for compatibility reasons. Most wallets/exchanges/services now support > sending > to native segwit addresses (https://en.bitcoin.it/wiki/Bech32_adoption) and > that > will be even more true if Schnorr/Taproot activate in 12+ months time. > > Apologies for necroing an ancient thread, but I'm echoing my agreement with > John here. > We still have plenty of time to have ecosystem upgrade by the time taproot is > likely to activate. > > On Wed, May 22, 2019 at 10:30 AM John Newbery via bitcoin-dev > wrote: > > > Hi, > > > > > A Taproot output is a SegWit output [...] with > > > version number 1, and a 33-byte witness program whose first byte is 0 or > > > 1. > > > > Given a secret key k and public key P=(x,y), a signer with the knowledge of > > k > > can sign for -P=(x,p-y) since -k is the secret key for that point. Encoding > > the > > y value of the public key therefore adds no security. As an alternative to > > providing the y value of the taproot output key Q when constructing the > > taproot > > output, the signer can provide it when signing. We can also restrict the y > > value > > of the internal key P to be even (or high, or a quadratic residue). That > > gives > > us 4 options for how to set the y signs for P and Q. > > > > 1. Q sign is explictly set in the witness program, P sign is explicitly set > > in the control block > > => witness program is 33 bytes, 32 possible leaf versions (one for each > > pair of 0xc0..0xff) > > 2. Q sign is explictly set in the witness program, P sign is implicitly even > > => witness program is 33 bytes, 64 possible leaf versions (one for each > > 0xc0..0xff) > > 3. Q sign is explictly set in the control block, P sign is explicitly set > > in the control block > > => witness program is 32 bytes, 16 possible leaf versions (one for each > > 4-tuple of 0xc0..0xff) > > 4. Q sign is explictly set in the control block, P sign is implicitly even > > => witness program is 32 bytes, 32 possible leaf versions (one for pair > > of 0xc0..0xff) > > > > The current proposal uses (1). Using (3) or (4) would reduce the size of a > > taproot output by one byte to be the same size as a P2WSH output. That means > > that it's not more expensive for senders compared to sending to P2WSH. > > > > (Credit to James Chiang for suggesting omitting the y sign from the public > > key and > > to sipa for pointing out the 4 options above) > > > > > (native or P2SH-nested, see BIP141) > > > > I'd prefer to not support P2SH-nested TR. P2SH wrapping was useful for > > segwit > > v0 for compatibility reasons. Most wallets/exchanges/services now support > > sending > > to native segwit addresses (https://en.bitcoin.it/wiki/Bech32_adoption) and > > that > > will be even more true if Schnorr/Taproot activate in 12+ months time. > > > > On Mon, May 6, 2019 at 2:36 PM Pieter Wuille via bitcoin-dev > > wrote: > > > > > Hello everyone, > > > > > > Here are two BIP drafts that specify a proposal for a Taproot > > > softfork. A number of ideas are included: > > > > > > * Taproot to make all outputs and cooperative spends indistinguishable > > > from eachother. > > > * Merkle branches to hide the unexecuted branches in scripts. > > > * Schnorr signatures enable wallet software to use key > > > aggregation/thresholds within one input. > > > * Improvements to the signature hashing algorithm (including signing > > > all input amounts). > > > * Replacing OP_CHECKMULTISIG(VERIFY) with OP_CHECKSIGADD, to support > > > batch validation. > > > * Tagged hashing for domain separation (avoiding issues like > > > CVE-2012-2459 in Merkle trees). > > > * Extensibility through leaf versions, OP_SUCCESS opcodes, and > > > upgradable pubkey types. > > > > > > The BIP drafts can be found here: > > > * https://github.com/sipa/bips/blob/bip-schnorr/bip-taproot.mediawiki > > > specifies the transaction input spending rules. > > > * https://github.com/sipa/bips/blob/bip-schnorr/bip-tapscript.mediawiki > > > specifies the changes to Script inside such spends. > > > * https://github.com/sipa/bips/blob/bip-schnorr/bip-schnorr.mediawiki > > >
Re: [bitcoin-dev] Introcing a side memory network to bitcoin for ads
Good morning Tamas, Thank you for taking the time to implement my idea. I filed an issue proposing a feature to add a "contact point" fixed-length field to all advertisements. https://github.com/defiads/defiads/issues/1 I believe this gives me the right to say: First post. I will try to take a look at building some kind of UI at some point in the next few months or years. Regards, ZmnSCPxj Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Tuesday, September 17, 2019 8:04 AM, Tamas Blummer via bitcoin-dev wrote: > I introduced you to the pattern of a side memory to bitcoin in [1] and > promised an implementation of it. > > Here you are. > > defiads is a side memory network to bitcoin, implemented in Rust, built > on top of rust-bitcoin, murmel, hammersbald, rust-bitcoinconsenus, > rust-wallet, all Rust open source free to grab at > https://github.com/defiads/defiads > > defiads builds a peer-to-peer network to distribute textual ads, as > first suggested by ZmnSCPxj[4]. I hope that it will serve > decentralized finance applications with an infrastructure to distribute > ads, order books, coinjoin proposals etc. > > Every defiads node maintains a copy of a network-wide shared 1GB memory > pool of current ads. > > An ad is replicated to other nodes as long as there is some bitcoin > locked to it on the bitcoin network. Locking means someone transferred > some sats to an address that is associated with the ad using the > pay-to-contract protocol[2]. The address does not release the bitcoins > until a predefined time span that is the duration of the advertizement, > this is accomplished with OP_CSV. The ad will be evicted from the pool > as soon as the coins locked to it are spendable again. > > defiads ranks advertizements by the ratio of used space divided by > bitcoins locked and will only replicate the top 1GB of this ranked list. > > You may read the ads by starting a defiads process of your own and > the query the content through its JSON-RPC API. > > You may place ads by performing the following steps, with its JSON-RPC API > > 1. deposit some bitcoins into your defiads node's wallet > 2. prepare an ad, providing its category, abstract and content > 3. fund the ad by locking some of the bitcoins to it for a limited term > of the advertizement > > 4. you may withdraw your coins from the defiads node's wallet after the > advertizement expires > > defiads handles the association with ads, locking and unlocking coins. > > Implementation notes > defiads connects to both the bitcoin and its own peer-to-peer network. > You do not need to run a bitcoin node as defiads only needs a small > fraction of the information on the bictoin blockchain and retrieves that > on its own, as an SPV node. > > The defiads node's wallet is compatibe with that of TREZOR, Ledger, > Greenwallet and many other wallets that support BIP38, BIP44, BIP48, > BIP84 key generation and use standards. > > defiads uses Invertible Bloom Lookup Tables[3] to synchronize the ads > pool with its peers. > > Status > It seems to work, but you should not yet use with real bitcoins, > therefore by default it connects the bitcoin's test network. > > There is no discovery for the network yet, so you will have to know some > peer in the network to see other than your own ads. Write me a direct > email if you'd like to connect to my node. > > Future developent > Should the use become popular then 1GB pool become tight, then people > will have to compete for its use. Some might not have enough bitcoin's > to lock and might therefore pay others to lock theirs to fund an > advertizement. defiads network could match both sides and thereby give > rise to bitcoin's first truly risk less interest rate market. > > defiads is currently downloading, but not storing, > the blocks after its birth date. This will no longer be needed once > BIP158 filters are served and committed by Bitcoin Core. > > I hope that someone builds a nice UI on top of the JSON RPC as that is > not my area of expertise. > > Tamas Blummer > > [1] > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-August/017264.html > > [2] https://arxiv.org/pdf/1212.3257.pdf > > [3] https://arxiv.org/pdf/1101.2245.pdf > > [4] > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-July/017083.html > > > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] Introcing a side memory network to bitcoin for ads
I introduced you to the pattern of a side memory to bitcoin in [1] and promised an implementation of it. Here you are. defiads is a side memory network to bitcoin, implemented in Rust, built on top of rust-bitcoin, murmel, hammersbald, rust-bitcoinconsenus, rust-wallet, all Rust open source free to grab at https://github.com/defiads/defiads defiads builds a peer-to-peer network to distribute textual ads, as first suggested by ZmnSCPxj[4]. I hope that it will serve decentralized finance applications with an infrastructure to distribute ads, order books, coinjoin proposals etc. Every defiads node maintains a copy of a network-wide shared 1GB memory pool of current ads. An ad is replicated to other nodes as long as there is some bitcoin locked to it on the bitcoin network. Locking means someone transferred some sats to an address that is associated with the ad using the pay-to-contract protocol[2]. The address does not release the bitcoins until a predefined time span that is the duration of the advertizement, this is accomplished with OP_CSV. The ad will be evicted from the pool as soon as the coins locked to it are spendable again. defiads ranks advertizements by the ratio of used space divided by bitcoins locked and will only replicate the top 1GB of this ranked list. You may read the ads by starting a defiads process of your own and the query the content through its JSON-RPC API. You may place ads by performing the following steps, with its JSON-RPC API 1. deposit some bitcoins into your defiads node's wallet 2. prepare an ad, providing its category, abstract and content 3. fund the ad by locking some of the bitcoins to it for a limited term of the advertizement 4. you may withdraw your coins from the defiads node's wallet after the advertizement expires defiads handles the association with ads, locking and unlocking coins. Implementation notes defiads connects to both the bitcoin and its own peer-to-peer network. You do not need to run a bitcoin node as defiads only needs a small fraction of the information on the bictoin blockchain and retrieves that on its own, as an SPV node. The defiads node's wallet is compatibe with that of TREZOR, Ledger, Greenwallet and many other wallets that support BIP38, BIP44, BIP48, BIP84 key generation and use standards. defiads uses Invertible Bloom Lookup Tables[3] to synchronize the ads pool with its peers. Status It seems to work, but you should not yet use with real bitcoins, therefore by default it connects the bitcoin's test network. There is no discovery for the network yet, so you will have to know some peer in the network to see other than your own ads. Write me a direct email if you'd like to connect to my node. Future developent Should the use become popular then 1GB pool become tight, then people will have to compete for its use. Some might not have enough bitcoin's to lock and might therefore pay others to lock theirs to fund an advertizement. defiads network could match both sides and thereby give rise to bitcoin's first truly risk less interest rate market. defiads is currently downloading, but not storing, the blocks after its birth date. This will no longer be needed once BIP158 filters are served and committed by Bitcoin Core. I hope that someone builds a nice UI on top of the JSON RPC as that is not my area of expertise. Tamas Blummer [1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-August/017264.html [2] https://arxiv.org/pdf/1212.3257.pdf [3] https://arxiv.org/pdf/1101.2245.pdf [4] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-July/017083.html ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] PoW fraud proofs without a soft fork
On Sun, Sep 08, 2019 at 05:39:28AM +0200, Ruben Somsen via bitcoin-dev wrote: > After looking more deeply into Tadge Dryja’s utreexo work [0], it has > become clear to me that this opens up a way to implement PoW fraud > proofs [1] without a soft fork. This is a nifty idea. > [...] you’d need to download: > > [...] > > 3. the utreexo merkle proofs which prove that all inputs of N+1 are > part of the UTXO set (~1MB) I think "~1 MB" is probably a reasonable estimate for the average case but not for the worst case. To allow verification of the spends in block N+1, each UTXO entry must contain its entire scriptPubKey. I believe the current consensus rules allow scriptPubKeys to be up to 10,000 bytes in size. A specially-constructed block can contain a bit more than 20,000 inputs, making the worst case size of just the UTXO entries that needs to be communicated over 200 MB. > If it turns out that one of your peers disagrees on what the correct > hash is, you find the last utreexo hash where that peer still agreed, > let’s say block M, and you simply execute the same three steps to find > out which peer is wrong I think this also expands to a worst-case of over 200 MB. A lying peer will only be able to get you on one of these checks, so it's 200 MB per lying peer. For an honest peer communicating valid blocks, the worst case is that they'll need to communicate both of these state transactions, so over 400 MB. That could be a bandwidth-wasting DoS attack on honest listening nodes if there were a large number of SPV clients using this type of fraud proofs. Additionally, each node capable of providing fraud proofs will need to persistently store the state transition proof for each new block. I assume this is equal to the block undo data currently stored by archival full nodes plus the utreexo partial merkle branches. This data would probably not be stored by pruned nodes, at least not beyond their prune depth, even for pruned nodes that use utreexo. That would mean this system will only work with archival full nodes with an extra "index" containing the utreexo partial merkle branches, or it will require querying utreexo bridge nodes. Given that both of those would require significant additional system resources beyond the minimum required to operate a full node, such nodes might be rare and so make it relatively easy to eclipse attack an SPV client depending on these proofs. Finally, this system depends on SPV clients implementing all the same consensus checks that full nodes can currently perform. Given that most SPV clients I'm aware of today don't even perform the full range of checks it's possible to run on block headers, I have serious doubts that many (or any) SPV clients will actually implement full verification. On top of that, each client must implement those checks perfectly or they could be tricked into a chainsplit the same as a full node that follows different rules than the economic consensus. > [1] Improving SPV security with PoW fraud proofs: > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-April/016873.html One thing I didn't like in your original proposal---which I appologize for keeping to myself---is that the SPV client will accept confirmations on the bad chain until a fork is produced. Even a miner with a minority of the hash rate will sometimes be able to produce a 6-block chain before the remaining miners produce a single block. In that case, SPV clients with a single dishonest peer in collusion with the miner will accept any transctions in the first block of that chain as having six confirmations. That's the same as it is today, but today SPV users don't think fraud proofs help keep them secure. I think that, if we wanted to widely deploy fraud proofs depending on forks as a signal, we'd have to also retrain SPV users to wait for much higher confirmation counts before accepting transactions as reasonably secure. -Dave ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Taproot proposal
> I'd prefer to not support P2SH-nested TR. P2SH wrapping was useful for segwit v0 for compatibility reasons. Most wallets/exchanges/services now support sending to native segwit addresses (https://en.bitcoin.it/wiki/Bech32_adoption) and that will be even more true if Schnorr/Taproot activate in 12+ months time. Apologies for necroing an ancient thread, but I'm echoing my agreement with John here. We still have plenty of time to have ecosystem upgrade by the time taproot is likely to activate. On Wed, May 22, 2019 at 10:30 AM John Newbery via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Hi, > > > A Taproot output is a SegWit output [...] with > > version number 1, and a 33-byte witness program whose first byte is 0 or > 1. > > Given a secret key k and public key P=(x,y), a signer with the knowledge > of k > can sign for -P=(x,p-y) since -k is the secret key for that point. > Encoding the > y value of the public key therefore adds no security. As an alternative to > providing the y value of the taproot output key Q when constructing the > taproot > output, the signer can provide it when signing. We can also restrict the y > value > of the internal key P to be even (or high, or a quadratic residue). That > gives > us 4 options for how to set the y signs for P and Q. > > 1. Q sign is explictly set in the witness program, P sign is explicitly > set in the control block > => witness program is 33 bytes, 32 possible leaf versions (one for > each pair of 0xc0..0xff) > 2. Q sign is explictly set in the witness program, P sign is implicitly > even > => witness program is 33 bytes, 64 possible leaf versions (one for > each 0xc0..0xff) > 3. Q sign is explictly set in the control block, P sign is explicitly set > in the control block > => witness program is 32 bytes, 16 possible leaf versions (one for > each 4-tuple of 0xc0..0xff) > 4. Q sign is explictly set in the control block, P sign is implicitly even > => witness program is 32 bytes, 32 possible leaf versions (one for > pair of 0xc0..0xff) > > The current proposal uses (1). Using (3) or (4) would reduce the size of a > taproot output by one byte to be the same size as a P2WSH output. That > means > that it's not more expensive for senders compared to sending to P2WSH. > > (Credit to James Chiang for suggesting omitting the y sign from the public > key and > to sipa for pointing out the 4 options above) > > > (native or P2SH-nested, see BIP141) > > I'd prefer to not support P2SH-nested TR. P2SH wrapping was useful for > segwit > v0 for compatibility reasons. Most wallets/exchanges/services now support > sending > to native segwit addresses (https://en.bitcoin.it/wiki/Bech32_adoption) > and that > will be even more true if Schnorr/Taproot activate in 12+ months time. > > On Mon, May 6, 2019 at 2:36 PM Pieter Wuille via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> Hello everyone, >> >> Here are two BIP drafts that specify a proposal for a Taproot >> softfork. A number of ideas are included: >> >> * Taproot to make all outputs and cooperative spends indistinguishable >> from eachother. >> * Merkle branches to hide the unexecuted branches in scripts. >> * Schnorr signatures enable wallet software to use key >> aggregation/thresholds within one input. >> * Improvements to the signature hashing algorithm (including signing >> all input amounts). >> * Replacing OP_CHECKMULTISIG(VERIFY) with OP_CHECKSIGADD, to support >> batch validation. >> * Tagged hashing for domain separation (avoiding issues like >> CVE-2012-2459 in Merkle trees). >> * Extensibility through leaf versions, OP_SUCCESS opcodes, and >> upgradable pubkey types. >> >> The BIP drafts can be found here: >> * https://github.com/sipa/bips/blob/bip-schnorr/bip-taproot.mediawiki >> specifies the transaction input spending rules. >> * https://github.com/sipa/bips/blob/bip-schnorr/bip-tapscript.mediawiki >> specifies the changes to Script inside such spends. >> * https://github.com/sipa/bips/blob/bip-schnorr/bip-schnorr.mediawiki >> is the Schnorr signature proposal that was discussed earlier on this >> list (See >> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-July/016203.html >> ) >> >> An initial reference implementation of the consensus changes, plus >> preliminary construction/signing tests in the Python framework can be >> found on https://github.com/sipa/bitcoin/commits/taproot. All >> together, excluding the Schnorr signature module in libsecp256k1, the >> consensus changes are around 520 LoC. >> >> While many other ideas exist, not everything is incorporated. This >> includes several ideas that can be implemented separately without loss >> of effectiveness. One such idea is a way to integrate SIGHASH_NOINPUT, >> which we're working on as an independent proposal. >> >> The document explains basic wallet operations, such as constructing >> outputs and signing. However, a wide variety of more complex >> constructions exist.
[bitcoin-dev] Transcripts from Scaling Bitcoin 2019
Hi, Here are some transcripts of talks from Scaling Bitcoin 2019 Tel Aviv. Any errors are most likely my own. Training material Training materials for bitcoin developers: https://diyhpl.us/wiki/transcripts/scalingbitcoin/tel-aviv-2019/edgedevplusplus/ Foundation topics: https://diyhpl.us/wiki/transcripts/scalingbitcoin/tel-aviv-2019/edgedevplusplus/bitcoin-data-structures/ https://diyhpl.us/wiki/transcripts/scalingbitcoin/tel-aviv-2019/edgedevplusplus/blockchain-design-patterns/ https://diyhpl.us/wiki/transcripts/scalingbitcoin/tel-aviv-2019/edgedevplusplus/hardware-wallet-design-best-practices/ https://diyhpl.us/wiki/transcripts/scalingbitcoin/tel-aviv-2019/edgedevplusplus/privacy-concepts/ Developing Bitcoin Core: https://diyhpl.us/wiki/transcripts/scalingbitcoin/tel-aviv-2019/edgedevplusplus/bitcoin-core-functional-test-framework/ https://diyhpl.us/wiki/transcripts/scalingbitcoin/tel-aviv-2019/edgedevplusplus/debugging-bitcoin/ https://diyhpl.us/wiki/transcripts/scalingbitcoin/tel-aviv-2019/edgedevplusplus/rebroadcasting/ https://diyhpl.us/wiki/transcripts/scalingbitcoin/tel-aviv-2019/edgedevplusplus/signet/ https://diyhpl.us/wiki/transcripts/scalingbitcoin/tel-aviv-2019/edgedevplusplus/wallet-architecture/ https://diyhpl.us/wiki/transcripts/scalingbitcoin/tel-aviv-2019/edgedevplusplus/libbitcoin/ Lightning network: https://diyhpl.us/wiki/transcripts/scalingbitcoin/tel-aviv-2019/edgedevplusplus/lightning-network-routing/ https://diyhpl.us/wiki/transcripts/scalingbitcoin/tel-aviv-2019/edgedevplusplus/lightning-network-sphinx-and-onion-routing/ https://diyhpl.us/wiki/transcripts/scalingbitcoin/tel-aviv-2019/edgedevplusplus/lightning-network-topology/ Upgrades: https://diyhpl.us/wiki/transcripts/scalingbitcoin/tel-aviv-2019/edgedevplusplus/accumulators/ https://diyhpl.us/wiki/transcripts/scalingbitcoin/tel-aviv-2019/edgedevplusplus/taproot/ Scaling Bitcoin conference LN, payment networks and hubs: https://diyhpl.us/wiki/transcripts/scalingbitcoin/tel-aviv-2019/anonymous-atomic-locks/ https://diyhpl.us/wiki/transcripts/scalingbitcoin/tel-aviv-2019/atomic-multi-channel-updates/ https://diyhpl.us/wiki/transcripts/scalingbitcoin/tel-aviv-2019/payment-channel-recovery-with-seeds/ Upgrades: https://diyhpl.us/wiki/transcripts/scalingbitcoin/tel-aviv-2019/bip-securethebag/ https://diyhpl.us/wiki/transcripts/scalingbitcoin/tel-aviv-2019/erlay/ https://diyhpl.us/wiki/transcripts/scalingbitcoin/tel-aviv-2019/secure-fountain-architecture/ https://diyhpl.us/wiki/transcripts/scalingbitcoin/tel-aviv-2019/elastic-block-caps/ https://diyhpl.us/wiki/transcripts/scalingbitcoin/tel-aviv-2019/plasma-cash/ https://diyhpl.us/wiki/transcripts/scalingbitcoin/tel-aviv-2019/prism/ https://diyhpl.us/wiki/transcripts/scalingbitcoin/tel-aviv-2019/proof-of-necessary-work/ https://diyhpl.us/wiki/transcripts/scalingbitcoin/tel-aviv-2019/proof-of-verification-for-proof-of-work/ https://diyhpl.us/wiki/transcripts/scalingbitcoin/tel-aviv-2019/threshold-scriptless-scripts/ https://diyhpl.us/wiki/transcripts/scalingbitcoin/tel-aviv-2019/scriptless-lotteries/ https://diyhpl.us/wiki/transcripts/scalingbitcoin/tel-aviv-2019/survey-of-progress-in-zero-knowledge-proofs-towards-trustless-snarks/ https://diyhpl.us/wiki/transcripts/scalingbitcoin/tel-aviv-2019/zkvm/ https://diyhpl.us/wiki/transcripts/scalingbitcoin/tel-aviv-2019/bitml/ Private information retrieval methods for lightweight clients: https://diyhpl.us/wiki/transcripts/scalingbitcoin/tel-aviv-2019/private-information-retrieval/ https://diyhpl.us/wiki/transcripts/scalingbitcoin/tel-aviv-2019/scaling-oblivious-read-write/ More privacy: https://diyhpl.us/wiki/transcripts/scalingbitcoin/tel-aviv-2019/zerolink-sudoku/ https://diyhpl.us/wiki/transcripts/scalingbitcoin/tel-aviv-2019/txprobe/ - Bryan http://heybryan.org/ 1 512 203 0507 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
