BIP Number Request: Addresses over Audio
28 messages, 8 to 13 Aug 2016. Started by Daniel Hoffman.
Daniel Hoffman (8), Erik Aronesty (5), Gregory Maxwell (2), Tier Nolan (2), James MacWhyte (2), Justin Newton, Trevin Hofmann, Jannes Faber, +6 more
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).
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:
Quoted text (19 lines)
> 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 > >
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:
Quoted text (50 lines)
> 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 > >
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:
Quoted text (50 lines)
> 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 > >
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:
Quoted text (66 lines)
> 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 > >
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:
Quoted text (73 lines)
> 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 >> >> >
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:
Quoted text (93 lines)
> 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 > >
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:
Quoted text (93 lines)
> 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 > >
On Tuesday, August 09, 2016 11:06:20 PM Daniel Hoffman via bitcoin-dev wrote:
Quoted text (1 line)
> 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?
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:
Quoted text (111 lines)
> 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 >
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:
Quoted text (146 lines)
> 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 >
On Tue, Aug 9, 2016 at 11:06 PM, Daniel Hoffman via bitcoin-dev < bitcoin-dev@lists•linuxfoundation•org> wrote:
Quoted text (10 lines)
> 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.
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.
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:
Quoted text (10 lines)
> 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 > >
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:
Quoted text (42 lines)
> 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 > >
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:
Quoted text (55 lines)
> 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 > >
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:
Quoted text (72 lines)
> 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 > >
On Wed, Aug 10, 2016 at 7:28 PM, Erik Aronesty via bitcoin-dev <bitcoin-dev@lists•linuxfoundation•org> wrote:
Quoted text (2 lines)
> 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.
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:
Quoted text (17 lines)
> 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 >
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:
Quoted text (28 lines)
> 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 >
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:
Quoted text (13 lines)
> 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 >
On Thu, Aug 11, 2016 at 2:55 PM, Erik Aronesty via bitcoin-dev < bitcoin-dev@lists•linuxfoundation•org> wrote:
Quoted text (4 lines)
> 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.
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:
Quoted text (50 lines)
> 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 > >
On Thu, Aug 11, 2016 at 8:37 PM, Erik Aronesty via bitcoin-dev <bitcoin-dev@lists•linuxfoundation•org> wrote:
Quoted text (3 lines)
> 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...
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:
Quoted text (12 lines)
> 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... >
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:
Quoted text (4 lines)
> > I'm imagining a "publishable seed" such that: > > - someone can derive a random bitcoin address from it - and send funds
to it.
Quoted text (1 line)
> - the possible derived address space is large enough that generating all
possible addresses would be a barrier
Quoted text (1 line)
> - the receiver, however, knowing the private key, can easily scan the
blockchain fairly efficiently and determine which addresses he has the keys to
Quoted text (10 lines)
> - 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
Quoted text (1 line)
>> > address was derived from it though. I mean, wouldn't I have to
compute all
Quoted text (14 lines)
>> > 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 >
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:
Quoted text (34 lines)
> 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 >
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?