Re: [bitcoin-dev] difficulty adjustment (was: The Nuclear Option: BIP148 + MR POWA)

2017-07-05 Thread Henning Kopp via bitcoin-dev
Hi,

> I would also highly advise finding a simple and robust difficulty adjustment
> that occurs every block instead of bitcoin/litecoin's 2016 block use.

I also thought about this some time ago. But note that this implies
that forks grow with the same block frequency as the main chain. Thus
the longest chain rule becomes irrelevant, since all chains will have
the same length (in expectancy). Rather, the chain with most work is
the true one.

Best
Henning


On Wed, Jul 05, 2017 at 02:02:08PM +, Troy Benjegerdes via bitcoin-dev 
wrote:
> The fastest way to triple Bitcoin capacity is to split the network into
> two or three different blockchains. We encourage forks of software, why
> are blockchains somehow different?
> 
> Yes, this is risky, and probably volatile.
> 
> I honestly don't expect lots of people with large amounts of money 
> invested (exchanges, financial institutions, etc) to go along with 
> something like this, and that say 90% of the wealth with stay concentrated
> in whatever chain has the majority SHA256 hashpower.
> 
> But as a game-theory excercise to see who's theories actually work?
> 
> I highly encourage a real-world test of all these theories.
> 
> I would also highly advise finding a simple and robust difficulty adjustment
> that occurs every block instead of bitcoin/litecoin's 2016 block use.
> 
> On Wed, Jul 05, 2017 at 09:18:36AM +, John Hardy via bitcoin-dev wrote:
> > This idea is highly contentious as it would guarantee a viable chain of 
> > Bitcoin with SegWit activated whether BIP148 gained sufficient support or 
> > not. I am not necessarily advocating it - just putting it out for 
> > discussion. While the downside is that it could permanently split the 
> > network, the upside is that it could heap additional pressure on miners to 
> > follow the BIP148 chain and ensure a minimally disruptive upgrade. This is 
> > pure game theory.
> > 
> > 
> > 
> > MR POWA (Mining Reactive Proof of Work Addition) is a method to introduce 
> > an additional proof of work to a blockchain in response to a detected 
> > mining behaviour.
> > 
> > 
> > 
> > In the case of BIP148, the criteria for activation could be when the 
> > software detects a non-BIP148 compliant chain that is 144 blocks (24 hours) 
> > ahead of a BIP148 compliant chain.
> > 
> > 
> > 
> > At this stage the software would change its consensus rules (hard fork) to 
> > do two things:
> > 
> >   *   Lower the difficulty for existing PoW method (SHA256).
> > 
> >   *   Introduce a second POW method, such as Scrypt or Ethash, that is 
> > incompatible with SHA256 hardware but already has an established mining 
> > industry for altcoins.
> > 
> > 
> > 
> > The difficulty should be low, and blocks will initially be found much more 
> > quickly than every 10 minutes until the difficulty adjusts. Each method 
> > would have its own difficulty. It could be a requirement that POW methods 
> > alternate to neutralise attacks from the other chain.
> > 
> > 
> > 
> > This would guarantee SegWit activation. Anybody who is already running a 
> > BIP148 node could just as easily run a BIP148 + MR POWA node. This could 
> > not realistically be supported by Core and would have to be implemented in 
> > a grassroots movement, similar to BIP148.
> > 
> > 
> > 
> > Ideally, it would just force the miners to follow the BIP148 chain (or risk 
> > the value of their hardware being hurt) and the code would never be 
> > activated. MR POWA would mean BIP148 miners would no longer need to ?hold 
> > their nerve? as they would be guaranteed a viable chain and rewarded for 
> > their early support.
> > 
> > 
> > Regards,
> > 
> > 
> > John Hardy
> > 
> > j...@seebitcoin.com
> > 
> > 
> 
> > ___
> > 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
> 

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


Re: [bitcoin-dev] Combining SPV and Stealth addresses

2017-05-06 Thread Henning Kopp via bitcoin-dev

Sorry, I cannot quite follow you. What do you mean with flag?

Best,
Henning


Am 04.05.2017 um 18:23 schrieb Chris Pacia:

Yes I've had it working using two pushes in op_return.

op_return op_pushdata  op_pushdata 

Flag goes in your filter. You anonymity set is all other transactions using
that same flag.

This is fairly decent privacy but the problem is you still need filter
matches on outgoing transactions to build a functioning wallet. So it might
not be an improvement over standard bloom filters but at least you can do
stealth if you want.

On May 4, 2017 9:00 AM, "Henning Kopp via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:


Hi all,

Recently I think a lot about combining Stealth addresses with SPV but
I did not come to a satisfying conclusion, so I post this as a
challenge to the wider community. Maybe you have an idea.

## Explanation of SPV
In SPV a thin client puts his public keys in a bloom filter
and asks a full node to give him Merkle proofs of all transactions
whose pubkey are in the bloom filter. Since a bloom filter has a lot
of false positives depending on the parameters, this gives privacy to
the thin client, since the full node cannot detect if a specific
transaction belongs to the thin client. This is cool if you want to
use Bitcoin on your smartphone.

## Explanation of Stealth Addresses
Stealth addresses on the other hand enable receiver privacy. The
sender of a transaction derives a one-time pubkey to which he sends the
money. The receiver can check if the money was sent to him and recover
the one-time private key. This is cool, since an observer cannot
decide if two payments belong to the same recipient. Further the
recipient needs only to have one pubkey.
For a more formal explanation see https://github.com/genjix/
bips/blob/master/bip-stealth.mediawiki#Reuse_ScanPubkey
I will use their notation in the following.

## The Problem
My line of thought was to combine stealth addresses with spv, so that
I can use stealth addresses on my smart phone without losing privacy.

Basically to check if a payment belongs to a pubkey (Q,R), the full
node needs to check if R' = R + H(dP)*G for each transaction. For this
it needs the private scanning key d.
This sucks, since when I give my d to a full node, he can link all my
transactions. For an online-wallet this may be okay, but not for thin
client synchronisation.

## Ideas
In the following I detail some ideas of me which did not work.

It does not suffice to have a Bloom filter and check if d is
contained since there is no way to recompute d from the equation. If
there were a way to recompute d, the scheme would offer no privacy,
since anyone could compute the private scanning key d and scan for
payments.
So, if we modify the scheme we need to be sure that d is kept private.

Multiparty computation may be possible in theory. The full node and
the thin client could collaboratively check R' = R + H(dP)*G, where d
is the private input of the thin client and R, R',P is provided by the
full node. But this is costly and they need to do it for each
transaction. It may be more costly than simply setting up a full node.

I do not think that some kind of search functionality without leaking
the search pattern (PIR?) would work, since the full node needs to compute
on the
data it has found. And further it needs to retrieve the whole Merkle
proofs.

Any better ideas?

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
___
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] Combining SPV and Stealth addresses

2017-05-04 Thread Henning Kopp via bitcoin-dev
Hi all,

Recently I think a lot about combining Stealth addresses with SPV but
I did not come to a satisfying conclusion, so I post this as a
challenge to the wider community. Maybe you have an idea.

## Explanation of SPV
In SPV a thin client puts his public keys in a bloom filter
and asks a full node to give him Merkle proofs of all transactions
whose pubkey are in the bloom filter. Since a bloom filter has a lot
of false positives depending on the parameters, this gives privacy to
the thin client, since the full node cannot detect if a specific
transaction belongs to the thin client. This is cool if you want to
use Bitcoin on your smartphone.

## Explanation of Stealth Addresses
Stealth addresses on the other hand enable receiver privacy. The
sender of a transaction derives a one-time pubkey to which he sends the
money. The receiver can check if the money was sent to him and recover
the one-time private key. This is cool, since an observer cannot
decide if two payments belong to the same recipient. Further the
recipient needs only to have one pubkey.
For a more formal explanation see 
https://github.com/genjix/bips/blob/master/bip-stealth.mediawiki#Reuse_ScanPubkey
I will use their notation in the following.

## The Problem
My line of thought was to combine stealth addresses with spv, so that
I can use stealth addresses on my smart phone without losing privacy.

Basically to check if a payment belongs to a pubkey (Q,R), the full
node needs to check if R' = R + H(dP)*G for each transaction. For this
it needs the private scanning key d.
This sucks, since when I give my d to a full node, he can link all my
transactions. For an online-wallet this may be okay, but not for thin
client synchronisation.

## Ideas
In the following I detail some ideas of me which did not work.

It does not suffice to have a Bloom filter and check if d is
contained since there is no way to recompute d from the equation. If
there were a way to recompute d, the scheme would offer no privacy,
since anyone could compute the private scanning key d and scan for
payments.
So, if we modify the scheme we need to be sure that d is kept private.

Multiparty computation may be possible in theory. The full node and
the thin client could collaboratively check R' = R + H(dP)*G, where d
is the private input of the thin client and R, R',P is provided by the
full node. But this is costly and they need to do it for each
transaction. It may be more costly than simply setting up a full node.

I do not think that some kind of search functionality without leaking
the search pattern (PIR?) would work, since the full node needs to compute on 
the
data it has found. And further it needs to retrieve the whole Merkle
proofs.

Any better ideas?

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


Re: [bitcoin-dev] SHA1 collisions make Git vulnerable to attakcs by third-parties, not just repo maintainers

2017-02-27 Thread Henning Kopp via bitcoin-dev
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 
> >  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 
> >  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" 
> >  escreveu:
> > 
> > > On Feb 24, 2017, at 7:01 PM, Peter Todd  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 als

Re: [bitcoin-dev] Bitcoin Currency

2016-12-14 Thread Henning Kopp via bitcoin-dev
Hi Ben,

not sure if this is the right mailing list for that. I think it rather
belongs to bitcoin-discuss.

And I am also not sure if I understand your question. What you may
mean is the private key of a user. If you find this, you can spend his
funds and also prove that you own the funds.

Depending on your level of understanding of Bitcoin, this blogpost may
be insightful for you:
http://www.michaelnielsen.org/ddi/how-the-bitcoin-protocol-actually-works/

All the best
Henning


On Tue, Dec 13, 2016 at 11:13:24AM +, Ben West via bitcoin-dev wrote:
> Hello all;
> is there any number or id that determine uniquely the BTC value.
> otherwise; is there any hash or address or key that when found we could say
> this is my 50BTC or my 20BTC ?.

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


Re: [bitcoin-dev] 1 Year bitcoin-dev Moderation Review

2016-10-10 Thread Henning Kopp via bitcoin-dev
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 
> 

> ___
> bitcoin-dev mailing list
> bitcoin-dev@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
___
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

2016-08-09 Thread Henning Kopp via bitcoin-dev
Hi Tony,

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

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

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

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

Best
Henning

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

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

2016-08-08 Thread Henning Kopp via bitcoin-dev
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

Re: [bitcoin-dev] Making AsicBoost irrelevant

2016-05-11 Thread Henning Kopp via bitcoin-dev
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@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
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


Re: [bitcoin-dev] Hardfork to fix difficulty drop algorithm

2016-03-09 Thread Henning Kopp via bitcoin-dev
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@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@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


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

Re: [bitcoin-dev] consensus rule change for TX fee safety

2016-03-03 Thread Henning Kopp via bitcoin-dev
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@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
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


Re: [bitcoin-dev] Question regarding Confidential Transactions

2016-02-10 Thread Henning Kopp via bitcoin-dev
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@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
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


[bitcoin-dev] Question regarding Confidential Transactions

2016-02-09 Thread Henning Kopp via bitcoin-dev
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

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