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

[Daniel Hoffman via bitcoin-dev]

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).

[Justin Newton via bitcoin-dev]

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 <

Post by Daniel Hoffman via bitcoin-dev
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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[Daniel Hoffman via bitcoin-dev]

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 <

Post by Justin Newton via bitcoin-dev
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 <

Post by Daniel Hoffman via bitcoin-dev
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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

--
Justin W. Newton
Founder/CEO
Netki, Inc.
+1.818.261.4248
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[Trevin Hofmann via bitcoin-dev]

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" <

Post by Justin Newton via bitcoin-dev
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 <

Post by Daniel Hoffman via bitcoin-dev
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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

--
Justin W. Newton
Founder/CEO
Netki, Inc.
+1.818.261.4248
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[Daniel Hoffman via bitcoin-dev]

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 <

Post by Trevin Hofmann via bitcoin-dev
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" <

Post by Justin Newton via bitcoin-dev
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 <

Post by Daniel Hoffman via bitcoin-dev
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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

--
Justin W. Newton
Founder/CEO
Netki, Inc.
+1.818.261.4248
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[Daniel Hoffman via bitcoin-dev]

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?

Post by Daniel Hoffman via bitcoin-dev
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 <

Post by Trevin Hofmann via bitcoin-dev
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" <

Post by Justin Newton via bitcoin-dev
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 <

Post by Daniel Hoffman via bitcoin-dev
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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

--
Justin W. Newton
Founder/CEO
Netki, Inc.
+1.818.261.4248
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[Jannes Faber via bitcoin-dev]

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" <

Post by Daniel Hoffman via bitcoin-dev
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?

Post by Daniel Hoffman via bitcoin-dev
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 <

Post by Trevin Hofmann via bitcoin-dev
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" <

Post by Justin Newton via bitcoin-dev
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 <

Post by Daniel Hoffman via bitcoin-dev
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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

--
Justin W. Newton
Founder/CEO
Netki, Inc.
+1.818.261.4248
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[Luke Dashjr via bitcoin-dev]

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?

[Chris Riley via bitcoin-dev]

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 <

Post by Daniel Hoffman via bitcoin-dev
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?

Post by Daniel Hoffman via bitcoin-dev
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 <

Post by Trevin Hofmann via bitcoin-dev
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" <

Post by Justin Newton via bitcoin-dev
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 <

Post by Daniel Hoffman via bitcoin-dev
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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

--
Justin W. Newton
Founder/CEO
Netki, Inc.
+1.818.261.4248
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[Thomas Daede via bitcoin-dev]

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.

Post by Daniel Hoffman via bitcoin-dev
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
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
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"
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
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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
<https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
--
Justin W. Newton
Founder/CEO
Netki, Inc.
+1.818.261.4248 <tel:[phone]>
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
<https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
<https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[Daniel Hoffman via bitcoin-dev]

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 <

Post by Thomas Daede via bitcoin-dev
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.

Post by Daniel Hoffman via bitcoin-dev
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>

Post by Daniel Hoffman via bitcoin-dev
What suggestions do you all have for it?
On Mon, Aug 8, 2016 at 8:50 PM, Daniel Hoffman
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
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"
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
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
https://lists.linuxfoundation.

org/mailman/listinfo/bitcoin-dev

Post by Daniel Hoffman via bitcoin-dev
<https://lists.linuxfoundation.org/mailman/

listinfo/bitcoin-dev>

Post by Daniel Hoffman via bitcoin-dev
--
Justin W. Newton
Founder/CEO
Netki, Inc.
+1.818.261.4248 <tel:[phone]>
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-

dev

Post by Daniel Hoffman via bitcoin-dev
<https://lists.linuxfoundation.org/mailman/

listinfo/bitcoin-dev>

Post by Daniel Hoffman via bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
<https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[Gregory Maxwell via bitcoin-dev]

On Tue, Aug 9, 2016 at 11:06 PM, Daniel Hoffman via bitcoin-dev <

Post by Daniel Hoffman via bitcoin-dev
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.

[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.

[Erik Aronesty via bitcoin-dev]

NOTE:

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

OR simply:

- Send btc to ***@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
***@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 <

Post by 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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[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 <

Post by Erik Aronesty via bitcoin-dev
Addresses aren't really meant to be broadcast - you should probably be
encoding BIP32 public seeds, not addresses.
- 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
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 <

Post by 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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[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 <

Post by 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 <

Post by Erik Aronesty via bitcoin-dev
Addresses aren't really meant to be broadcast - you should probably be
encoding BIP32 public seeds, not addresses.
- 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
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 <

Post by 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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[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" <

Post by 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 <

Post by 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 <

Post by Erik Aronesty via bitcoin-dev
Addresses aren't really meant to be broadcast - you should probably be
encoding BIP32 public seeds, not addresses.
- 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
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 <

Post by 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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[Pieter Wuille via bitcoin-dev]

On Wed, Aug 10, 2016 at 7:28 PM, 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.

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.

[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" <

Post by Pieter Wuille via bitcoin-dev
On Wed, Aug 10, 2016 at 7:28 PM, Erik Aronesty via bitcoin-dev

Post by Erik Aronesty via bitcoin-dev
By sending a public seed, there's no way for someone to use the

transmitted

Post by Erik Aronesty via bitcoin-dev
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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[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 <

Post by 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" <

Post by Pieter Wuille via bitcoin-dev
On Wed, Aug 10, 2016 at 7:28 PM, Erik Aronesty via bitcoin-dev

Post by Erik Aronesty via bitcoin-dev
By sending a public seed, there's no way for someone to use the

transmitted

Post by Erik Aronesty via bitcoin-dev
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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[Erik Aronesty via bitcoin-dev]

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.

Post by Pieter Wuille via bitcoin-dev
On Wed, Aug 10, 2016 at 7:28 PM, Erik Aronesty via bitcoin-dev

Post by Erik Aronesty via bitcoin-dev
By sending a public seed, there's no way for someone to use the

transmitted

Post by Erik Aronesty via bitcoin-dev
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

[Tier Nolan via bitcoin-dev]

On Thu, Aug 11, 2016 at 2:55 PM, Erik Aronesty via bitcoin-dev <

Post by Erik Aronesty via bitcoin-dev
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.

[Erik Aronesty via bitcoin-dev]

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 <

Post by Tier Nolan via bitcoin-dev
On Thu, Aug 11, 2016 at 2:55 PM, Erik Aronesty via bitcoin-dev <

Post by Erik Aronesty via bitcoin-dev
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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[Gregory Maxwell via bitcoin-dev]

On Thu, Aug 11, 2016 at 8:37 PM, Erik Aronesty via bitcoin-dev

Post by Erik Aronesty via bitcoin-dev
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...

[Erik Aronesty via bitcoin-dev]

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?

Post by Gregory Maxwell via bitcoin-dev
On Thu, Aug 11, 2016 at 8:37 PM, Erik Aronesty via bitcoin-dev

Post by Erik Aronesty via bitcoin-dev
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

Post by Erik Aronesty via bitcoin-dev
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...

[Jorge Timón via bitcoin-dev]

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" <

Post by Erik Aronesty via bitcoin-dev
- someone can derive a random bitcoin address from it - and send funds

to it.

Post by Erik Aronesty via bitcoin-dev
- the possible derived address space is large enough that generating all

possible addresses would be a barrier

Post by Erik Aronesty via bitcoin-dev
- the receiver, however, knowing the private key, can easily scan the

blockchain fairly efficiently and determine which addresses he has the keys
to

Post by Erik Aronesty via bitcoin-dev
- another interested party cannot easily do so
Perhaps homomorphic encryption may need to be involved?

Post by Gregory Maxwell via bitcoin-dev
On Thu, Aug 11, 2016 at 8:37 PM, Erik Aronesty via bitcoin-dev

Post by Erik Aronesty via bitcoin-dev
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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[James MacWhyte via bitcoin-dev]

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 <

Post by Erik Aronesty via bitcoin-dev
- 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?

Post by Gregory Maxwell via bitcoin-dev
On Thu, Aug 11, 2016 at 8:37 PM, Erik Aronesty via bitcoin-dev

Post by Erik Aronesty via bitcoin-dev
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

Post by Erik Aronesty via bitcoin-dev
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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[Daniel Hoffman via bitcoin-dev]

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?