Re: [bitcoin-dev] BIP proposal: Inhibiting a covert attack on the Bitcoin POW function

2017-04-07 Thread Jannes Faber via bitcoin-dev
On 6 April 2017 at 19:13, Alex Mizrahi via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > > Ethically, this situation has some similarities to the DAO fork. > > > Much better analogy: > > 1. An ISV make software which makes use of an undocumented OS feature. > 2. That feature is no

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

2016-08-09 Thread Jannes Faber via bitcoin-dev
Wow. No value judgement, but 1980 called, they want their radio broadcast for analogue modems back. Both very cool and very cringe worthy. It sounds quite horrible tbh. Imagine this being as pervasive as bar and qr codes. And it's as meaningful and unpleasant to the human ear as a qr code is to

Re: [bitcoin-dev] Making AsicBoost irrelevant

2016-05-11 Thread Jannes Faber via bitcoin-dev
On 11 May 2016 at 16:18, Sergio Demian Lerner via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Jorge Timón said.. > > What do you mean by "embrace" in the context of a patented optimization > that one miner can prevent the rest from using? > > Everyone seems to assume that one

Re: [bitcoin-dev] Making AsicBoost irrelevant

2016-05-11 Thread Jannes Faber via bitcoin-dev
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

[bitcoin-dev] Best (block nr % 2016) for hard fork activation?

2016-01-28 Thread Jannes Faber via bitcoin-dev
Hi, Question if you'll allow me. This is not about Gavin's latest hard fork proposal but in general about any hard (or soft) fork. I was surprised to see a period expressed in human time instead of in block time: > Blocks with timestamps greater than or equal to the triggering block's timestamp

Re: [bitcoin-dev] Segregated Witness features wish list

2015-12-11 Thread Jannes Faber via bitcoin-dev
Segregated IBLT I was just wondering if it would make sense when we have SW to also make Segregated IBLT? Segregating transactions from signatures and then tune the parameters such that transactions have a slightly higher guarantee and save a bit of space on the signatures side. IBLT should of

Re: [bitcoin-dev] OP_CHECKWILDCARDSIGVERIFY or "Wildcard Inputs" or "Coalescing Transactions"

2015-11-24 Thread Jannes Faber via bitcoin-dev
Few issues I can think of: 1. In its basic form this encourages address reuse. Unless the wildcard can be constructed such that it can match a whole branch of an HD wallet. Although I guess that would tie all those addresses together making HD moot to begin with. 2. Sounds pretty dangerous