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

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

2017-05-06 Thread Henning Kopp via bitcoin-dev
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, "Hennin

[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

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 wi

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

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

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

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 c

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 percent

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 m

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 w

Re: [bitcoin-dev] Question regarding Confidential Transactions

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

[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