Henning Kopp [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2015-07-02 to 2017-07-05
💬 Posted a total of 14 messages
📚 Participated in the following categories: bitcoin-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-07 19:56:42

- reply

📅 Original date posted:2017-02-27
📝 Original message:Hi all,
I did not follow the whole discussion, but wanted to throw in some
literature on the failure of crypto primitives in Bitcoin.
There is a paper which discusses the problems, but does not give any
remedies: https://eprint.iacr.org/2016/167.pdf
And there are also contingency plans on the wiki:
https://en.bitcoin.it/wiki/Contingency_plans These are not very
detailed and my impression is that this information should be viewed
very critically (E.g., when ECDSA is broken, the suggested vague
response is "Switch to the stronger algorithm." Yeah. And "Code for
all of this should be prepared." Surely. As far as I know, there is no
such code and no-one is working on it).
Best,
Henning
On Sat, Feb 25, 2017 at 09:45:36AM -0800, Shin'ichiro Matsuo via bitcoin-dev wrote:
> We should distinguish collision resistance from 2nd pre-image resistance, in general.
>
> As previously written, we should care both hash output length and algorithm itself. The weakness of SHA-0 (preliminary version of SHA-1) was reported in 2004, then many research on the structure of SHA-1 were conducted. In the case of SHA-2, it is harder than SHA-1 to find collisions.
>
> Existing security consideration and evaluation criteria were extensively discussed in the NIST SHA-3 competition. Please see the following sites.
>
> https://ehash.iaik.tugraz.at/wiki/The_SHA-3_Zoo
> https://ehash.iaik.tugraz.at/wiki/Cryptanalysis_Categories
>
> We need similar analysis on RIPEMD160 and impacts of attacks on (RIPEMD160(SHA2(msg)).
>
> We can also refer the security assumption of hash chain in Asiacrypt 2004 Paper.
> https://home.cyber.ee/~ahtbu/timestampsec.pdf
>
> In the discussion of SHA3 competition, we choose another hash design structure, so called "sponge structure." This leads diversity of design principles of hash function and gives resilience even when one hash design structure becomes vulnerable. As Peter Todd wrote, discussion on design structure and algorithm is important. Discussions on all of algorithm, output length and security requirements are needed.
>
> At some future moment, we should think about transition of underlying hash functions. I’m working on this subject and will present an idea at IEEE S&B.
>
> Shin’ichiro Matsuo
>
>
> > On Feb 25, 2017, at 8:10 AM, Ethan Heilman via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> >
> > >SHA1 is insecure because the SHA1 algorithm is insecure, not because 160bits isn't enough.
> >
> > I would argue that 160-bits isn't enough for collision resistance. Assuming RIPEMD-160(SHA-256(msg)) has no flaws (i.e. is a random oracle), collisions can be generated in 2^80 queries (actually detecting these collisions requires some time-memory additional trade-offs). The Bitcoin network at the current hash rate performs roughly SHA-256 ~2^78 queries a day or 2^80 queries every four days. Without any break in RIPEMD-160(SHA-256(msg)) the US could build an ASIC datacenter and produce RIPEMD-160 collisions for a fraction of its yearly cryptologic budget.
> >
> > The impact of collisions in RIPEMD-160(SHA-256(msg)) according to "On Bitcoin Security in the Presence of Broken Crypto Primitives"(https://eprint.iacr.org/2016/167.pdf):
> >
> > >Collisions are similar, though in this case both public keys are under the adversary’s control, and again the adversary does not have access to the private keys. In both scenarios, there is a question of nonrepudiation external to the protocol itself: by presenting a second pre-image of a key used to sign a transaction, a user/adversary can claim that his coins were stolen.
> >
> > How would such an event effect the price of Bitcoin when headlines are "Bitcoin's Cryptography Broken"? How much money could someone make by playing the market in this way?
> >
> > For both reasons of credibility and good engineering (safety margins) Bitcoin should strive to always use cryptography which is beyond reproach.
> >
> >
> > On Sat, Feb 25, 2017 at 9:50 AM, Leandro Coutinho via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> > Google recommeds "migrate to safer cryptographic hashes such as SHA-256 and SHA-3"
> > It does not mention RIPEMD-160
> >
> > https://security.googleblog.com/2017/02/announcing-first-sha1-collision.html?m=1
> >
> >
> > Em 25/02/2017 10:47, "Steve Davis via bitcoin-dev" <bitcoin-dev at lists.linuxfoundation.org> escreveu:
> >
> > > On Feb 24, 2017, at 7:01 PM, Peter Todd <pete at petertodd.org> wrote:
> > >
> > > On Fri, Feb 24, 2017 at 05:49:36PM -0600, Steve Davis via bitcoin-dev wrote:
> > >> If the 20 byte SHA1 is now considered insecure (with good reason), what about RIPEMD-160 which is the foundation of Bitcoin addresses?
> > >
> > > SHA1 is insecure because the SHA1 algorithm is insecure, not because 160bits isn't enough.
> > >
> > > AFAIK there aren't any known weaknesses in RIPEMD160,
> >
> > …so far. I wonder how long that vacation will last?
> >
> > > but it also hasn't been
> > > as closely studied as more common hash algorithms.
> >
> > ...but we can be sure that it will be, since the dollar value held in existing utxos continues to increase...
> >
> > > That said, Bitcoin uses
> > > RIPEMD160(SHA256(msg)), which may make creating collisions harder if an attack
> > > is found than if it used RIPEMD160 alone.
> >
> > Does that offer any greater protection? That’s not so clear to me as the outputs (at least for p2pkh) only verify the public key against the final 20 byte hash. Specifically, in the first (notional) case the challenge would be to find a private key that has a public key that hashes to the final hash. In the second (realistic) case, you merely need to add the sha256 hash into the problem, which doesn’t seem to me to increase the difficulty by any significant amount?
> >
> >
> > /s
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
> >
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
> >
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--
Henning Kopp
Institute of Distributed Systems
Ulm University, Germany
Office: O27 - 3402
Phone: +49 731 50-24138
Web: http://www.uni-ulm.de/in/vs/~kopp

2023-06-07 19:53:50

- reply

📅 Original date posted:2016-10-10
📝 Original message:Hi all,
I totally agree with the assessment of the situation. Previously I
learned a lot about bitcoin on this list. There were a lot of great
ideas regarding the protocol and the surrounding ecosystem. Now there
is mainly talk about code and BIPs, which is the main purpose of a
developer list.
I do not feel that we should clog bitcoin-dev again with
non-development talk but rather find a way to get bitcoin-discuss
going. My impression is that bitcoin-discuss has not reached a
critical mass of contributors. The question is how we can change that.
All the best
Henning
On Sun, Oct 09, 2016 at 12:26:07PM +0200, Jeremy via bitcoin-dev wrote:
> Hi bitcoin-dev,
>
> I'm well aware that discussion of moderation on bitcoin-dev is
> discouraged*. However, I think that we should, as a year of moderation
> approaches, discuss openly as a community what the impact of such policy
> has been. Making such a post now is timely given that people will have the
> opportunity to discuss in-person as well as online as Scaling Bitcoin is
> currently underway. On the suggestion of others, I've also CC'd
> bitcoin-discuss on this message.
>
> Below, I'll share some of my own personal thoughts as a starter, but would
> love to hear others feelings as well.
>
> For me, the bitcoin-dev mailing list was a place where I started
> frequenting to learn a lot about bitcoin and the development process and
> interact with the community. Since moderation has begun, it seems that the
> messages/day has dropped drastically. This may be a nice outcome overall
> for our sanity, but I think that it has on the whole made the community
> less accessible. I've heard from people (a > 1 number, myself included)
> that they now self-censor because they think they will put a lot of work
> into their email only for it to get moderated away as trolling/spam. Thus,
> while we may not observe a high rate of moderated posts, it does mean the
> "chilling effect" of moderation still manifests -- I think that people not
> writing emails because they think it may be moderated reduces the rate of
> people writing emails which is a generally valuable thing as it offers
> people a vehicle through which they try to think through and communicate
> their ideas in detail.
>
> Overall, I think that at the time that moderation was added to the list, it
> was probably the right thing to do. We're in a different place as a
> community now, so I feel we should attempt to open up this valuable
> communication channel once again. My sentiment is that we enacted
> moderation to protect a resource that we all felt was valuable, but in the
> process, the value of the list was damaged, but not irreparably so.
>
> Best,
>
> Jeremy
>
>
> * From the email introducing the bitcoin-dev moderation policy, "Generally
> discouraged: shower thoughts, wild speculation, jokes, +1s, non-technical
> bitcoin issues, rehashing settled topics without new data, moderation
> concerns."
>
>
> --
> @JeremyRubin <https://twitter.com/JeremyRubin>
> <https://twitter.com/JeremyRubin>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--
Henning Kopp
Institute of Distributed Systems
Ulm University, Germany
Office: O27 - 3402
Phone: +49 731 50-24138
Web: http://www.uni-ulm.de/in/vs/~kopp

2023-06-07 19:52:27

- reply

📅 Original date posted:2016-08-09
📝 Original message: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 <henning.kopp at uni-ulm.de>:
>
> > 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
> > > 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 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.
> > >
> > > To issue the new private coin, one can burn regular BTC by sending it to
> > > one of several unspendable bitcoin addresses, one address per
> > denomination.
> > > Burning BTC would entitle one to an equal amount of the new private
> > coin,
> > > let’s call it *black bitcoin*, or *BBC*.
> > >
> > > Then BBC would be transferred from user to user by:
> > > 1. creating a private transaction, which consists of one input and
> > several
> > > outputs;
> > > 2. storing the hash of the transaction and the spend proof of the
> > consumed
> > > output into the blockchain in an OP_RETURN (the sender pays the
> > > corresponding fees in regular BTC)
> > > 3. sending the transaction, together with the history leading to its
> > input,
> > > directly to the payee over a private communication channel. The first
> > > entry of the history must be a bitcoin transaction that burned BTC to
> > issue
> > > an equal amount of BCC.
> > >
> > > To verify the payment, the payee:
> > > 1. makes sure that the amount of the input matches the sum of outputs,
> > and
> > > all are divisible by the denomination
> > > 2. calculates the hash of the private transaction
> > > 3. looks up an OP_RETURN that includes this hash and is signed by the
> > > payee. If there is more than one, the one that comes in the earlier
> > block
> > > prevails.
> > > 4. calculates the spend proof and makes sure that it is included in the
> > > same OP_RETURN
> > > 5. makes sure the same spend proof is not included anywhere in the same
> > or
> > > earlier blocks (that is, the coin was not spent before). Only
> > transactions
> > > by the same author are searched.
> > > 6. repeats the same steps for every entry in the history, except the
> > first
> > > entry, which should be a valid burning transaction.
> > >
> > > To facilitate exchange of private transaction data, the bitcoin network
> > > protocol can be extended with a new message type. Unfortunately, it
> > lacks
> > > encryption, hence private payments are really private only when bitcoin
> > is
> > > used over tor.
> > >
> > > There are a few limitations that ought to be mentioned:
> > > 1. After user A sends a private payment to user B, user A will know what
> > > the spend proof is going to be when B decides to spend the coin.
> > > Therefore, A will know when the coin was spent by B, but nothing more.
> > > Neither the new owner of the coin, nor its future movements will be
> > known
> > > to A.
> > > 2. Over time, larger outputs will likely be split into many smaller
> > > outputs, whose amounts are not much greater than their denominations.
> > > You’ll have to combine more inputs to send the same amount. When you
> > want
> > > to send a very large amount that is much greater than the highest
> > available
> > > denomination, you’ll have to send a lot of private transactions, your
> > > bitcoin transaction with so many OP_RETURNs will stand out, and their
> > > number will roughly indicate the total amount. This kind of privacy
> > > leakage, however it applies to a small number of users, is easy to avoid
> > by
> > > using multiple addresses and storing a relatively small amount on each
> > > address.
> > > 3. Exchanges and large merchants will likely accumulate large coin
> > > histories. Although fragmented, far from complete, and likely outdated,
> > it
> > > is still something to bear in mind.
> > >
> > > No hard or soft fork is required, BBC is just a separate privacy
> > preserving
> > > currency on top of bitcoin blockchain, and the same private keys and
> > > addresses are used for both BBC and the base currency BTC. Every BCC
> > > transaction must be enclosed into by a small BTC transaction that stores
> > > the OP_RETURNs and pays for the fees.
> > >
> > > Are there any flaws in this design?
> > >
> > > Originally posted to BCT https://bitcointalk.org/index.
> > php?topic=1574508.0,
> > > but got no feedback so far, apparently everybody was consumed with
> > bitfinex
> > > drama and now mimblewimble.
> > >
> > > Tony
> >
> > > _______________________________________________
> > > bitcoin-dev mailing list
> > > bitcoin-dev at lists.linuxfoundation.org
> > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
> >
> > --
> > Henning Kopp
> > Institute of Distributed Systems
> > Ulm University, Germany
> >
> > Office: O27 - 3402
> > Phone: +49 731 50-24138
> > Web: http://www.uni-ulm.de/in/vs/~kopp
> >
--
Henning Kopp
Institute of Distributed Systems
Ulm University, Germany
Office: O27 - 3402
Phone: +49 731 50-24138
Web: http://www.uni-ulm.de/in/vs/~kopp

2023-06-07 19:52:23

- reply

📅 Original date posted:2016-08-08
📝 Original message: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
> 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 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.
>
> To issue the new private coin, one can burn regular BTC by sending it to
> one of several unspendable bitcoin addresses, one address per denomination.
> Burning BTC would entitle one to an equal amount of the new private coin,
> let’s call it *black bitcoin*, or *BBC*.
>
> Then BBC would be transferred from user to user by:
> 1. creating a private transaction, which consists of one input and several
> outputs;
> 2. storing the hash of the transaction and the spend proof of the consumed
> output into the blockchain in an OP_RETURN (the sender pays the
> corresponding fees in regular BTC)
> 3. sending the transaction, together with the history leading to its input,
> directly to the payee over a private communication channel. The first
> entry of the history must be a bitcoin transaction that burned BTC to issue
> an equal amount of BCC.
>
> To verify the payment, the payee:
> 1. makes sure that the amount of the input matches the sum of outputs, and
> all are divisible by the denomination
> 2. calculates the hash of the private transaction
> 3. looks up an OP_RETURN that includes this hash and is signed by the
> payee. If there is more than one, the one that comes in the earlier block
> prevails.
> 4. calculates the spend proof and makes sure that it is included in the
> same OP_RETURN
> 5. makes sure the same spend proof is not included anywhere in the same or
> earlier blocks (that is, the coin was not spent before). Only transactions
> by the same author are searched.
> 6. repeats the same steps for every entry in the history, except the first
> entry, which should be a valid burning transaction.
>
> To facilitate exchange of private transaction data, the bitcoin network
> protocol can be extended with a new message type. Unfortunately, it lacks
> encryption, hence private payments are really private only when bitcoin is
> used over tor.
>
> There are a few limitations that ought to be mentioned:
> 1. After user A sends a private payment to user B, user A will know what
> the spend proof is going to be when B decides to spend the coin.
> Therefore, A will know when the coin was spent by B, but nothing more.
> Neither the new owner of the coin, nor its future movements will be known
> to A.
> 2. Over time, larger outputs will likely be split into many smaller
> outputs, whose amounts are not much greater than their denominations.
> You’ll have to combine more inputs to send the same amount. When you want
> to send a very large amount that is much greater than the highest available
> denomination, you’ll have to send a lot of private transactions, your
> bitcoin transaction with so many OP_RETURNs will stand out, and their
> number will roughly indicate the total amount. This kind of privacy
> leakage, however it applies to a small number of users, is easy to avoid by
> using multiple addresses and storing a relatively small amount on each
> address.
> 3. Exchanges and large merchants will likely accumulate large coin
> histories. Although fragmented, far from complete, and likely outdated, it
> is still something to bear in mind.
>
> No hard or soft fork is required, BBC is just a separate privacy preserving
> currency on top of bitcoin blockchain, and the same private keys and
> addresses are used for both BBC and the base currency BTC. Every BCC
> transaction must be enclosed into by a small BTC transaction that stores
> the OP_RETURNs and pays for the fees.
>
> Are there any flaws in this design?
>
> Originally posted to BCT https://bitcointalk.org/index.php?topic=1574508.0,
> but got no feedback so far, apparently everybody was consumed with bitfinex
> drama and now mimblewimble.
>
> Tony
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--
Henning Kopp
Institute of Distributed Systems
Ulm University, Germany
Office: O27 - 3402
Phone: +49 731 50-24138
Web: http://www.uni-ulm.de/in/vs/~kopp

2023-06-07 19:50:35

- reply

📅 Original date posted:2016-05-11
📝 Original message:On Wed, May 11, 2016 at 11:21:10AM +0200, Jannes Faber via bitcoin-dev wrote:
> On 11 May 2016 at 05:14, Timo Hanke via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> > There is no way to tell from a block if it was mined with AsicBoost or
> > not. So you don’t know what percentage of the hashrate uses AsicBoost at
> > any point in time. How can you risk forking that percentage out? Note that
> > this would be a GUARANTEED chain fork. Meaning that after you change the
> > block mining algorithm some percentage of hardware will no longer be able
> > to produce valid blocks. That hardware cannot “switch over” to the majority
> > chain even if it wanted to. Hence you are guaranteed to have two
> > co-existing bitcoin blockchains afterwards.
> >
> > Again: this is unlike the hypothetical persistence of two chains after a
> > hardfork that is only contentious but doesn’t change the mining algorithm,
> > the kind of hardfork you are proposing would guarantee the persistence of
> > two chains.
> >
>
> Assuming AsicBoost miners are in the minority, their chain will constantly
> get overtaken. So it will not be one endless hard fork as you claim, but
> rather AsicBoost blocks will continue to be ignored (orphaned) until they
> stop making them.
At least until a difficulty adjustment on the AsicBoost chain takes
place. From that point on, both chains, the AsicBoost one and the
forked one will grow approximately at the same speed.
All the best
Henning
--
Henning Kopp
Institute of Distributed Systems
Ulm University, Germany
Office: O27 - 3402
Phone: +49 731 50-24138
Web: http://www.uni-ulm.de/in/vs/~kopp

2023-06-07 19:49:39

- reply

📅 Original date posted:2016-03-03
📝 Original message:Hi,
I think there is no need to do a hardfork for this. Rather it should
be implemented as a safety-mechanism in the client. Perhaps a warning
can pop up, if one of your conditions A) or B) is met.
All the best
Henning Kopp
On Thu, Mar 03, 2016 at 05:02:11AM -0800, Alice Wonder via bitcoin-dev wrote:
> I think the next hard fork should require a safety rule for TX fees.
>
> https://blockchain.info/tx/6fe69404e6c12b25b60fcd56cc6dc9fb169b24608943def6dbe1eb0a9388ed08
>
> 15 BTC TX fee for < 7 BTC of outputs.
>
> Probably either a typo or client bug.
>
> My guess is the user was using a client that does not adjust TX fee, and
> needed to manually set it in order to get the TX in the block sooner, and
> meant 15 mBTC or something.
>
> I suggest that either :
>
> A) TX fee may not be larger than sum of outputs
> B) TX fee per byte may not be larger than 4X largest fee per byte in
> previous block
>
> Either of those would have prevented this TX from going into a block.
>
> Many people I know are scared of bitcoin, that they will make a TX and make
> a mistake they can't undo.
>
> Adding protections may help give confidence and there is precedence to doing
> things to prevent typo blunders - a public address has a four byte checksum
> to reduce the odds of a typo.
>
> This kind of mistake is rare, so a fix could be included in the coming HF
> for the possible July 2017 block increase.
>
> Thank you for your time.
>
> Alice Wonder
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--
Henning Kopp
Institute of Distributed Systems
Ulm University, Germany
Office: O27 - 3402
Phone: +49 731 50-24138
Web: http://www.uni-ulm.de/in/vs/~kopp

2023-06-07 19:49:37

- reply

📅 Original date posted:2016-03-04
📝 Original message:Hi,
> However, I think it could actually increase
> confidence in the system if the community is able to demonstrate a good
> process for making such decisions, and show that we can separate the
> meaningful underlying principles, such as the coin limit and overall
> inflation rate, from what is more akin to an implementation detail, as I
> consider the large-step reward reduction to be.
I do not think that a line can be drawn here. As far as I understood,
you think that the coin limit is a meaningful underlying principle
which should not be touched, whereas the halving of mining rewards is
an implementation detail. The two are very closely tied together and
changes to both of them would result in a hardfork, if I am not
mistaken.
Regarding the effects of the mining reward halving, there is a nice
paper from courtois:
http://arxiv.org/abs/1405.0534
All the best
Henning
On Thu, Mar 03, 2016 at 10:27:35AM -0800, Corey Haddad via bitcoin-dev wrote:
> Since the root cause of what you are trying to address is the reward
> having, I'd suggest considering an adjustment to the having schedule.
> Instead of their being a large supply shock every four years, perhaps the
> reward could drop every 52,500 blocks (yearly), or even at each difficulty
> adjustment, in such a way that the inflation curve is smoothed out. The
> exponential decay rate would be preserved, so overall economic philosophy
> would be preserved.
>
> I'm guessing hesitance to this approach would lie in a reluctance to tinker
> with Bitcoin's 'economic contract', and slippery slope concerns about might
> be the next change (21M?). However, I think it could actually increase
> confidence in the system if the community is able to demonstrate a good
> process for making such decisions, and show that we can separate the
> meaningful underlying principles, such as the coin limit and overall
> inflation rate, from what is more akin to an implementation detail, as I
> consider the large-step reward reduction to be.
>
> I'm not too worried about the impact of the having as is, but adjusting the
> economic parameter would be a safer and simpler way to address the concerns
> than to tinker with the difficulty targeting mechanism, which is at the
> heart of Bitcoin's security
>
> On Wed, Mar 2, 2016 at 6:56 AM, Luke Dashjr via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> > We are coming up on the subsidy halving this July, and there have been some
> > concerns raised that a non-trivial number of miners could potentially drop
> > off
> > the network. This would result in a significantly longer block interval,
> > which
> > also means a higher per-block transaction volume, which could cause the
> > block
> > size limit to legitimately be hit much sooner than expected. Furthermore,
> > due
> > to difficulty adjustment being measured exclusively in blocks, the time
> > until
> > it adjusts to compensate would be prolonged.
> >
> > For example, if 50% of miners dropped off the network, blocks would be
> > every
> > 20 minutes on average and contain double the transactions they presently
> > do.
> > Even double would be approximately 850-900k, which potentially bumps up
> > against the hard limit when empty blocks are taken into consideration. This
> > situation would continue for a full month if no changes are made. If more
> > miners drop off the network, most of this becomes linearly worse, but due
> > to
> > hitting the block size limit, the backlog would grow indefinitely until the
> > adjustment occurs.
> >
> > To alleviate this risk, it seems reasonable to propose a hardfork to the
> > difficulty adjustment algorithm so it can adapt quicker to such a
> > significant
> > drop in mining rate. BtcDrak tells me he has well-tested code for this in
> > his
> > altcoin, which has seen some roller-coaster hashrates, so it may even be
> > possible to have such a proposal ready in time to be deployed alongside
> > SegWit
> > to take effect in time for the upcoming subsidy halving. If this slips, I
> > think it may be reasonable to push for at least code-readiness before July,
> > and possibly roll it into any other hardfork proposed before or around that
> > time.
> >
> > I am unaware of any reason this would be controversial, so if anyone has a
> > problem with such a change, please speak up sooner rather than later. Other
> > ideas or concerns are of course welcome as well.
> >
> > Thanks,
> >
> > Luke
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--
Henning Kopp
Institute of Distributed Systems
Ulm University, Germany
Office: O27 - 3402
Phone: +49 731 50-24138
Web: http://www.uni-ulm.de/in/vs/~kopp

2023-06-07 19:49:01

- reply

📅 Original date posted:2016-02-10
📝 Original message:Hi Jeremy,
> My understanding of the paper is that the blinding factor would be included
> in the extra data which is incorporated into the ring signatures used in the
> range proof.
Yep, that is a possibility. The blinding factor could be encrypted
with the public key of the receiver. Thus it is only visible for the
receiver who can then check that the correct amount has been sent.
> Although, since I think the range proof is optional for single output
> transactions (or at least, one output per transaction doesn't require a
> range proof since there's only one possible value that it can be to make the
> whole thing work, and that value must be in range, I'm not entirely sure how
I understand and agree.
> you'd transmit it then, though in any case, since using it will pretty much
> require segwit, adding extraneous data isn't much of a problem. In both
> cases, I imagine the blinding factor would be protected from outside
> examination via some form of shared secret generation... Although that would
> require the sender to know the recipient's unhashed public key; I don't know
> of any shared secret schemes that will work on hashed keys.
Here you lost me.
Why do we need to create a shared secret? Is this shared secret used
as the blinding factor?
Also I think the sender knows the unhashed public key of the receiver.
The only reason not to include it in the transaction script is that an
external observer is unable to see the receiver directly in the
blockchain.
Best
Henning
On Tue, Feb 09, 2016 at 04:12:37PM -0600, Jeremy Papp via bitcoin-dev wrote:
> My understanding of the paper is that the blinding factor would be included
> in the extra data which is incorporated into the ring signatures used in the
> range proof.
>
> Although, since I think the range proof is optional for single output
> transactions (or at least, one output per transaction doesn't require a
> range proof since there's only one possible value that it can be to make the
> whole thing work, and that value must be in range, I'm not entirely sure how
> you'd transmit it then, though in any case, since using it will pretty much
> require segwit, adding extraneous data isn't much of a problem. In both
> cases, I imagine the blinding factor would be protected from outside
> examination via some form of shared secret generation... Although that would
> require the sender to know the recipient's unhashed public key; I don't know
> of any shared secret schemes that will work on hashed keys.
>
> Jeremy Papp
>
> On 2/9/2016 7:12 AM, Henning Kopp via bitcoin-dev wrote:
> >Hi all,
> >
> >I am trying to fully grasp confidential transactions.
> >
> >When a sender creates a confidential transaction and picks the blinding
> >values correctly, anyone can check that the transaction is valid. It
> >remains publically verifiable.
> >But how can the receiver of the transaction check which amount was
> >sent to him?
> >I think he needs to learn the blinding factor to reveal the commit
> >somehow off-chain. Am I correct with this assumption?
> >If yes, how does this work?
> >
> >All the best
> >Henning
> >
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--
Henning Kopp
Institute of Distributed Systems
Ulm University, Germany
Office: O27 - 3402
Phone: +49 731 50-24138
Web: http://www.uni-ulm.de/in/vs/~kopp

2023-06-07 17:41:28

- reply

📅 Original date posted:2015-07-02
📝 Original message:Hi Jean-Paul,
that's a very interesting point of view and I have never thought about
it this way, since I have a totally different background.
How would you go on about defining a min spec? Is this done by testing
the software on different hardware configurations or are you looking
at the requirements a priori?
Best regards
Henning
On Wed, Jul 01, 2015 at 09:04:19PM -0700, Jean-Paul Kogelman wrote:
> Hi folks,
>
> I’m a game developer. I write time critical code for a living and have to deal with memory, CPU, GPU and I/O budgets on a daily basis. These budgets are based on what we call a minimum specification (of hardware); min spec for short. In most cases the min spec is based on entry model machines that are available during launch, and will give the user an enjoyable experience when playing our games. Obviously, we can turn on a number of bells and whistles for people with faster machines, but that’s not the point of this mail.
>
> The point is, can we define a min spec for Bitcoin Core? The number one reason for this is: if you know how your changes affect your available budgets, then the risk of breaking something due to capacity problems is reduced to practically zero.
>
> One way of doing so is to work backwards from what we have right now: Block size (network / disk I/O), SigOps/block (CPU), UTXO size (memory), etc. Then there’s Pieter’s analysis of network bottlenecks and how it affects orphan rates that could be used to set some form of cap on what transfer time + verification time should be to keep the orphan rate at an acceptable level.
>
> So taking all of the above (and more) into account, what configuration would be the bare minimum to comfortably run Bitcoin Core at maximum load and can it be reasonably expected to still be out there in the field running Bitcoin Core? Also, can the parameters that were used to determine this min spec be codified in some way so that they can later be used if Bitcoin Core is optimized (or extended with new functionality) and see how it affects the min spec? Basically, with any reasonably big change, one of the first questions could be: “How does this change affect min spec?"
>
> For example, currently OpenSSL is used to verify the signatures in the transactions. The new secp256k1 implementation is several times faster than (depending on CPU architecture, I’m sure) OpenSSL’s implementation. So it would result in faster verification time. This can then result in the following things; either network I/O and CPU requirements are adjusted downward in the min spec (you can run the new Bitcoin Core on a cheaper configuration), or other parameters can be adjusted upwards (number of SigOps / transaction, block size?), through proper rollout obviously. Since we know how min spec is affected by these changes, they should be non-controversial by default. Nobody running min spec is going to be affected by it, etc.
>
> Every change that has a positive effect on min spec (do more on the same hardware) basically pushes the need to start following any of the curve laws (Nielsen, Moore) forward. No need for miners / node operators to upgrade.
>
> Once we hit what we call SOL (Speed Of Light, the fastest something can go on a specific platform) it’s time to start looking at periodically adjusting min spec upwards, or by that time maybe it’s possible to use conservative plots of the curve laws as a basis.
>
> Lastly, a benchmark test could be developed that can tell everyone running Bitcoin Core how their setup compares to the min spec and how long they can expect to run on this setup.
>
> What do you guys think?
>
>
> jp
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--
Henning Kopp
Institute of Distributed Systems
Ulm University, Germany
Office: O27 - 3402
Phone: +49 731 50-24138
Web: http://www.uni-ulm.de/in/vs/~kopp