Re: [bitcoin-dev] Hiding entire content of on-chain transactions
The whole point is in preventing every third party, including miners, from seeing the details of what is being spent and how. The burden of verification is shifted to the owners of the coin (which is fair). In fact we could have miners recognize spend proofs and check that the same spend proof is not entered into the blockchain more than once (which would be a sign of double spend), but it is not required. The coin owners can already do that themselves. 2016-08-09 0:41 GMT+03:00 James MacWhyte : > Wouldn't you lose the ability to assume transactions in the blockchain are > verified as valid, since miners can't see the details of what is being > spent and how? I feel like this ability is bitcoin's greatest asset, and by > removing it you're creating an altcoin different enough to not be connected > to/supported by the main bitcoin project. > > On Mon, Aug 8, 2016, 09:13 Tony Churyumoff via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> 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 inpu
Re: [bitcoin-dev] BIP Number Request: Addresses over Audio
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] *Changing* the blocksize limit
On Sat, Aug 06, 2016 at 07:15:22AM -0700, Chris Priest via bitcoin-dev wrote: > If the blocksize limit is to be changed to a block output limit, the > number the limit is set to should be roughly the amount of outputs > that are found in 1MB blocks today. This way, the change should be The largest output on testnet is a bit under 1MB, and encodes a certain well-known love song... In many circumstances(1) miners have an incentive to create larger blocks that take their competitors longer to receive and validate, so protocol-level block limits need to take all these potential DoS vectors into account; serialized size is one of the most fundemental things that needs to be limited. > considered non-controversial. I think its silly that some people think > its a good thing to keep usage restricted, but again, it is what it > is. As mentioned above, and explained in detail in my recent blog post(1), restrictions are needed to keep a level playing field between all miners. 1) https://petertodd.org/2016/block-publication-incentives-for-miners -- https://petertodd.org 'peter'[:-1]@petertodd.org signature.asc Description: Digital signature ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP draft: HTLC transactions
On Wed, Jul 20, 2016 at 06:17:39AM +, Luke Dashjr wrote: > On Wednesday, July 20, 2016 5:46:54 AM Peter Todd via bitcoin-dev wrote: > > On Tue, Jul 19, 2016 at 10:35:39PM -0600, Sean Bowe via bitcoin-dev wrote: > > > I'm requesting feedback for Hash Time-Locked Contract (HTLC) transactions > > > in Bitcoin. > > > > > > HTLC transactions allow you to pay for the preimage of a hash. CSV/CLTV > > > can be used to recover your funds if the other party is not cooperative. > > > These > > > > > > scripts take the following general form: > > > [HASHOP] OP_EQUAL > > > OP_IF > > > > > > > > > > > > OP_ELSE > > > > > > [TIMEOUTOP] OP_DROP > > > > > > OP_ENDIF > > > OP_CHECKSIG > > > > Note that because you're hashing the top item on the stack regardless > > scriptSig's that satisfy HTLC's are malleable: that top stack item can be > > changed anything in the digest-not-provided case and the script still > > passes. > > OP_SIZE > OP_IF > [HASHOP] OP_EQUALVERIFY > > OP_ELSE >[TIMEOUTOP] > > OP_ENDIF > OP_CHECKSIG Ha! That's brilliant; good job. -- https://petertodd.org 'peter'[:-1]@petertodd.org signature.asc Description: 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
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? On Mon, Aug 8, 2016 at 4:42 PM Tony Churyumoff wrote: > The whole point is in preventing every third party, including miners, from > seeing the details of what is being spent and how. The burden of > verification is shifted to the owners of the coin (which is fair). > > In fact we could have miners recognize spend proofs and check that the > same spend proof is not entered into the blockchain more than once (which > would be a sign of double spend), but it is not required. The coin owners > can already do that themselves. > > 2016-08-09 0:41 GMT+03:00 James MacWhyte : > >> Wouldn't you lose the ability to assume transactions in the blockchain >> are verified as valid, since miners can't see the details of what is being >> spent and how? I feel like this ability is bitcoin's greatest asset, and by >> removing it you're creating an altcoin different enough to not be connected >> to/supported by the main bitcoin project. >> >> On Mon, Aug 8, 2016, 09:13 Tony Churyumoff via bitcoin-dev < >> bitcoin-dev@lists.linuxfoundation.org> 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
Re: [bitcoin-dev] Hiding entire content of on-chain transactions
That is a good point. As you said, it puts a lot more burden on the coin holders. One big downside would be data management. Instead of simply backing up a single HD private key, the user would have to back up entire histories of every output that has been sent to them if they want to secure their funds. It also requires them to be online to receive payments, and I think finding a method of sending the private message containing the coin's history is going to be a bit of a challenge. If you connect directly to the recipient to convey the information through traditional channels, anonymity is lost. Sending messages through the bitcoin network is one option to protect anonymity, but without active pathfinding there's no guarantee the payee will even get the message. I'm assuming you'd have to essentially replace tx messages with encrypted BBC histories, and mempools are quite full as it is. Tony, do you have any more thoughts on exactly how users would convey the private messages to payees? On Mon, Aug 8, 2016 at 4:42 PM Tony Churyumoff wrote: > The whole point is in preventing every third party, including miners, from > seeing the details of what is being spent and how. The burden of > verification is shifted to the owners of the coin (which is fair). > > In fact we could have miners recognize spend proofs and check that the > same spend proof is not entered into the blockchain more than once (which > would be a sign of double spend), but it is not required. The coin owners > can already do that themselves. > > 2016-08-09 0:41 GMT+03:00 James MacWhyte : > >> Wouldn't you lose the ability to assume transactions in the blockchain >> are verified as valid, since miners can't see the details of what is being >> spent and how? I feel like this ability is bitcoin's greatest asset, and by >> removing it you're creating an altcoin different enough to not be connected >> to/supported by the main bitcoin project. >> >> On Mon, Aug 8, 2016, 09:13 Tony Churyumoff via bitcoin-dev < >> bitcoin-dev@lists.linuxfoundation.org> 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 ex
Re: [bitcoin-dev] BIP Number Request: Addresses over Audio
I wouldn't worry about payment requests until I built a decoder and made the transmission a lot faster (probably adding tones and making it 5 bits wide), which shouldn't be hard On Mon, Aug 8, 2016 at 5:06 PM, Justin Newton via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Daniel, >Thanks for proposing this. I think this could have some useful use > cases as you state. I was wondering what you would think to adding some > additional tones to optionally denote an amount (in satoshis?). > > (FYI, actual link is here: https://github.com/Dako300/BIP ) > > Justin > > On Mon, Aug 8, 2016 at 2:22 PM, Daniel Hoffman via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> This is my BIP idea: a fast, robust, and standardized for representing >> Bitcoin addresses over audio. It takes the binary representation of the >> Bitcoin address (little endian), chops that up into 4 or 2 bit chunks >> (depending on type, 2 bit only for low quality audio like american >> telephone lines), and generates a tone based upon that value. This started >> because I wanted an easy way to donate to podcasts that I listen to, and >> having a Shazam-esque app (or a media player with this capability) that >> gives me an address automatically would be wonderful for both the consumer >> and producer. Comes with error correction built into the protocol >> >> You can see the full specification of the BIP on my GitHub page ( >> https://github.com/Dako300/BIP-0153). >> >> ___ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> >> > > > -- > > Justin W. Newton > Founder/CEO > Netki, Inc. > > 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
Re: [bitcoin-dev] BIP Number Request: Addresses over Audio
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] BIP Number Request: Addresses over Audio (fixed link)
Sorry about the last email, I deleted the repository to get rid of the BIP number to prevent confusion. The correct address is https://github.com/Dako300/BIP This is my BIP idea: a fast, robust, and standardized way 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 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP Number Request: Addresses over Audio
Daniel, 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
Re: [bitcoin-dev] Hiding entire content of on-chain transactions
On Mon, Aug 08, 2016 at 09:41:27PM +, James MacWhyte via bitcoin-dev wrote: > Wouldn't you lose the ability to assume transactions in the blockchain are > verified as valid, since miners can't see the details of what is being > spent and how? I feel like this ability is bitcoin's greatest asset, and by > removing it you're creating an altcoin different enough to not be connected > to/supported by the main bitcoin project. The fact that miners verify transactions is just an optimisation: https://petertodd.org/2013/disentangling-crypto-coin-mining Preventing double-spending however is a fundemental requirement of Bitcoin, and this proposal does prevent double-spending perfectly well (although there may be better ways to do it). The OP's proposal sounds quite similar to my earlier one along similar lines: https://petertodd.org/2016/closed-seal-sets-and-truth-lists-for-privacy -- https://petertodd.org 'peter'[:-1]@petertodd.org signature.asc Description: 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
Wouldn't you lose the ability to assume transactions in the blockchain are verified as valid, since miners can't see the details of what is being spent and how? I feel like this ability is bitcoin's greatest asset, and by removing it you're creating an altcoin different enough to not be connected to/supported by the main bitcoin project. On Mon, Aug 8, 2016, 09:13 Tony Churyumoff via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> 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 exactly >> one >> > previous output). This means that when we track a coin’s history back >> in >> > time, it will no longer branch. It will grow linearly with the number >> of >> > transfers of ownership. If a user wants to combine several inputs, he >> will >> > have to send them as separate private transactions (technically, several >> > OP_RETURNs, which can be included in a single regular bitcoin >> transaction). >> > >> > Thus, we are now forbidding any coin merges but still allowing coin >> > splits. To avoid ultimate splitting into the dust, we will also require >> > that all private coins be issued in o
[bitcoin-dev] BIP Number Request: Addresses over Audio
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
Re: [bitcoin-dev] Authentication BIP
On 08/08/2016 01:42 PM, Gregory Maxwell wrote: On Mon, Aug 8, 2016 at 5:09 PM, Andy Schroder via bitcoin-dev wrote: I have mixed feelings about strictly tying the identity-public-keys with a [...] guaranteed static IP address. The second reason is because the DNS PTR I don't see any reason that it couldn't also accept a DNS name there. The purpose of that table is so the client knows which server ID to expect. Okay, that may be fine. You are saying otherwise you'd have to do a trial and error and this tying to a network identifier just speeds things up? If the DNS is spoofed, it's no big deal because the authentication will fail anyway? I consider it a good thing from a privacy perspective if my IP address changes every once and a while. And the design seeks to preserve that privacy. Maybe a strict check option where the identity-public-keys must optionally match a specific network identifier would be a compromise? Maybe this is up The client must know the identity of the server it is expecting. The server does not announce itself. If it did then your changing of IPs would provide you with no privacy at all. Good point. If the design is to provide any protection against MITM you need to know who you expected to connect to in any case. I think the purpose of this is to detect if someone has physically stolen and compromised my bitcoin node and placed it on another network under control of an attacker. Huh. No. Almost the opposite. The system is designed to inhibit fingerprinting. You can't tell what identity key(s) a node has unless you already know them. This means that if you don't publish your node pubkey, no one can use it to track your node around the network. Cool. Is there an option for a wildcard here? Couldn't there be a case where the client wants to authenticate, but the bitcoin node does not care who it's clients are? This would be similar to many of the http based bitcoin block explorer API services that are out there. The API operators have built up some reputation, so people use them, but they don't necessarily care about who their users are. Then they're just not listed in the file. The client can ask the server to authenticate without authenticating itself. Simple enough. 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? 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] Authentication BIP
On Mon, Aug 8, 2016 at 5:09 PM, Andy Schroder via bitcoin-dev wrote: > I have mixed feelings about strictly tying the identity-public-keys with a [...] > guaranteed static IP address. The second reason is because the DNS PTR I don't see any reason that it couldn't also accept a DNS name there. The purpose of that table is so the client knows which server ID to expect. > I consider it a good thing from a privacy perspective if my IP address > changes every once and a while. And the design seeks to preserve that privacy. > Maybe a strict check option where the identity-public-keys must optionally > match a specific network identifier would be a compromise? Maybe this is up The client must know the identity of the server it is expecting. The server does not announce itself. If it did then your changing of IPs would provide you with no privacy at all. If the design is to provide any protection against MITM you need to know who you expected to connect to in any case. > I think the purpose of this is to detect if someone has physically stolen and > compromised my bitcoin node and placed it on another network under control of > an attacker. Huh. No. Almost the opposite. The system is designed to inhibit fingerprinting. You can't tell what identity key(s) a node has unless you already know them. This means that if you don't publish your node pubkey, no one can use it to track your node around the network. > Is there an option for a wildcard here? Couldn't there be a case where the > client wants to authenticate, but the bitcoin node does not care who it's > clients are? This would be similar to many of the http based bitcoin block > explorer API services that are out there. The API operators have built up > some reputation, so people use them, but they don't necessarily care about > who their users are. Then they're just not listed in the file. The client can ask the server to authenticate without authenticating itself. > 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. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Authentication BIP
On 08/08/2016 11:00 AM, Jonas Schnelli via bitcoin-dev wrote: # ___known-peers___ contains known identity-public-keys together with a network identifier (IP & port), similar to the "known-host" file supported by openssh. I have mixed feelings about strictly tying the identity-public-keys with a network identifier. I think the purpose of this is to detect if someone has physically stolen and compromised my bitcoin node and placed it on another network under control of an attacker. This seems to be a bit of a benefit, however, an attacker could always spoof the original network identifier anyway. I run my bitcoin node on an internet connection that does not guarantee a static IP address (although it usually stays the same for several weeks or months at a time). I'd like to be able to make secure connections back to my own node, even if I know the IP address may change from time to time. There are several reasons for wanting to this with a changing IP. The first is because the bandwidth on my internet connection with a guaranteed static IP address is considerably more expensive than my internet connection without a guaranteed static IP address. The second reason is because the DNS PTR record for my static IP address is personally identifiable based on other reasons/services. The internet connection that my bitcoin node is using without a guaranteed static IP address just has a PTR record that basically includes my IP address and ISP name. This isn't much use to the general public (although my ISP obviously knows who I am). The third reason is that I consider it a good thing from a privacy perspective if my IP address changes every once and a while. Maybe a strict check option where the identity-public-keys must optionally match a specific network identifier would be a compromise? Maybe this is up to the client implementation to decide, so it should just be suggested in the BIP rather than required? # ___authorized-peers___ contains authorized identity-public-keys Is there an option for a wildcard here? Couldn't there be a case where the client wants to authenticate, but the bitcoin node does not care who it's clients are? This would be similar to many of the http based bitcoin block explorer API services that are out there. The API operators have built up some reputation, so people use them, but they don't necessarily care about who their users are. === Local identity key management === Each peer can configure one identity-key (ECC, 32 bytes) per listening network interface (IPv4, IPv6, tor). What if I have bitcoind listening on multiple IPv4 interfaces? Can I have a different identity-key for each IPv4 interface? Also, would it be possible to only allow this authentication on specific interfaces? In my example above where I have two internet connections, if you don't agree to loosening the tie between the network identifier and the identity-public-keys, maybe I would just connect my bitcoin node to both internet connections, but only allow a few authorized-peers on the static IP (which would be low bandwidth), and then not authenticate on the internet connection with the changing IP at all If you don't want to increase complexity by adding these options, one could always accomplish the same thing by runing two instances of bitcoind and pairing the two over a local network, it would just be a waste of resources. == Disadvantages == The protocol may be slow if a peer has a large authorized-peers database due to the requirement of iterating and hashing over all available authorized peers identity-public-keys. Does openssh have this same problem? I'm assuming this could be parallelized very easily, so it is not a huge problem? 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
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 exactly > one > > previous output). This means that when we track a coin’s history back in > > time, it will no longer branch. It will grow linearly with the number of > > transfers of ownership. If a user wants to combine several inputs, he > will > > have to send them as separate private transactions (technically, several > > OP_RETURNs, which can be included in a single regular bitcoin > transaction). > > > > Thus, we are now forbidding any coin merges but still allowing coin > > splits. To avoid ultimate splitting into the dust, we will also require > > that all private coins be issued in one of a small number of > > denominations. Only integer number of “banknotes” can be transferred, > the > > input and output amounts must therefore be divisible by the denomination. > > For example, an input of amount 700, denomination 100, can be split into > > outputs 400 and 300, but not into 450 and 250. To send a payment, the > > payer has to pick the unspent outputs of the highest denomination first, > > then the second highest, and so on, like we already do when we pay in > cash. > > > > With fixed denominations and one input per transaction, coin histories > > still grow,
Re: [bitcoin-dev] Hiding entire content of on-chain transactions
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 exactly one > previous output). This means that when we track a coin’s history back in > time, it will no longer branch. It will grow linearly with the number of > transfers of ownership. If a user wants to combine several inputs, he will > have to send them as separate private transactions (technically, several > OP_RETURNs, which can be included in a single regular bitcoin transaction). > > Thus, we are now forbidding any coin merges but still allowing coin > splits. To avoid ultimate splitting into the dust, we will also require > that all private coins be issued in one of a small number of > denominations. Only integer number of “banknotes” can be transferred, the > input and output amounts must therefore be divisible by the denomination. > For example, an input of amount 700, denomination 100, can be split into > outputs 400 and 300, but not into 450 and 250. To send a payment, the > payer has to pick the unspent outputs of the highest denomination first, > then the second highest, and so on, like we already do when we pay in cash. > > With fixed denominations and one input per transaction, coin histories > still grow, but only linearly, which should not be a concern in regard to > scalability given that all relevant computing resources still grow > exponentially. The histories need to be stored only by the current owner > of the coin, not every bitcoin node. This is a fairer allocation of > costs. Regarding privacy, coin histories do expose private transactions > (or rather parts thereof, since a typical payment will likely consist of
[bitcoin-dev] Hiding entire content of on-chain transactions
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 exactly one previous output). This means that when we track a coin’s history back in time, it will no longer branch. It will grow linearly with the number of transfers of ownership. If a user wants to combine several inputs, he will have to send them as separate private transactions (technically, several OP_RETURNs, which can be included in a single regular bitcoin transaction). Thus, we are now forbidding any coin merges but still allowing coin splits. To avoid ultimate splitting into the dust, we will also require that all private coins be issued in one of a small number of denominations. Only integer number of “banknotes” can be transferred, the input and output amounts must therefore be divisible by the denomination. For example, an input of amount 700, denomination 100, can be split into outputs 400 and 300, but not into 450 and 250. To send a payment, the payer has to pick the unspent outputs of the highest denomination first, then the second highest, and so on, like we already do when we pay in cash. With fixed denominations and one input per transaction, coin histories still grow, but only linearly, which should not be a concern in regard to scalability given that all relevant computing resources still grow exponentially. The histories need to be stored only by the current owner of the coin, not every bitcoin node. This is a fairer allocation of costs. Regarding privacy, coin histories do expose private transactions (or rather parts thereof, since a typical payment will likely consist of several transactions due to one-input-per-transaction rule) of past coin owners to the future ones, and that exposure grows linearly with time, but it is still much much better than having every transaction immediately on the public blockchain. Also, the value of this information for potential adversaries arguably decreases with time. 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 s
[bitcoin-dev] Authentication BIP
Hi As already mentioned in the recent BIP151 thread (https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-June/012826.html), I propose the following authentication scheme to basically allow MITM detection and rejection in conjunction with BIP151. The proposed authentication BIP does require BIP151. The propose BIP does assume, node operators want to build trusted connections for various reasons. BIPs mediawiki github page available here: https://github.com/bitcoin/bips/compare/master...jonasschnelli:2016/07/auth_bip?expand=1 === BIP: ??? Title: Peer Authentication Author: Jonas Schnelli Status: Draft Type: Standards Track Created: 2016-03-23 == Abstract == This BIP describes a way how peers can authenticate – without opening fingerprinting possibilities – to other peers to guarantee ownership and/or allowing to access additional or limited services. == Motivation == We assume peer operators want to limit the access of different services or increase datastream priorities to a selective subset of peers. Also we assume peers want to connect to specific peers to broadcast or filter transactions (or similar action that reveals sensitive informations) and therefore they want to authenticate the remote peer and make sure that they have not connected to a MITM. Benefits with peer authentication: * Peers could detect MITM attacks when connecting to known peers * Peers could allow resource hungry transaction filtering only to specific peers * Peers could allow access to sensitive information that can lead to node fingerprinting (fee estimation) * Peers could allow custom message types (private extensions) to authenticated peers A simple authentication scheme based on elliptic cryptography will allow peers to identify each other and selective allow access to restricted services or reject the connection if the identity could not be verified. == Specification == The authentication scheme proposed in this BIP uses ECDSA, ___secrets will never be transmitted___. ___Authentication initialization must only happen if encrypted channels have been established (according to BIP-151 [1]).___ The ___encryption-session-ID___ is available once channels are encrypted (according to BIP-151 [1]). The identity-public-keys used for the authentication must be pre-shared over a different channel (Mail/PGP, physical paper exchange, etc.). This BIP does not cover a "trust on first use" (TOFU) concept. The authentication state must be kept until the encryption/connection terminates. Only one authentication process is allowed per connection. Re-authenticate require re-establishing the connection. === Known-peers and authorized-peers database === Each peer that supports p2p authentication must provide two users editable "databases" # ___known-peers___ contains known identity-public-keys together with a network identifier (IP & port), similar to the "known-host" file supported by openssh. # ___authorized-peers___ contains authorized identity-public-keys === Local identity key management === Each peer can configure one identity-key (ECC, 32 bytes) per listening network interface (IPv4, IPv6, tor). The according identity-public-key can be shared over a different channel with other node-operators (or non-validating clients) to grant authorized access. === Authentication procedure === Authentication after this BIP will require both sides to authenticate. Signatures/public-keys will only be revealed if the remote peer could prove that they already know the remote identity-public-key. # -> Requesting peer sends `AUTHCHALLENGE` (hash) # <- Responding peer sends `AUTHREPLY` (signature) # -> Requesting peer sends `AUTHPROPOSE` (hash) # <- Responding peer sends `AUTHCHALLENGE` (hash) # -> Requesting peer sends `AUTHREPLY` (signature) For privacy reasons, dropping the connection or aborting during the authentication process must not be possible. === `AUTHCHALLENGE` message === A peer can send an authentication challenge to see if the responding peer can produce a valid signature with the expected responding peers identity-public-key by sending an `AUTHCHALLENGE`-message to the remote peer. The responding peer needs to check if the hash matches the hash calculated with his own local identity-public-key. Fingerprinting the requesting peer is not possible. 32bytes challenge-hash `hash(encryption-session-ID || challenge_type || remote-peers-expected-identity-public-key)` `challenge_type` is a single character. `i` if the `AUTHCHALLENGE`-message is the first, requesting challenge or `r` if it's the second, remote peers challenge message. === `AUTHREPLY` message === A peer must reply an `AUTHCHALLENGE`-message with an `AUTHREPLY`-message. | 64bytes || signature || normalized comp.-signature || A signature of the encryption-session-ID done with the identity-key If the challenge-hash from the `AUTHCHALLENGE`-message did not match the local authentication public
Re: [bitcoin-dev] BIP clearing house addresses
Not everyone who uses centralized exchanges are there to obtain the currency though. A large portion are speculators who need to be able to enter and exit complex positions in milliseconds and don't care about decentralization, security, and often even the asset that they're buying. Try telling everyone who currently uses Btc-e to go do their margin trading over lightning channels, for example. They're not going to want to do that because these exchanges are already meeting their needs perfectly well, and like I argued before -- it would be very hard to do that as efficiently with any other design (there are major drawbacks for traders with a decentralized exchange.) Like it or not, these exchanges play an integral role in the current Bitcoin eco-system since they allow us to most efficiently discover price and help improve liquidity. A decentralized exchange isn't going to stop any more centralized exchanges from being hacked even if they are more secure simply because traders don't want to use them. (Sorry for the duplicate message Erik, I haven't used many mailing lists before. I think I have the hang of it now though :) ) On Mon, Aug 8, 2016 at 8:59 AM, Erik Aronesty wrote: > I still feel like you're better off getting rid of "hot wallets" and use > lightning-esqe networks to route orders. I don't think either speed or > flexibility is an issue there. > > IMO, the point of Bitcoin is to avoid the centralization that seems to be > happening on the network now. By making "hot wallets" more "secure", we > encourage things to keep heading downhill with massive centralized > crappy-security exchanges. > > Because, ultimately, there's no security that will prevent an inside > job. And all of these thefts have, in my opinion, been at least partly > inside jobs. > > And centralization is the actually demon that needs slaying here. > > A client-side library with P2P order routing, tether.to + bitcoin > and you've got a decentralized exchange... with orders matched to users > directly, and channel-trades executed instantly. And "market makers" > running nodes to facilitate routing, etc. > > No center... nothing to shut down or sue... and no one holds your funds. > That's a real Bitcoin exchange. > > > > On Sun, Aug 7, 2016 at 1:35 AM, Matthew Roberts via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> I'm wondering if we're fully on the same page here. What I was thinking >> was that this protection mechanism would be applied to the coins in the hot >> wallet (I wasn't talking about moving coins from the cold wallet to the hot >> wallet -- though such a mechanism is also needed.) >> >> With the hot wallet you would have an output script that only allowed >> coins to be sent to a new transaction whose output script was then only >> redeemable after N confirmations (the output is relative time-locked) but >> which can also be recovered to a fixed fail-safe address before the >> time-lock is reached (exactly like TierNolan already listed only the >> time-locked destination shouldn't be completely fixed.) So the private key >> for this hot wallet can still sign valid transactions to withdraw coins to >> any known destination and these transactions still reach the blockchain. >> >> The key difference from a regular transaction is that the destination >> only has access to the coins -after- the relative time-lock is reached (N >> blocks after first confirm) so everyone knows where withdrawals are suppose >> to be going and how many coins are being withdrawn at any given time. >> Deposits to the hot wallet would therefore need to be encumbered by the >> same protection so that from then on this time-lock to redeem coins can be >> applied to every new transaction trying to move coins (withdrawn by a user >> of the exchange or sent to the cold wallet.) >> >> Notice we don't care about the destination in the TX script for the hot >> wallet because to process user's withdrawals we can't know ahead of time >> where they need to be sent (so it isn't possible to use a fixed address >> here – though you might want to remove the clearing phase and set a fixed >> address for coins sent from the hot wallet to the cold wallet.) The benefit >> here comes from being able to see what withdrawals are being cleared, >> matching those up to our expectations, and being able to "cancel" >> withdrawals if they look suspicious, and you get the benefits for transfers >> made from the hot wallet to the cold wallet and visa-versa. >> >> >> This approach is good for a number of crucial services: >> >> 1. Wallets could be built that grouped coins into different "accounts" >> with different time-frames required for clearing / unlocking coins. Your >> savings or investment account would say -- take up to a week to clear -- >> whereas your everyday account used for smaller purchases (with less money) >> would only take a few hours. This could all be linked up to services that >> notified you of your money being
Re: [bitcoin-dev] BIP clearing house addresses
With channels and the exchange acting as hub, you can do instant trades between altcoins. This doesn't work with fiat accounts. A "100% reserve" company could issue fiat tokens. The exchange could then trade those tokens. This eliminates the counter-party risk for the exchange. If the exchange dies, you still have your (alt)coins and also fiat tokens. There is still risk that the token company could go bankrupt though. This could be mitigated by that company requiring only "cashing out" tokens to accounts which have been verified. The company could set up a blockchain where it signed the blocks rather than mining and could get money from transaction fees and also minting fees (say it charges 1% for minting new tokens) I wonder what how the law would work for that. It isn't actually doing trading, it is just issuing tokens and redeeming them. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP clearing house addresses
I'm not convinced you need to hold people's funds to provide those features. Maybe the millisecond thing. But 99 out of 100 traders would accept a 100 millisecond latency in exchange for 0 counterparty risk. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP clearing house addresses
On Mon, Aug 8, 2016 at 1:48 AM, Matthew Roberts wrote: > Not everyone who uses centralized exchanges are there to obtain the > currency though. A large portion are speculators who need to be able to > enter and exit complex positions in milliseconds and don't care about > decentralization, security, and often even the asset that they're buying. > Centralized exchanges also allow for things like limit orders. You don't even have to be logged in and they can execute trades. This couldn't be done with channels. > Try telling everyone who currently uses Btc-e to go do their margin > trading over lightning channels, for example. > Using channels and a centralized exchange gets many of the benefits of a distributed exchange. The channel allows instant funding while allowing the customer to have full control over the funds. The customer could fund the channel and then move money to the exchange when needed. Even margin account holders might like the fact that it is clear which funds are under their direct control and which funds are held by the exchange. If they are using bitcoin funds as collateral for a margin trade, then inherently the exchange has to have control over those funds. A 2 of 3 system where the customer, exchange and a 3rd party arbitration agency holds keys might be acceptable to the exchange. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
