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

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

[Daniel Hoffman]

[-- Attachment #1: Type: text/plain, Size: 746 bytes --]

This is my BIP idea: a fast, robust, and standardized for representing
Bitcoin addresses over audio. It takes the binary representation of the
Bitcoin address (little endian), chops that up into 4 or 2 bit chunks
(depending on type, 2 bit only for low quality audio like american
telephone lines), and generates a tone based upon that value. This started
because I wanted an easy way to donate to podcasts that I listen to, and
having a Shazam-esque app (or a media player with this capability) that
gives me an address automatically would be wonderful for both the consumer
and producer. Comes with error correction built into the protocol

You can see the full specification of the BIP on my GitHub page (
https://github.com/Dako300/BIP-0153).

[-- Attachment #2: Type: text/html, Size: 846 bytes --]

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

[Justin Newton]

[-- Attachment #1.1: Type: text/plain, Size: 1438 bytes --]

Daniel,
   Thanks for proposing this.  I think this could have some useful use
cases as you state.  I was wondering what you would think to adding some
additional tones to optionally denote an amount (in satoshis?).

(FYI, actual link is here:  https://github.com/Dako300/BIP )

Justin

On Mon, Aug 8, 2016 at 2:22 PM, Daniel Hoffman via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> This is my BIP idea: a fast, robust, and standardized for representing
> Bitcoin addresses over audio. It takes the binary representation of the
> Bitcoin address (little endian), chops that up into 4 or 2 bit chunks
> (depending on type, 2 bit only for low quality audio like american
> telephone lines), and generates a tone based upon that value. This started
> because I wanted an easy way to donate to podcasts that I listen to, and
> having a Shazam-esque app (or a media player with this capability) that
> gives me an address automatically would be wonderful for both the consumer
> and producer. Comes with error correction built into the protocol
>
> You can see the full specification of the BIP on my GitHub page (
> https://github.com/Dako300/BIP-0153).
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>


-- 

Justin W. Newton
Founder/CEO
Netki, Inc.

justin@netki.com
+1.818.261.4248

[-- Attachment #1.2: Type: text/html, Size: 3480 bytes --]

[-- Attachment #2: PastedGraphic-1.tiff --]
[-- Type: image/tiff, Size: 10972 bytes --]

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

[Daniel Hoffman]

[-- Attachment #1.1: Type: text/plain, Size: 1974 bytes --]

I wouldn't worry about payment requests until I built a decoder and made
the transmission a lot faster (probably adding tones and making it 5 bits
wide), which shouldn't be hard

On Mon, Aug 8, 2016 at 5:06 PM, Justin Newton via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Daniel,
>    Thanks for proposing this.  I think this could have some useful use
> cases as you state.  I was wondering what you would think to adding some
> additional tones to optionally denote an amount (in satoshis?).
>
> (FYI, actual link is here:  https://github.com/Dako300/BIP )
>
> Justin
>
> On Mon, Aug 8, 2016 at 2:22 PM, Daniel Hoffman via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> This is my BIP idea: a fast, robust, and standardized for representing
>> Bitcoin addresses over audio. It takes the binary representation of the
>> Bitcoin address (little endian), chops that up into 4 or 2 bit chunks
>> (depending on type, 2 bit only for low quality audio like american
>> telephone lines), and generates a tone based upon that value. This started
>> because I wanted an easy way to donate to podcasts that I listen to, and
>> having a Shazam-esque app (or a media player with this capability) that
>> gives me an address automatically would be wonderful for both the consumer
>> and producer. Comes with error correction built into the protocol
>>
>> You can see the full specification of the BIP on my GitHub page (
>> https://github.com/Dako300/BIP-0153).
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>
>
> --
>
> Justin W. Newton
> Founder/CEO
> Netki, Inc.
>
> justin@netki.com
> +1.818.261.4248
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

[-- Attachment #1.2: Type: text/html, Size: 4643 bytes --]

[-- Attachment #2: PastedGraphic-1.tiff --]
[-- Type: image/tiff, Size: 10972 bytes --]

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

[Trevin Hofmann]

[-- Attachment #1.1: Type: text/plain, Size: 2065 bytes --]

Would it be feasible to transmit an entire BIP21 URI as audio? If you were
to encode any extra information (such as amount), it would be useful to
include a checksum for the entire message. This checksum could possibly be
used instead of the checksum in the address.

Trevin

On Aug 8, 2016 3:06 PM, "Justin Newton via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Daniel,
>    Thanks for proposing this.  I think this could have some useful use
> cases as you state.  I was wondering what you would think to adding some
> additional tones to optionally denote an amount (in satoshis?).
>
> (FYI, actual link is here:  https://github.com/Dako300/BIP )
>
> Justin
>
> On Mon, Aug 8, 2016 at 2:22 PM, Daniel Hoffman via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> This is my BIP idea: a fast, robust, and standardized for representing
>> Bitcoin addresses over audio. It takes the binary representation of the
>> Bitcoin address (little endian), chops that up into 4 or 2 bit chunks
>> (depending on type, 2 bit only for low quality audio like american
>> telephone lines), and generates a tone based upon that value. This started
>> because I wanted an easy way to donate to podcasts that I listen to, and
>> having a Shazam-esque app (or a media player with this capability) that
>> gives me an address automatically would be wonderful for both the consumer
>> and producer. Comes with error correction built into the protocol
>>
>> You can see the full specification of the BIP on my GitHub page (
>> https://github.com/Dako300/BIP-0153).
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>
>
> --
>
> Justin W. Newton
> Founder/CEO
> Netki, Inc.
>
> justin@netki.com
> +1.818.261.4248
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

[-- Attachment #1.2: Type: text/html, Size: 4582 bytes --]

[-- Attachment #2: PastedGraphic-1.tiff --]
[-- Type: image/tiff, Size: 10972 bytes --]

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

[Daniel Hoffman]

[-- Attachment #1.1: Type: text/plain, Size: 2557 bytes --]

It wouldn't be feasible in the vast majority of cases, but I can't think of
a reason why it can't be built into the standard.

On Mon, Aug 8, 2016 at 5:59 PM, Trevin Hofmann via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Would it be feasible to transmit an entire BIP21 URI as audio? If you were
> to encode any extra information (such as amount), it would be useful to
> include a checksum for the entire message. This checksum could possibly be
> used instead of the checksum in the address.
>
> Trevin
>
> On Aug 8, 2016 3:06 PM, "Justin Newton via bitcoin-dev" <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Daniel,
>>    Thanks for proposing this.  I think this could have some useful use
>> cases as you state.  I was wondering what you would think to adding some
>> additional tones to optionally denote an amount (in satoshis?).
>>
>> (FYI, actual link is here:  https://github.com/Dako300/BIP )
>>
>> Justin
>>
>> On Mon, Aug 8, 2016 at 2:22 PM, Daniel Hoffman via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>>> This is my BIP idea: a fast, robust, and standardized for representing
>>> Bitcoin addresses over audio. It takes the binary representation of the
>>> Bitcoin address (little endian), chops that up into 4 or 2 bit chunks
>>> (depending on type, 2 bit only for low quality audio like american
>>> telephone lines), and generates a tone based upon that value. This started
>>> because I wanted an easy way to donate to podcasts that I listen to, and
>>> having a Shazam-esque app (or a media player with this capability) that
>>> gives me an address automatically would be wonderful for both the consumer
>>> and producer. Comes with error correction built into the protocol
>>>
>>> You can see the full specification of the BIP on my GitHub page (
>>> https://github.com/Dako300/BIP-0153).
>>>
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev@lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>>>
>>
>>
>> --
>>
>> Justin W. Newton
>> Founder/CEO
>> Netki, Inc.
>>
>> justin@netki.com
>> +1.818.261.4248
>>
>>
>>
>> _______________________________________________
>> 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
>
>

[-- Attachment #1.2: Type: text/html, Size: 5620 bytes --]

[-- Attachment #2: PastedGraphic-1.tiff --]
[-- Type: image/tiff, Size: 10972 bytes --]

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

[Daniel Hoffman]

[-- Attachment #1.1.1: Type: text/plain, Size: 3297 bytes --]

I have updated the GitHub a lot (changed tones to be less chirpy, fixed
some smalls) and made a couple of samples (see attachment for MP3 and FLAC
of both tone tables, first 16 then 4). Is this good enough to warrant an
official BIP number? I haven't built a decoder yet, but it seems like the
encoder is working properly (looked at Audacity, seems like it is working),
and some people on reddit want to "allow for decoding experiments"
<https://www.reddit.com/r/btc/comments/4wsn7v/bip_proposal_addresses_over_audio_thoughts/d69m3st>

What suggestions do you all have for it?

On Mon, Aug 8, 2016 at 8:50 PM, Daniel Hoffman <danielhoffman699@gmail.com>
wrote:

> It wouldn't be feasible in the vast majority of cases, but I can't think
> of a reason why it can't be built into the standard.
>
> On Mon, Aug 8, 2016 at 5:59 PM, Trevin Hofmann via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Would it be feasible to transmit an entire BIP21 URI as audio? If you
>> were to encode any extra information (such as amount), it would be useful
>> to include a checksum for the entire message. This checksum could possibly
>> be used instead of the checksum in the address.
>>
>> Trevin
>>
>> On Aug 8, 2016 3:06 PM, "Justin Newton via bitcoin-dev" <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>>> Daniel,
>>>    Thanks for proposing this.  I think this could have some useful use
>>> cases as you state.  I was wondering what you would think to adding some
>>> additional tones to optionally denote an amount (in satoshis?).
>>>
>>> (FYI, actual link is here:  https://github.com/Dako300/BIP )
>>>
>>> Justin
>>>
>>> On Mon, Aug 8, 2016 at 2:22 PM, Daniel Hoffman via bitcoin-dev <
>>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>>
>>>> This is my BIP idea: a fast, robust, and standardized for representing
>>>> Bitcoin addresses over audio. It takes the binary representation of the
>>>> Bitcoin address (little endian), chops that up into 4 or 2 bit chunks
>>>> (depending on type, 2 bit only for low quality audio like american
>>>> telephone lines), and generates a tone based upon that value. This started
>>>> because I wanted an easy way to donate to podcasts that I listen to, and
>>>> having a Shazam-esque app (or a media player with this capability) that
>>>> gives me an address automatically would be wonderful for both the consumer
>>>> and producer. Comes with error correction built into the protocol
>>>>
>>>> You can see the full specification of the BIP on my GitHub page (
>>>> https://github.com/Dako300/BIP-0153).
>>>>
>>>> _______________________________________________
>>>> bitcoin-dev mailing list
>>>> bitcoin-dev@lists.linuxfoundation.org
>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>>
>>>>
>>>
>>>
>>> --
>>>
>>> Justin W. Newton
>>> Founder/CEO
>>> Netki, Inc.
>>>
>>> justin@netki.com
>>> +1.818.261.4248
>>>
>>>
>>>
>>> _______________________________________________
>>> 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
>>
>>
>

[-- Attachment #1.1.2: Type: text/html, Size: 6996 bytes --]

[-- Attachment #1.2: PastedGraphic-1.tiff --]
[-- Type: image/tiff, Size: 10972 bytes --]

[-- Attachment #2: BIP_latest_custom_address.flac --]
[-- Type: audio/flac, Size: 2484566 bytes --]

[-- Attachment #3: BIP_latest_custom_address.mp3 --]
[-- Type: audio/mpeg, Size: 585142 bytes --]

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

[Jannes Faber]

[-- Attachment #1.1: Type: text/plain, Size: 4987 bytes --]

Wow. No value judgement, but 1980 called, they want their radio broadcast
for analogue modems back. Both very cool and very cringe worthy.

It sounds quite horrible tbh. Imagine this being as pervasive as bar and qr
codes. And it's as meaningful and unpleasant to the human ear as a qr code
is to the eye.

Please think of something like using a Mozart symphony as the carrier wave
onto which you modulate your signal. Let the notes last a little longer to
represent a 1 bit. Or change the tempo. Or add an echo. Make it so the
listener can interpret it as a generic not too annoying tune and not even
realise it's different every time without being an audiophile.

Maybe have a 100 different base tunes from mozart to hiphop so the user can
pick one suitable to their audience and context. Maybe have some that don't
interfere with human speech frequencies so narrator can keep talking right
over it.

I guess it may be tricky because you want your signal to survive
re-encoding as increased playback speeds.

Another consideration: you want a preamble that is very easy to detect, so
it doesn't cost a lot of CPU (battery) to have your podcast player
continuously scanning for these things.

Not sure all these wishes are possible at the same time, but surely there's
research around on some?.

On 10 Aug 2016 1:28 a.m., "Daniel Hoffman via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> I have updated the GitHub a lot (changed tones to be less chirpy, fixed
> some smalls) and made a couple of samples (see attachment for MP3 and FLAC
> of both tone tables, first 16 then 4). Is this good enough to warrant an
> official BIP number? I haven't built a decoder yet, but it seems like the
> encoder is working properly (looked at Audacity, seems like it is working),
> and some people on reddit want to "allow for decoding experiments"
> <https://www.reddit.com/r/btc/comments/4wsn7v/bip_proposal_addresses_over_audio_thoughts/d69m3st>
>
> What suggestions do you all have for it?
>
> On Mon, Aug 8, 2016 at 8:50 PM, Daniel Hoffman <danielhoffman699@gmail.com
> > wrote:
>
>> It wouldn't be feasible in the vast majority of cases, but I can't think
>> of a reason why it can't be built into the standard.
>>
>> On Mon, Aug 8, 2016 at 5:59 PM, Trevin Hofmann via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>>> Would it be feasible to transmit an entire BIP21 URI as audio? If you
>>> were to encode any extra information (such as amount), it would be useful
>>> to include a checksum for the entire message. This checksum could possibly
>>> be used instead of the checksum in the address.
>>>
>>> Trevin
>>>
>>> On Aug 8, 2016 3:06 PM, "Justin Newton via bitcoin-dev" <
>>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>>
>>>> Daniel,
>>>>    Thanks for proposing this.  I think this could have some useful use
>>>> cases as you state.  I was wondering what you would think to adding some
>>>> additional tones to optionally denote an amount (in satoshis?).
>>>>
>>>> (FYI, actual link is here:  https://github.com/Dako300/BIP )
>>>>
>>>> Justin
>>>>
>>>> On Mon, Aug 8, 2016 at 2:22 PM, Daniel Hoffman via bitcoin-dev <
>>>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>>>
>>>>> This is my BIP idea: a fast, robust, and standardized for representing
>>>>> Bitcoin addresses over audio. It takes the binary representation of the
>>>>> Bitcoin address (little endian), chops that up into 4 or 2 bit chunks
>>>>> (depending on type, 2 bit only for low quality audio like american
>>>>> telephone lines), and generates a tone based upon that value. This started
>>>>> because I wanted an easy way to donate to podcasts that I listen to, and
>>>>> having a Shazam-esque app (or a media player with this capability) that
>>>>> gives me an address automatically would be wonderful for both the consumer
>>>>> and producer. Comes with error correction built into the protocol
>>>>>
>>>>> You can see the full specification of the BIP on my GitHub page (
>>>>> https://github.com/Dako300/BIP-0153).
>>>>>
>>>>> _______________________________________________
>>>>> bitcoin-dev mailing list
>>>>> bitcoin-dev@lists.linuxfoundation.org
>>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> Justin W. Newton
>>>> Founder/CEO
>>>> Netki, Inc.
>>>>
>>>> justin@netki.com
>>>> +1.818.261.4248
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>
>

[-- Attachment #1.2: Type: text/html, Size: 9225 bytes --]

[-- Attachment #2: PastedGraphic-1.tiff --]
[-- Type: image/tiff, Size: 10972 bytes --]

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

[Chris Riley]

[-- Attachment #1.1: Type: text/plain, Size: 4238 bytes --]

Have you checked AudioModem out:
https://github.com/applidium/AudioModem

Or Chirp:
http://www.chirp.io/faq/

Or this Network World article (particularly the last portion on bitcoin):
http://www.networkworld.com/article/2956450/smartphones/sending-data-over-sound-revisited.html
and
http://www.networkworld.com/article/2689597/opensource-subnet/how-a-tv-network-is-being-used-to-move-financial-transactions.html

Instead of re-inventing the wheel, perhaps take a look at them.  Or at
least to see their design choices and rationale.

Cheers!


On Tue, Aug 9, 2016 at 7:06 PM, Daniel Hoffman via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> I have updated the GitHub a lot (changed tones to be less chirpy, fixed
> some smalls) and made a couple of samples (see attachment for MP3 and FLAC
> of both tone tables, first 16 then 4). Is this good enough to warrant an
> official BIP number? I haven't built a decoder yet, but it seems like the
> encoder is working properly (looked at Audacity, seems like it is working),
> and some people on reddit want to "allow for decoding experiments"
> <https://www.reddit.com/r/btc/comments/4wsn7v/bip_proposal_addresses_over_audio_thoughts/d69m3st>
>
> What suggestions do you all have for it?
>
> On Mon, Aug 8, 2016 at 8:50 PM, Daniel Hoffman <danielhoffman699@gmail.com
> > wrote:
>
>> It wouldn't be feasible in the vast majority of cases, but I can't think
>> of a reason why it can't be built into the standard.
>>
>> On Mon, Aug 8, 2016 at 5:59 PM, Trevin Hofmann via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>>> Would it be feasible to transmit an entire BIP21 URI as audio? If you
>>> were to encode any extra information (such as amount), it would be useful
>>> to include a checksum for the entire message. This checksum could possibly
>>> be used instead of the checksum in the address.
>>>
>>> Trevin
>>>
>>> On Aug 8, 2016 3:06 PM, "Justin Newton via bitcoin-dev" <
>>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>>
>>>> Daniel,
>>>>    Thanks for proposing this.  I think this could have some useful use
>>>> cases as you state.  I was wondering what you would think to adding some
>>>> additional tones to optionally denote an amount (in satoshis?).
>>>>
>>>> (FYI, actual link is here:  https://github.com/Dako300/BIP )
>>>>
>>>> Justin
>>>>
>>>> On Mon, Aug 8, 2016 at 2:22 PM, Daniel Hoffman via bitcoin-dev <
>>>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>>>
>>>>> This is my BIP idea: a fast, robust, and standardized for representing
>>>>> Bitcoin addresses over audio. It takes the binary representation of the
>>>>> Bitcoin address (little endian), chops that up into 4 or 2 bit chunks
>>>>> (depending on type, 2 bit only for low quality audio like american
>>>>> telephone lines), and generates a tone based upon that value. This started
>>>>> because I wanted an easy way to donate to podcasts that I listen to, and
>>>>> having a Shazam-esque app (or a media player with this capability) that
>>>>> gives me an address automatically would be wonderful for both the consumer
>>>>> and producer. Comes with error correction built into the protocol
>>>>>
>>>>> You can see the full specification of the BIP on my GitHub page (
>>>>> https://github.com/Dako300/BIP-0153).
>>>>>
>>>>> _______________________________________________
>>>>> bitcoin-dev mailing list
>>>>> bitcoin-dev@lists.linuxfoundation.org
>>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> Justin W. Newton
>>>> Founder/CEO
>>>> Netki, Inc.
>>>>
>>>> justin@netki.com
>>>> +1.818.261.4248
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>
>

[-- Attachment #1.2: Type: text/html, Size: 8925 bytes --]

[-- Attachment #2: PastedGraphic-1.tiff --]
[-- Type: image/tiff, Size: 10972 bytes --]

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

[Luke Dashjr]

On Tuesday, August 09, 2016 11:06:20 PM Daniel Hoffman via bitcoin-dev wrote:
> Is this good enough to warrant an official BIP number?

Yeah, let's call it BIP 170.

Next step is to:
- Fix the BIP number in the file
- Format it in the usual BIP mediawiki format instead of markdown
- Add it to a fork of the bitcoin/bips git repository
- Open a pull request against bitcoin/bips

P.S. Why are telephones considered 4-tone? DTMF is 16-tone IIRC?

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

[Thomas Daede]

If this is just encoding BIP-21 addresses, it is basically an "audio QR
code". In this case, does publishing it as a BIP still make sense? (Not
to imply that it doesn't, but it's something you should consider.)

Please look at existing implementations of audio modems when creating
your design. A lot of this work has been done many times before, so
there is a lot to learn from.

Your selected frequencies are harmonics of each other, meaning nonlinear
distortion will make detection more difficult. The Bell 202 and similar
modem standards chose AFSK frequencies to minimize interference.

Repeating a message multiple times is a very inefficient method of error
recovery. It works, but there may be better techniques, such as trellis
modulation or other convolutional codes.

Defining channel models to simulate your various use cases will help a
lot to determine if you have met your requirements.

- Thomas

P.S. I also briefly considered audio to exchange transactions with a
hardware wallet. Using GNU Radio made the implementation much easier.

On 08/09/2016 04:06 PM, Daniel Hoffman via bitcoin-dev wrote:
> I have updated the GitHub a lot (changed tones to be less chirpy, fixed
> some smalls) and made a couple of samples (see attachment for MP3 and
> FLAC of both tone tables, first 16 then 4). Is this good enough to
> warrant an official BIP number? I haven't built a decoder yet, but it
> seems like the encoder is working properly (looked at Audacity, seems
> like it is working), and some people on reddit want to "allow for
> decoding experiments"
> <https://www.reddit.com/r/btc/comments/4wsn7v/bip_proposal_addresses_over_audio_thoughts/d69m3st>
> 
> What suggestions do you all have for it?
> 
> On Mon, Aug 8, 2016 at 8:50 PM, Daniel Hoffman
> <danielhoffman699@gmail.com <mailto:danielhoffman699@gmail.com>> wrote:
> 
>     It wouldn't be feasible in the vast majority of cases, but I can't
>     think of a reason why it can't be built into the standard.
> 
>     On Mon, Aug 8, 2016 at 5:59 PM, Trevin Hofmann via bitcoin-dev
>     <bitcoin-dev@lists.linuxfoundation.org
>     <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
> 
>         Would it be feasible to transmit an entire BIP21 URI as audio?
>         If you were to encode any extra information (such as amount), it
>         would be useful to include a checksum for the entire message.
>         This checksum could possibly be used instead of the checksum in
>         the address.
> 
>         Trevin
> 
> 
>         On Aug 8, 2016 3:06 PM, "Justin Newton via bitcoin-dev"
>         <bitcoin-dev@lists.linuxfoundation.org
>         <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
> 
>             Daniel,
>                Thanks for proposing this.  I think this could have some
>             useful use cases as you state.  I was wondering what you
>             would think to adding some additional tones to optionally
>             denote an amount (in satoshis?).
> 
>             (FYI, actual link is here:  https://github.com/Dako300/BIP
>             <https://github.com/Dako300/BIP> )
> 
>             Justin
> 
>             On Mon, Aug 8, 2016 at 2:22 PM, Daniel Hoffman via
>             bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org
>             <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
> 
>                 This is my BIP idea: a fast, robust, and standardized
>                 for representing Bitcoin addresses over audio. It takes
>                 the binary representation of the Bitcoin address (little
>                 endian), chops that up into 4 or 2 bit chunks (depending
>                 on type, 2 bit only for low quality audio like american
>                 telephone lines), and generates a tone based upon that
>                 value. This started because I wanted an easy way to
>                 donate to podcasts that I listen to, and having a
>                 Shazam-esque app (or a media player with this
>                 capability) that gives me an address automatically would
>                 be wonderful for both the consumer and producer. Comes
>                 with error correction built into the protocol
> 
>                 You can see the full specification of the BIP on my
>                 GitHub page (https://github.com/Dako300/BIP-0153
>                 <https://github.com/Dako300/BIP-0153>).
> 
>                 _______________________________________________
>                 bitcoin-dev mailing list
>                 bitcoin-dev@lists.linuxfoundation.org
>                 <mailto:bitcoin-dev@lists.linuxfoundation.org>
>                 https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>                 <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
> 
> 
> 
> 
>             -- 
> 
>             Justin W. Newton
>             Founder/CEO
>             Netki, Inc.
> 
>             justin@netki.com <mailto:justin@netki.com>
>             +1.818.261.4248 <tel:+1.818.261.4248>
> 
> 
> 
>             _______________________________________________
>             bitcoin-dev mailing list
>             bitcoin-dev@lists.linuxfoundation.org
>             <mailto:bitcoin-dev@lists.linuxfoundation.org>
>             https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>             <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
> 
> 
>         _______________________________________________
>         bitcoin-dev mailing list
>         bitcoin-dev@lists.linuxfoundation.org
>         <mailto:bitcoin-dev@lists.linuxfoundation.org>
>         https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>         <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]

[-- Attachment #1: Type: text/plain, Size: 7275 bytes --]

Thomas
In all honesty, I shouldn't have added the multiple feature. It should
always stay to one and have the Bitcoin address's built in checksum do all
of the heavy lifting (or implement another checksum into the protocol).
Having said that, it would make the most sense to not include BIP21
requests. The frequencies that are going to be used are prone to being
changed (probably moving them into the ultrasound range, at least for the
16 tones)

Luke Dashjr
I thought it was only 12, will change it accordingly.

Chris
I looked at Audio Modem and will probably look at the others soon as well.

The general idea of this BIP is to see if you all even approve of the idea
of sending Bitcoin addresses over sound waves. I will push it into the
ultrasound, and I might implement phase modulation.

On Tue, Aug 9, 2016 at 8:09 PM, Thomas Daede via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> If this is just encoding BIP-21 addresses, it is basically an "audio QR
> code". In this case, does publishing it as a BIP still make sense? (Not
> to imply that it doesn't, but it's something you should consider.)
>
> Please look at existing implementations of audio modems when creating
> your design. A lot of this work has been done many times before, so
> there is a lot to learn from.
>
> Your selected frequencies are harmonics of each other, meaning nonlinear
> distortion will make detection more difficult. The Bell 202 and similar
> modem standards chose AFSK frequencies to minimize interference.
>
> Repeating a message multiple times is a very inefficient method of error
> recovery. It works, but there may be better techniques, such as trellis
> modulation or other convolutional codes.
>
> Defining channel models to simulate your various use cases will help a
> lot to determine if you have met your requirements.
>
> - Thomas
>
> P.S. I also briefly considered audio to exchange transactions with a
> hardware wallet. Using GNU Radio made the implementation much easier.
>
> On 08/09/2016 04:06 PM, Daniel Hoffman via bitcoin-dev wrote:
> > I have updated the GitHub a lot (changed tones to be less chirpy, fixed
> > some smalls) and made a couple of samples (see attachment for MP3 and
> > FLAC of both tone tables, first 16 then 4). Is this good enough to
> > warrant an official BIP number? I haven't built a decoder yet, but it
> > seems like the encoder is working properly (looked at Audacity, seems
> > like it is working), and some people on reddit want to "allow for
> > decoding experiments"
> > <https://www.reddit.com/r/btc/comments/4wsn7v/bip_proposal_
> addresses_over_audio_thoughts/d69m3st>
> >
> > What suggestions do you all have for it?
> >
> > On Mon, Aug 8, 2016 at 8:50 PM, Daniel Hoffman
> > <danielhoffman699@gmail.com <mailto:danielhoffman699@gmail.com>> wrote:
> >
> >     It wouldn't be feasible in the vast majority of cases, but I can't
> >     think of a reason why it can't be built into the standard.
> >
> >     On Mon, Aug 8, 2016 at 5:59 PM, Trevin Hofmann via bitcoin-dev
> >     <bitcoin-dev@lists.linuxfoundation.org
> >     <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
> >
> >         Would it be feasible to transmit an entire BIP21 URI as audio?
> >         If you were to encode any extra information (such as amount), it
> >         would be useful to include a checksum for the entire message.
> >         This checksum could possibly be used instead of the checksum in
> >         the address.
> >
> >         Trevin
> >
> >
> >         On Aug 8, 2016 3:06 PM, "Justin Newton via bitcoin-dev"
> >         <bitcoin-dev@lists.linuxfoundation.org
> >         <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
> >
> >             Daniel,
> >                Thanks for proposing this.  I think this could have some
> >             useful use cases as you state.  I was wondering what you
> >             would think to adding some additional tones to optionally
> >             denote an amount (in satoshis?).
> >
> >             (FYI, actual link is here:  https://github.com/Dako300/BIP
> >             <https://github.com/Dako300/BIP> )
> >
> >             Justin
> >
> >             On Mon, Aug 8, 2016 at 2:22 PM, Daniel Hoffman via
> >             bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org
> >             <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
> >
> >                 This is my BIP idea: a fast, robust, and standardized
> >                 for representing Bitcoin addresses over audio. It takes
> >                 the binary representation of the Bitcoin address (little
> >                 endian), chops that up into 4 or 2 bit chunks (depending
> >                 on type, 2 bit only for low quality audio like american
> >                 telephone lines), and generates a tone based upon that
> >                 value. This started because I wanted an easy way to
> >                 donate to podcasts that I listen to, and having a
> >                 Shazam-esque app (or a media player with this
> >                 capability) that gives me an address automatically would
> >                 be wonderful for both the consumer and producer. Comes
> >                 with error correction built into the protocol
> >
> >                 You can see the full specification of the BIP on my
> >                 GitHub page (https://github.com/Dako300/BIP-0153
> >                 <https://github.com/Dako300/BIP-0153>).
> >
> >                 _______________________________________________
> >                 bitcoin-dev mailing list
> >                 bitcoin-dev@lists.linuxfoundation.org
> >                 <mailto:bitcoin-dev@lists.linuxfoundation.org>
> >                 https://lists.linuxfoundation.
> org/mailman/listinfo/bitcoin-dev
> >                 <https://lists.linuxfoundation.org/mailman/
> listinfo/bitcoin-dev>
> >
> >
> >
> >
> >             --
> >
> >             Justin W. Newton
> >             Founder/CEO
> >             Netki, Inc.
> >
> >             justin@netki.com <mailto:justin@netki.com>
> >             +1.818.261.4248 <tel:+1.818.261.4248>
> >
> >
> >
> >             _______________________________________________
> >             bitcoin-dev mailing list
> >             bitcoin-dev@lists.linuxfoundation.org
> >             <mailto:bitcoin-dev@lists.linuxfoundation.org>
> >             https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-
> dev
> >             <https://lists.linuxfoundation.org/mailman/
> listinfo/bitcoin-dev>
> >
> >
> >         _______________________________________________
> >         bitcoin-dev mailing list
> >         bitcoin-dev@lists.linuxfoundation.org
> >         <mailto:bitcoin-dev@lists.linuxfoundation.org>
> >         https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >         <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
>

[-- Attachment #2: Type: text/html, Size: 12019 bytes --]

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

[Gregory Maxwell]

[-- Attachment #1: Type: text/plain, Size: 1210 bytes --]

On Tue, Aug 9, 2016 at 11:06 PM, Daniel Hoffman via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> I have updated the GitHub a lot (changed tones to be less chirpy, fixed
> some smalls) and made a couple of samples (see attachment for MP3 and FLAC
> of both tone tables, first 16 then 4). Is this good enough to warrant an
> official BIP number? I haven't built a decoder yet, but it seems like the
> encoder is working properly (looked at Audacity, seems like it is working),
> and some people on reddit want to "allow for decoding experiments"
> <https://www.reddit.com/r/btc/comments/4wsn7v/bip_proposal_addresses_over_audio_thoughts/d69m3st>
>
> What suggestions do you all have for it?
>


With DSP hat on, your decoder for noisy/distorted channels will be 99.9% of
the complexity and will completely control the design of the encoder.

It's not a proposal yet without a decoder, it's just an idea.  FSK modems
microphone-channel (terrible multipath) is quite challenging and several
other parties have tried to do bitcoin info over audio in the past without
success.

It's very interesting, but I think you do need to go through and get the
whole thing working to really gauge viability.

[-- Attachment #2: Type: text/html, Size: 1732 bytes --]

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

[Tier Nolan]

[-- Attachment #1: Type: text/plain, Size: 196 bytes --]

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.

[-- Attachment #2: Type: text/html, Size: 235 bytes --]

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

[Erik Aronesty]

[-- Attachment #1: Type: text/plain, Size: 1247 bytes --]

NOTE:

Addresses aren't really meant to be broadcast - you should probably be
encoding BIP32 public seeds, not addresses.

OR simply:

- Send btc to rick@q32.com
- TXT record _btc.rick.q32.com is queried (_<coin-code>.<name>.<domain>)
- DNS-SEC validation is *required*
- TXT record contains addr:[<bip32-pub-seed>]

Then you can just say, in the podcast, "Send your bitcoin donations to
rick@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
>
>

[-- Attachment #2: Type: text/html, Size: 2072 bytes --]

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

[Theo Chino]

[-- Attachment #1: Type: text/plain, Size: 1729 bytes --]

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 rick@q32.com
> - TXT record _btc.rick.q32.com is queried (_<coin-code>.<name>.<domain>)
> - DNS-SEC validation is *required*
> - TXT record contains addr:[<bip32-pub-seed>]
>
> Then you can just say, in the podcast, "Send your bitcoin donations to
> rick@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
>
>

[-- Attachment #2: Type: text/html, Size: 3170 bytes --]

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

[Daniel Hoffman]

[-- Attachment #1: Type: text/plain, Size: 2234 bytes --]

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 rick@q32.com
>> - TXT record _btc.rick.q32.com is queried (_<coin-code>.<name>.<domain>)
>> - DNS-SEC validation is *required*
>> - TXT record contains addr:[<bip32-pub-seed>]
>>
>> Then you can just say, in the podcast, "Send your bitcoin donations to
>> rick@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
>
>

[-- Attachment #2: Type: text/html, Size: 4220 bytes --]

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

[Erik Aronesty]

[-- Attachment #1: Type: text/plain, Size: 2734 bytes --]

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 rick@q32.com
>>> - TXT record _btc.rick.q32.com is queried (_<coin-code>.<name>.<domain>)
>>> - DNS-SEC validation is *required*
>>> - TXT record contains addr:[<bip32-pub-seed>]
>>>
>>> Then you can just say, in the podcast, "Send your bitcoin donations to
>>> rick@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
>
>

[-- Attachment #2: Type: text/html, Size: 5146 bytes --]

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

[Pieter Wuille]

On Wed, Aug 10, 2016 at 7:28 PM, Erik Aronesty via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> 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

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

[Daniel Hoffman]

[-- Attachment #1: Type: text/plain, Size: 836 bytes --]

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
> <bitcoin-dev@lists.linuxfoundation.org> 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
>

[-- Attachment #2: Type: text/html, Size: 1444 bytes --]

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

[James MacWhyte]

[-- Attachment #1: Type: text/plain, Size: 1764 bytes --]

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
>> <bitcoin-dev@lists.linuxfoundation.org> 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
>

[-- Attachment #2: Type: text/html, Size: 2894 bytes --]

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

[Erik Aronesty]

[-- Attachment #1: Type: text/plain, Size: 708 bytes --]

Sorr, I thought there was some BIP for a public seed such that someone can
generate new random addresses, but cannot trivially verify whether an
address was derived from the seed.

On Wed, Aug 10, 2016 at 1:38 PM, Pieter Wuille <pieter.wuille@gmail.com>
wrote:

> On Wed, Aug 10, 2016 at 7:28 PM, Erik Aronesty via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> 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
>

[-- Attachment #2: Type: text/html, Size: 1201 bytes --]

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

[Tier Nolan]

[-- Attachment #1: Type: text/plain, Size: 1664 bytes --]

On Thu, Aug 11, 2016 at 2:55 PM, Erik Aronesty via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Sorr, I thought there was some BIP for a public seed such that someone can
> generate new random addresses, but cannot trivially verify whether an
> address was derived from the seed.
>

If you take a public key and multiply it by k, then the recipient can work
out the private key by multiplying their master private key by k.

If k is random, then the recipient wouldn't be able to work it out, but if
it is non-random, then everyone else can work it out.  You need some way to
get k to the recipient without others figuring it out.

This means either the system is interactive or you use a shared secret.

The info about the shared secret is included in the scriptPubKey (or the
more socially conscientious option, an OP_RETURN).

The address would indicate the master public key.

master_public = master_private * G

The transaction contains k*G.

Both sides can compute the shared secret.

secret = k*master_private*G = master_private*k*G

<encode(k*G)> DROP DUP HASH160 <hash160(encode(secret + pub key))>
EQUALVERIFY CHECKSIG

This adds 34 bytes to the scriptPubKey.

This is pretty heavy for scanning for transactions sent to you.  You have
to check every transaction output to see if it is the given template.  Then
you have to do an ECC multiply to compute the shared secret.  Once you have
the shared secret, you need to do an ECC addition and a hash to figure out
if it matches the public key hash in the output.

This is approx one ECC multiply per output and is similar CPU load to what
you would need to do to actually verify a block.

[-- Attachment #2: Type: text/html, Size: 2251 bytes --]

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

[Erik Aronesty]

[-- Attachment #1: Type: text/plain, Size: 2315 bytes --]

Can't have shared secrets or interactivity for a public address to have the
love it needs.

Still not sure how you can take a BIP32 public seed and figure out if an
address was derived from it though.   I mean, wouldn't I have to compute
all 2^31 possible public child addresses?





On Thu, Aug 11, 2016 at 11:13 AM, Tier Nolan via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Thu, Aug 11, 2016 at 2:55 PM, Erik Aronesty via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Sorr, I thought there was some BIP for a public seed such that someone
>> can generate new random addresses, but cannot trivially verify whether an
>> address was derived from the seed.
>>
>
> If you take a public key and multiply it by k, then the recipient can work
> out the private key by multiplying their master private key by k.
>
> If k is random, then the recipient wouldn't be able to work it out, but if
> it is non-random, then everyone else can work it out.  You need some way to
> get k to the recipient without others figuring it out.
>
> This means either the system is interactive or you use a shared secret.
>
> The info about the shared secret is included in the scriptPubKey (or the
> more socially conscientious option, an OP_RETURN).
>
> The address would indicate the master public key.
>
> master_public = master_private * G
>
> The transaction contains k*G.
>
> Both sides can compute the shared secret.
>
> secret = k*master_private*G = master_private*k*G
>
> <encode(k*G)> DROP DUP HASH160 <hash160(encode(secret + pub key))>
> EQUALVERIFY CHECKSIG
>
> This adds 34 bytes to the scriptPubKey.
>
> This is pretty heavy for scanning for transactions sent to you.  You have
> to check every transaction output to see if it is the given template.  Then
> you have to do an ECC multiply to compute the shared secret.  Once you have
> the shared secret, you need to do an ECC addition and a hash to figure out
> if it matches the public key hash in the output.
>
> This is approx one ECC multiply per output and is similar CPU load to what
> you would need to do to actually verify a block.
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

[-- Attachment #2: Type: text/html, Size: 3468 bytes --]

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

[Gregory Maxwell]

On Thu, Aug 11, 2016 at 8:37 PM, Erik Aronesty via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> Still not sure how you can take a BIP32 public seed and figure out if an
> address was derived from it though.   I mean, wouldn't I have to compute all
> 2^31 possible public child addresses?

Which would take a quad core laptop about 8 hours with competent software

And presumably you're not using the whole 2^31 space else the receiver
also has to do that computation...

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

[Erik Aronesty]

[-- Attachment #1: Type: text/plain, Size: 1077 bytes --]

I'm imagining a "publishable seed" such that:

 - someone can derive a random bitcoin address from it -  and send funds to
it.
 - the possible derived address space is large enough that generating all
possible addresses would be a barrier
 - the receiver, however, knowing the private key, can easily scan the
blockchain fairly efficiently and determine which addresses he has the keys
to
 - another interested party cannot easily do so

Perhaps homomorphic encryption may need to be involved?


On Thu, Aug 11, 2016 at 8:36 PM, Gregory Maxwell <greg@xiph.org> wrote:

> On Thu, Aug 11, 2016 at 8:37 PM, Erik Aronesty via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
> > Still not sure how you can take a BIP32 public seed and figure out if an
> > address was derived from it though.   I mean, wouldn't I have to compute
> all
> > 2^31 possible public child addresses?
>
> Which would take a quad core laptop about 8 hours with competent software
>
> And presumably you're not using the whole 2^31 space else the receiver
> also has to do that computation...
>

[-- Attachment #2: Type: text/html, Size: 1623 bytes --]

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

[Jorge Timón]

[-- Attachment #1: Type: text/plain, Size: 2217 bytes --]

No, anyone with the bip32 public seed can do the same as the receiver as
"watch only". The only difference is rhat the receiver can actually spend
the coins. As gmaxwell explained, if it's expensive for everyone, it will
be also expensive for the receiver (assuming no interaction after the bip32
public seed is transfered).

Something different would be to give a different bip32 public seed to each
payer.  That way they can simply start with zero an increment with each new
payment. With those assumptions, the receiver could start listening to new
addresses only after they receive something in the previous address.

Probably not useful for this case, just thinking out loud about using bip32
public seeds instead of one use addresses when there's going to be several
payments from the same payer to the payee.

On Aug 12, 2016 2:37 PM, "Erik Aronesty via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> I'm imagining a "publishable seed" such that:
>
>  - someone can derive a random bitcoin address from it -  and send funds
to it.
>  - the possible derived address space is large enough that generating all
possible addresses would be a barrier
>  - the receiver, however, knowing the private key, can easily scan the
blockchain fairly efficiently and determine which addresses he has the keys
to
>  - another interested party cannot easily do so
>
> Perhaps homomorphic encryption may need to be involved?
>
>
> On Thu, Aug 11, 2016 at 8:36 PM, Gregory Maxwell <greg@xiph.org> wrote:
>>
>> On Thu, Aug 11, 2016 at 8:37 PM, Erik Aronesty via bitcoin-dev
>> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>> > Still not sure how you can take a BIP32 public seed and figure out if
an
>> > address was derived from it though.   I mean, wouldn't I have to
compute all
>> > 2^31 possible public child addresses?
>>
>> Which would take a quad core laptop about 8 hours with competent software
>>
>> And presumably you're not using the whole 2^31 space else the receiver
>> also has to do that computation...
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[-- Attachment #2: Type: text/html, Size: 2946 bytes --]

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

[James MacWhyte]

[-- Attachment #1: Type: text/plain, Size: 1645 bytes --]

For reasons others have pointed out, it's not really plausible.

Either way, this has nothing to do with transmitting data over audio.
Please start a new thread if you want to discuss your idea instead of
hijacking this one. Thanks ;)

On Fri, Aug 12, 2016, 05:36 Erik Aronesty via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> I'm imagining a "publishable seed" such that:
>
>  - someone can derive a random bitcoin address from it -  and send funds
> to it.
>  - the possible derived address space is large enough that generating all
> possible addresses would be a barrier
>  - the receiver, however, knowing the private key, can easily scan the
> blockchain fairly efficiently and determine which addresses he has the keys
> to
>  - another interested party cannot easily do so
>
> Perhaps homomorphic encryption may need to be involved?
>
>
> On Thu, Aug 11, 2016 at 8:36 PM, Gregory Maxwell <greg@xiph.org> wrote:
>
>> On Thu, Aug 11, 2016 at 8:37 PM, Erik Aronesty via bitcoin-dev
>> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>> > Still not sure how you can take a BIP32 public seed and figure out if an
>> > address was derived from it though.   I mean, wouldn't I have to
>> compute all
>> > 2^31 possible public child addresses?
>>
>> Which would take a quad core laptop about 8 hours with competent software
>>
>> And presumably you're not using the whole 2^31 space else the receiver
>> also has to do that computation...
>>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[-- Attachment #2: Type: text/html, Size: 2629 bytes --]

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

[Daniel Hoffman]

[-- Attachment #1: Type: text/plain, Size: 705 bytes --]

I started work on the decoder. It works by comparing each cycle of the sine
wave recorded with a certain frequency (freq_t). The function that does
this currently returns the last sample that falls in that range over all
samples. The longest chain to match up with a certain frequency the best is
interpreted as that frequency (assuming it passes an entrance floor to
separate it from static).  I will probably extrapolate the sine wave to
more samples (320 kbps+), but this works OK just for testing. I am also
prepping the docs per the official BIP spec.

GitHub is https://github.com/Dako300/BIP-0170

Is it okay to host the BIP on my own GitHub, or do I need to host it on a
more official repository?

[-- Attachment #2: Type: text/html, Size: 829 bytes --]