Re: [bitcoin-dev] BIP Number Request: Addresses over Audio

[James MacWhyte via bitcoin-dev]

I agree, audio-based transference isn't really great for a podcast or radio
ad. It could be used to transmit payment details between phones that don't
have cameras, though. I think it would be better to define a standard for
transmitting information over audio, but not define what information is to
be conveyed so people could use the method for sending pub keys, payment
protocol requests, or anything else developers might want to make use of.

I'm guessing some sort of data-over-audio standard already exists? In which
case the bip could just say "we use [standard] to convey any
bitcoin-related data".

On Wed, Aug 10, 2016, 10:55 Daniel Hoffman via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> thats how i thought it worked originally, but im not well versed on that,
> so i took his word for it
>
> On Aug 10, 2016 12:38 PM, "Pieter Wuille via bitcoin-dev" <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> On Wed, Aug 10, 2016 at 7:28 PM, Erik Aronesty via bitcoin-dev
>>  wrote:
>> > By sending a public seed,  there's no way for someone to use the
>> transmitted
>> > address and trace the total amount of payments to it.
>>
>> Worse. By revealing a public seed, anyone who has seen it (= anyone
>> who ever pays you through it) can identity all payments to _any_
>> address derived from that seed.
>>
>> --
>> Pieter
>> ___
>> 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 mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP Number Request: Addresses over Audio

[Daniel Hoffman via bitcoin-dev]

thats how i thought it worked originally, but im not well versed on that,
so i took his word for it

On Aug 10, 2016 12:38 PM, "Pieter Wuille via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Wed, Aug 10, 2016 at 7:28 PM, Erik Aronesty via bitcoin-dev
>  wrote:
> > By sending a public seed,  there's no way for someone to use the
> transmitted
> > address and trace the total amount of payments to it.
>
> Worse. By revealing a public seed, anyone who has seen it (= anyone
> who ever pays you through it) can identity all payments to _any_
> address derived from that seed.
>
> --
> Pieter
> ___
> 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

Re: [bitcoin-dev] BIP Number Request: Addresses over Audio

[Pieter Wuille via bitcoin-dev]

On Wed, Aug 10, 2016 at 7:28 PM, Erik Aronesty via bitcoin-dev
 wrote:
> By sending a public seed,  there's no way for someone to use the transmitted
> address and trace the total amount of payments to it.

Worse. By revealing a public seed, anyone who has seen it (= anyone
who ever pays you through it) can identity all payments to _any_
address derived from that seed.

-- 
Pieter
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP Number Request: Addresses over Audio

[Erik Aronesty via bitcoin-dev]

By sending a public seed,  there's no way for someone to use the
transmitted address and trace the total amount of payments to it.

On Aug 10, 2016 12:02 PM, "Daniel Hoffman via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Erik
> What would be the advantages of transmitting a BIP32 public seed, instead
> of a plain address?
>
> Theo
> I didn't really think of that, but that's genius.
>
> On Wed, Aug 10, 2016 at 6:49 AM, Theo Chino via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Another use for the audio would be for watches that can listen but can't
>> use a camera (ie: Samsung S2), so sound would be great.
>>
>> On Wed, Aug 10, 2016 at 7:42 AM, Erik Aronesty via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>>> NOTE:
>>>
>>> Addresses aren't really meant to be broadcast - you should probably be
>>> encoding BIP32 public seeds, not addresses.
>>>
>>> OR simply:
>>>
>>> - Send btc to r...@q32.com
>>> - TXT record _btc.rick.q32.com is queried (_..)
>>> - DNS-SEC validation is *required*
>>> - TXT record contains addr:[]
>>>
>>> Then you can just say, in the podcast, "Send your bitcoin donations to
>>> r...@q32.com".   And you can link it to your email address, if your
>>> provider lets you set up a TXT record.   (By structuring the TXT record
>>> that way, many existing email providers will support the standard without
>>> having to change anything.)
>>>
>>> This works with audio, video, web and other publishing formats... and
>>> very little infrastructure change is needed.
>>>
>>>
>>> On Wed, Aug 10, 2016 at 6:41 AM, Tier Nolan via bitcoin-dev <
>>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>>
 Have you considered CDMA?  This has the nice property that it just
 sounds like noise.  The codes would take longer to send, but you could send
 multiple bits at once and have the codes orthogonal.

 ___
 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 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 mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP Number Request: Addresses over Audio

[Daniel Hoffman via bitcoin-dev]

Erik
What would be the advantages of transmitting a BIP32 public seed, instead
of a plain address?

Theo
I didn't really think of that, but that's genius.

On Wed, Aug 10, 2016 at 6:49 AM, Theo Chino via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Another use for the audio would be for watches that can listen but can't
> use a camera (ie: Samsung S2), so sound would be great.
>
> On Wed, Aug 10, 2016 at 7:42 AM, Erik Aronesty via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> NOTE:
>>
>> Addresses aren't really meant to be broadcast - you should probably be
>> encoding BIP32 public seeds, not addresses.
>>
>> OR simply:
>>
>> - Send btc to r...@q32.com
>> - TXT record _btc.rick.q32.com is queried (_..)
>> - DNS-SEC validation is *required*
>> - TXT record contains addr:[]
>>
>> Then you can just say, in the podcast, "Send your bitcoin donations to
>> r...@q32.com".   And you can link it to your email address, if your
>> provider lets you set up a TXT record.   (By structuring the TXT record
>> that way, many existing email providers will support the standard without
>> having to change anything.)
>>
>> This works with audio, video, web and other publishing formats... and
>> very little infrastructure change is needed.
>>
>>
>> On Wed, Aug 10, 2016 at 6:41 AM, Tier Nolan via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>>> Have you considered CDMA?  This has the nice property that it just
>>> sounds like noise.  The codes would take longer to send, but you could send
>>> multiple bits at once and have the codes orthogonal.
>>>
>>> ___
>>> 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 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

Re: [bitcoin-dev] BIP Number Request: Addresses over Audio

[Theo Chino via bitcoin-dev]

Another use for the audio would be for watches that can listen but can't
use a camera (ie: Samsung S2), so sound would be great.

On Wed, Aug 10, 2016 at 7:42 AM, Erik Aronesty via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> NOTE:
>
> Addresses aren't really meant to be broadcast - you should probably be
> encoding BIP32 public seeds, not addresses.
>
> OR simply:
>
> - Send btc to r...@q32.com
> - TXT record _btc.rick.q32.com is queried (_..)
> - DNS-SEC validation is *required*
> - TXT record contains addr:[]
>
> Then you can just say, in the podcast, "Send your bitcoin donations to
> r...@q32.com".   And you can link it to your email address, if your
> provider lets you set up a TXT record.   (By structuring the TXT record
> that way, many existing email providers will support the standard without
> having to change anything.)
>
> This works with audio, video, web and other publishing formats... and very
> little infrastructure change is needed.
>
>
> On Wed, Aug 10, 2016 at 6:41 AM, Tier Nolan via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Have you considered CDMA?  This has the nice property that it just sounds
>> like noise.  The codes would take longer to send, but you could send
>> multiple bits at once and have the codes orthogonal.
>>
>> ___
>> 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 mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Hiding entire content of on-chain transactions

[Tony Churyumoff via bitcoin-dev]

> Signed by the key pair that was referenced in the output of the on-chain
> transaction?

Signed by the key pair referenced in the private output.

>  (Bob in my example, actually)

I misread your example.  If it was Bob, then the troll couldn't
generate the correct spend proof because he didn't see the private
output C.  The troll could try to replay the spend proof in the
Alice's transaction as soon as he sees it in the mempool, but then the
spend proof would be signed by the wrong user.

> Doesn't that mean it's easy to
> follow who is paying whom, you just can't see how much is going to reach
> recipient?

Only the recipients of the private outputs can see the previous owners
of the coins they receive (including amounts).  What everybody else
sees, is just meaningless hashes that hide both the recipient of the
coin and the amount.


2016-08-10 7:31 GMT+03:00 James MacWhyte :
> Signed by the key pair that was referenced in the output of the on-chain
> transaction? (Bob in my example, actually) Doesn't that mean it's easy to
> follow who is paying whom, you just can't see how much is going to reach
> recipient?
>
> On Tue, Aug 9, 2016, 04:40 Tony Churyumoff  wrote:
>>
>> This troll is harmless.  A duplicate spend proof should also be signed
>> by the same user (Alice, in your example) to be considered a double
>> spend.
>>
>> 2016-08-09 3:18 GMT+03:00 James MacWhyte :
>> > One more thought about why verification by miners may be needed.
>> >
>> > Let's say Alice sends Bob a transaction, generating output C.
>> >
>> > A troll, named Timothy, broadcasts a transaction with a random hash,
>> > referencing C's output as its spend proof. The miners can't tell if it's
>> > valid or not, and so they include the transaction in a block. Now Bob's
>> > money is useless, because everyone can see the spend proof referenced
>> > and
>> > thinks it has already been spent, even though the transaction that
>> > claims it
>> > isn't valid.
>> >
>> > Did I miss something that protects against this?
>> >
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Fwd: Hiding entire content of on-chain transactions

[Tony Churyumoff via bitcoin-dev]

This troll is harmless.  A duplicate spend proof should also be signed
by the same user (Alice, in your example) to be considered a double
spend.

2016-08-09 3:18 GMT+03:00 James MacWhyte :
> One more thought about why verification by miners may be needed.
>
> Let's say Alice sends Bob a transaction, generating output C.
>
> A troll, named Timothy, broadcasts a transaction with a random hash,
> referencing C's output as its spend proof. The miners can't tell if it's
> valid or not, and so they include the transaction in a block. Now Bob's
> money is useless, because everyone can see the spend proof referenced and
> thinks it has already been spent, even though the transaction that claims it
> isn't valid.
>
> Did I miss something that protects against this?
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Fwd: Hiding entire content of on-chain transactions

[Tony Churyumoff via bitcoin-dev]

> That is a good point. As you said, it puts a lot more burden on the coin
> holders. One big downside would be data management. Instead of simply
> backing up a single HD private key, the user would have to back up entire
> histories of every output that has been sent to them if they want to secure
> their funds.

You are correct.  It is somewhat similar to bearer assets: if you lose
the histories, you lose money.

> It also requires them to be online to receive payments, and I think finding
> a method of sending the private message containing the coin's history is
> going to be a bit of a challenge. If you connect directly to the recipient
> to convey the information through traditional channels, anonymity is lost.
> Sending messages through the bitcoin network is one option to protect
> anonymity, but without active pathfinding there's no guarantee the payee
> will even get the message. I'm assuming you'd have to essentially replace tx
> messages with encrypted BBC histories, and mempools are quite full as it is.
>
> Tony, do you have any more thoughts on exactly how users would convey the
> private messages to payees?

You are right conveying the private messages is not trivial.  While we
can adapt the existing bitcoin network protocol for a limited set of
use cases, such as both parties being online at the same time and
connected directly, BBC would work best if we design a whole new
communication layer specifically for conveying private messages.  We
could route the end-to-end encrypted messages through hubs who are
constantly online and would store and forward the messages, thus the
peers don't have to be online at the same time and don't have to
connect directly.  The hubs could simultaneously serve as lightening
network hubs.


2016-08-09 3:03 GMT+03:00 James MacWhyte :
> That is a good point. As you said, it puts a lot more burden on the coin
> holders. One big downside would be data management. Instead of simply
> backing up a single HD private key, the user would have to back up entire
> histories of every output that has been sent to them if they want to secure
> their funds.
>
> It also requires them to be online to receive payments, and I think finding
> a method of sending the private message containing the coin's history is
> going to be a bit of a challenge. If you connect directly to the recipient
> to convey the information through traditional channels, anonymity is lost.
> Sending messages through the bitcoin network is one option to protect
> anonymity, but without active pathfinding there's no guarantee the payee
> will even get the message. I'm assuming you'd have to essentially replace tx
> messages with encrypted BBC histories, and mempools are quite full as it is.
>
> Tony, do you have any more thoughts on exactly how users would convey the
> private messages to payees?
>
> On Mon, Aug 8, 2016 at 4:42 PM Tony Churyumoff  wrote:
>>
>> The whole point is in preventing every third party, including miners, from
>> seeing the details of what is being spent and how.  The burden of
>> verification is shifted to the owners of the coin (which is fair).
>>
>> In fact we could have miners recognize spend proofs and check that the
>> same spend proof is not entered into the blockchain more than once (which
>> would be a sign of double spend), but it is not required.  The coin owners
>> can already do that themselves.
>>
>> 2016-08-09 0:41 GMT+03:00 James MacWhyte :
>>>
>>> Wouldn't you lose the ability to assume transactions in the blockchain
>>> are verified as valid, since miners can't see the details of what is being
>>> spent and how? I feel like this ability is bitcoin's greatest asset, and by
>>> removing it you're creating an altcoin different enough to not be connected
>>> to/supported by the main bitcoin project.
>>>
>>>
>>> On Mon, Aug 8, 2016, 09:13 Tony Churyumoff via bitcoin-dev
>>>  wrote:

 Hi Henning,

 1. The fees are paid by the enclosing BTC transaction.
 2. The hash is encoded into an OP_RETURN.

 > Regarding the blinding factor, I think you could just use HMAC.
 How exactly?

 Tony


 2016-08-08 18:47 GMT+03:00 Henning Kopp :
>
> Hi Tony,
>
> I see some issues in your protocol.
>
> 1. How are mining fees handled?
>
> 2. Assume Alice sends Bob some Coins together with their history and
> Bob checks that the history is correct. How does the hash of the txout
> find its way into the blockchain?
>
> Regarding the blinding factor, I think you could just use HMAC.
>
> All the best
> Henning
>
>
> On Mon, Aug 08, 2016 at 06:30:21PM +0300, Tony Churyumoff via
> bitcoin-dev wrote:
> > This is a proposal about hiding the entire content of bitcoin
> > transactions.  It goes farther than CoinJoin and ring signatures,
> > 

[bitcoin-dev] Fwd: Hiding entire content of on-chain transactions

[Tony Churyumoff via bitcoin-dev]

> Instead of a hash function you may use a keyed hash function (HMAC) where
> the key is just the random string. They key needs to be stored in the
> history of the coin to allow for verification.

This is nearly equivalent.  The sole purpose of the blinding factor is
to increase the search space and make preimaging of the output
impossible.  While in many applications HMAC is superior to plain hash
of a concatenation of the input data and the key (key = blinding
factor in our case), its preimage resistance is the same as that of
the hash.


2016-08-09 10:26 GMT+03:00 Henning Kopp :
>
> Hi Tony,
>
> > > Regarding the blinding factor, I think you could just use HMAC.
> > How exactly?
>
> I am not entirely sure if this works. You wrote:
>
> > There is one technical nuance that I omitted above to avoid distraction.
> >  Unlike regular bitcoin transactions, every output in a private payment
> > must also include a blinding factor, which is just a random string.  When
> > the output is spent, the corresponding spend proof will therefore depend on
> > this blinding factor (remember that spend proof is just a hash of the
> > output).  Without a blinding factor, it would be feasible to pre-image the
> > spend proof and reveal the output being spent as the search space of all
> > possible outputs is rather small.
>
> Instead of a hash function you may use a keyed hash function (HMAC) where
> the key is just the random string. They key needs to be stored in the
> history of the coin to allow for verification.
>
> Best
> Henning
>
> On Mon, Aug 08, 2016 at 07:03:28PM +0300, Tony Churyumoff wrote:
> > Hi Henning,
> >
> > 1. The fees are paid by the enclosing BTC transaction.
> > 2. The hash is encoded into an OP_RETURN.
> >
> > > Regarding the blinding factor, I think you could just use HMAC.
> > How exactly?
> >
> > Tony
> >
> >
> > 2016-08-08 18:47 GMT+03:00 Henning Kopp :
> >
> > > Hi Tony,
> > >
> > > I see some issues in your protocol.
> > >
> > > 1. How are mining fees handled?
> > >
> > > 2. Assume Alice sends Bob some Coins together with their history and
> > > Bob checks that the history is correct. How does the hash of the txout
> > > find its way into the blockchain?
> > >
> > > Regarding the blinding factor, I think you could just use HMAC.
> > >
> > > All the best
> > > Henning
> > >
> > >
> > > On Mon, Aug 08, 2016 at 06:30:21PM +0300, Tony Churyumoff via bitcoin-dev
> > > wrote:
> > > > This is a proposal about hiding the entire content of bitcoin
> > > > transactions.  It goes farther than CoinJoin and ring signatures, which
> > > > only obfuscate the transaction graph, and Confidential Transactions,
> > > which
> > > > only hide the amounts.
> > > >
> > > > The central idea of the proposed design is to hide the entire inputs and
> > > > outputs, and publish only the hash of inputs and outputs in the
> > > > blockchain.  The hash can be published as OP_RETURN.  The plaintext of
> > > > inputs and outputs is sent directly to the payee via a private message,
> > > and
> > > > never goes into the blockchain.  The payee then calculates the hash and
> > > > looks it up in the blockchain to verify that the hash was indeed
> > > published
> > > > by the payer.
> > > >
> > > > Since the plaintext of the transaction is not published to the public
> > > > blockchain, all validation work has to be done only by the user who
> > > > receives the payment.
> > > >
> > > > To protect against double-spends, the payer also has to publish another
> > > > hash, which is the hash of the output being spent.  We’ll call this hash
> > > *spend
> > > > proof*.  Since the spend proof depends solely on the output being spent,
> > > > any attempt to spend the same output again will produce exactly the same
> > > > spend proof, and the payee will be able to see that, and will reject the
> > > > payment.  If there are several outputs consumed by the same transaction,
> > > > the payer has to publish several spend proofs.
> > > >
> > > > To prove that the outputs being spent are valid, the payer also has to
> > > send
> > > > the plaintexts of the earlier transaction(s) that produced them, then 
> > > > the
> > > > plaintexts of even earlier transactions that produced the outputs spent
> > > in
> > > > those transactions, and so on, up until the issue (similar to coinbase)
> > > > transactions that created the initial private coins.  Each new owner of
> > > the
> > > > coin will have to store its entire history, and when he spends the coin,
> > > he
> > > > forwards the entire history to the next owner and extends it with his 
> > > > own
> > > > transaction.
> > > >
> > > > If we apply the existing bitcoin design that allows multiple inputs and
> > > > multiple outputs per transaction, the history of ownership transfers
> > > would
> > > > grow exponentially.  Indeed, if we take any regular bitcoin output and
> > > try
> > > > to track its history back to coinbase, our history will 

[bitcoin-dev] Fwd: Hiding entire content of on-chain transactions

[Tony Churyumoff via bitcoin-dev]

> The OP's proposal sounds quite similar to my earlier one along similar lines:
>
>https://petertodd.org/2016/closed-seal-sets-and-truth-lists-for-privacy

Similar indeed, thank you for the link.


2016-08-09 0:53 GMT+03:00 Peter Todd :
>
> On Mon, Aug 08, 2016 at 09:41:27PM +, James MacWhyte via bitcoin-dev 
> wrote:
> > Wouldn't you lose the ability to assume transactions in the blockchain are
> > verified as valid, since miners can't see the details of what is being
> > spent and how? I feel like this ability is bitcoin's greatest asset, and by
> > removing it you're creating an altcoin different enough to not be connected
> > to/supported by the main bitcoin project.
>
> The fact that miners verify transactions is just an optimisation:
>
> https://petertodd.org/2013/disentangling-crypto-coin-mining
>
> Preventing double-spending however is a fundemental requirement of Bitcoin, 
> and
> this proposal does prevent double-spending perfectly well (although there may
> be better ways to do it).
>
> The OP's proposal sounds quite similar to my earlier one along similar lines:
>
> https://petertodd.org/2016/closed-seal-sets-and-truth-lists-for-privacy
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP Number Request: Addresses over Audio

[Tier Nolan via bitcoin-dev]

Have you considered CDMA?  This has the nice property that it just sounds
like noise.  The codes would take longer to send, but you could send
multiple bits at once and have the codes orthogonal.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev