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

[James MacWhyte via bitcoin-dev]

Signed by the key pair that was referenced in the output of the on-chain
transaction? (Bob in my example, actually) Doesn't that mean it's easy to
follow who is paying whom, you just can't see how much is going to reach
recipient?

On Tue, Aug 9, 2016, 04:40 Tony Churyumoff  wrote:

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

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

[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" <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> I have updated the GitHub a lot (changed tones to be less chirpy, fixed
> some smalls) and made a couple of samples (see attachment for MP3 and FLAC
> of both tone tables, first 16 then 4). Is this good enough to warrant an
> official BIP number? I haven't built a decoder yet, but it seems like the
> encoder is working properly (looked at Audacity, seems like it is working),
> and some people on reddit want to "allow for decoding experiments"
> 
>
> What suggestions do you all have for it?
>
> On Mon, Aug 8, 2016 at 8:50 PM, Daniel Hoffman  > 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.

 jus...@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
>
>

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

[Gregory Maxwell via bitcoin-dev]

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

> I have updated the GitHub a lot (changed tones to be less chirpy, fixed
> some smalls) and made a couple of samples (see attachment for MP3 and FLAC
> of both tone tables, first 16 then 4). Is this good enough to warrant an
> official BIP number? I haven't built a decoder yet, but it seems like the
> encoder is working properly (looked at Audacity, seems like it is working),
> and some people on reddit want to "allow for decoding experiments"
> 
>
> 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.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

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

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"
> 
> 
> What suggestions do you all have for it?
> 
> On Mon, Aug 8, 2016 at 8:50 PM, Daniel Hoffman
> > 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
>  > 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"
>  > 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  > 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.
> 
> jus...@netki.com 
> +1.818.261.4248 

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

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

> I have updated the GitHub a lot (changed tones to be less chirpy, fixed
> some smalls) and made a couple of samples (see attachment for MP3 and FLAC
> of both tone tables, first 16 then 4). Is this good enough to warrant an
> official BIP number? I haven't built a decoder yet, but it seems like the
> encoder is working properly (looked at Audacity, seems like it is working),
> and some people on reddit want to "allow for decoding experiments"
> 
>
> What suggestions do you all have for it?
>
> On Mon, Aug 8, 2016 at 8:50 PM, Daniel Hoffman  > 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.

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

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

[Luke Dashjr via bitcoin-dev]

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

Yeah, let's call it BIP 170.

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

P.S. Why are telephones considered 4-tone? DTMF is 16-tone IIRC?
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Authentication BIP

[Jonas Schnelli via bitcoin-dev]

Hi Andy

>>
>>> Does openssh have this same problem?
>> No. OpenSSH doesn't make an effort to protect the privacy of its users.
>>
>>> I'm assuming this could be parallelized very easily, so it is not a huge
>>> problem?
>> It's not a issue because we're not aware of any usecase where a node
>> would have a large list of authenticated peers.
>>
>>> Each peer can configure one identity-key (ECC, 32 bytes) per listening
>> network interface (IPv4, IPv6, tor).
>>
>> I'm not aware of any reason for this limitation to exist. A node
>> should be able to have as many listening identities as it wants, with
>> a similar cost to having a large authorized keys list.
>>
> 
> So you are saying that you agree with me that the original text needs to
> be revised slightly or I am just misinterpreting the original text?

Yes. I think this limitation could be removed.
A responding node can have – in theory – multiple identity-keys per
network interface (network interfaces is also confusing, because you
could run multiple bitcoind instances on the same interface with
different ports).

The BIP should just make clear, that it is probably wise, to use
different identity-keys for each network interface (ipv4, v6, tor).

I'll try to overhaul that part.





signature.asc
Description: OpenPGP digital signature
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Henning Kopp via bitcoin-dev]

Hi Tony,

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

I am not entirely sure if this works. You wrote:

> There is one technical nuance that I omitted above to avoid distraction.
>  Unlike regular bitcoin transactions, every output in a private payment
> must also include a blinding factor, which is just a random string.  When
> the output is spent, the corresponding spend proof will therefore depend on
> this blinding factor (remember that spend proof is just a hash of the
> output).  Without a blinding factor, it would be feasible to pre-image the
> spend proof and reveal the output being spent as the search space of all
> possible outputs is rather small.

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

Best
Henning

On Mon, Aug 08, 2016 at 07:03:28PM +0300, Tony Churyumoff wrote:
> Hi Henning,
> 
> 1. The fees are paid by the enclosing BTC transaction.
> 2. The hash is encoded into an OP_RETURN.
> 
> > Regarding the blinding factor, I think you could just use HMAC.
> How exactly?
> 
> Tony
> 
> 
> 2016-08-08 18:47 GMT+03:00 Henning Kopp :
> 
> > Hi Tony,
> >
> > I see some issues in your protocol.
> >
> > 1. How are mining fees handled?
> >
> > 2. Assume Alice sends Bob some Coins together with their history and
> > Bob checks that the history is correct. How does the hash of the txout
> > find its way into the blockchain?
> >
> > Regarding the blinding factor, I think you could just use HMAC.
> >
> > All the best
> > Henning
> >
> >
> > On Mon, Aug 08, 2016 at 06:30:21PM +0300, Tony Churyumoff via bitcoin-dev
> > wrote:
> > > This is a proposal about hiding the entire content of bitcoin
> > > transactions.  It goes farther than CoinJoin and ring signatures, which
> > > only obfuscate the transaction graph, and Confidential Transactions,
> > which
> > > only hide the amounts.
> > >
> > > The central idea of the proposed design is to hide the entire inputs and
> > > outputs, and publish only the hash of inputs and outputs in the
> > > blockchain.  The hash can be published as OP_RETURN.  The plaintext of
> > > inputs and outputs is sent directly to the payee via a private message,
> > and
> > > never goes into the blockchain.  The payee then calculates the hash and
> > > looks it up in the blockchain to verify that the hash was indeed
> > published
> > > by the payer.
> > >
> > > Since the plaintext of the transaction is not published to the public
> > > blockchain, all validation work has to be done only by the user who
> > > receives the payment.
> > >
> > > To protect against double-spends, the payer also has to publish another
> > > hash, which is the hash of the output being spent.  We’ll call this hash
> > *spend
> > > proof*.  Since the spend proof depends solely on the output being spent,
> > > any attempt to spend the same output again will produce exactly the same
> > > spend proof, and the payee will be able to see that, and will reject the
> > > payment.  If there are several outputs consumed by the same transaction,
> > > the payer has to publish several spend proofs.
> > >
> > > To prove that the outputs being spent are valid, the payer also has to
> > send
> > > the plaintexts of the earlier transaction(s) that produced them, then the
> > > plaintexts of even earlier transactions that produced the outputs spent
> > in
> > > those transactions, and so on, up until the issue (similar to coinbase)
> > > transactions that created the initial private coins.  Each new owner of
> > the
> > > coin will have to store its entire history, and when he spends the coin,
> > he
> > > forwards the entire history to the next owner and extends it with his own
> > > transaction.
> > >
> > > If we apply the existing bitcoin design that allows multiple inputs and
> > > multiple outputs per transaction, the history of ownership transfers
> > would
> > > grow exponentially.  Indeed, if we take any regular bitcoin output and
> > try
> > > to track its history back to coinbase, our history will branch every time
> > > we see a transaction that has more than one input (which is not
> > uncommon).
> > > After such a transaction (remember, we are traveling back in time), we’ll
> > > have to track two or more histories, for each respective input.  Those
> > > histories will branch again, and the total number of history entries
> > grows
> > > exponentially.  For example, if every transaction had exactly two inputs,
> > > the size of history would grow as 2^N where N is the number of steps back
> > > in history.
> > >
> > > To avoid such rapid growth of ownership history (which is not only
> > > inconvenient to move, but also exposes too much private information about
> > > previous owners of all the contributing coins), we will require each
> > > private transaction to have exactly one input (i.e. to consume