[bitcoin-dev] Bitcoin and CVEs

Hi, Are there are any vulnerabilities in Bitcoin which have been fixed but not yet publicly disclosed? Is the following list of Bitcoin CVEs up-to-date? https://en.bitcoin.it/wiki/Common_Vulnerabilities_and_Exposures There have been no new CVEs posted for almost three years, except for

[bitcoin-dev] Fwd: [Mimblewimble] Lightning in Scriptless Scripts

-- Forwarded message -- From: Andrew Poelstra Date: Mon, Mar 20, 2017 at 5:11 PM Subject: [Mimblewimble] Lightning in Scriptless Scripts To: mimblewim...@lists.launchpad.net In my last post about scriptless scripts [2] I described a way to do

Re: [bitcoin-dev] Malice Reactive Proof of Work Additions (MR POWA): Protecting Bitcoin from malicious miners

> It's possible to switch PoW algorithms with a soft fork rather than a hard > fork. You put forward an interesting idea if it could work, but in the adversarial emergency where an entity is contentiously using a POW monopoly, a hard fork would likely be a far easier and more efficient

[bitcoin-dev] Inquiry: Transaction Tiering

Hi Team, I would like to find out what the current consensus on transaction tiering is. Background: The current protocol enables two parties to transact freely, however, transaction processors (block generators) have the authority to discriminate participants arbitrarily. This is well known and

Re: [bitcoin-dev] Malice Reactive Proof of Work Additions (MR POWA): Protecting Bitcoin from malicious miners

I am in support of having multiple PoW forks to choose from, but it is indeed problematic to have one chain running a rotation of algorithms. The reason I support multiple algos is because we don't want an attacker secretly making asics ahead of time in the event of an emergency PoW fork. We want

Re: [bitcoin-dev] Malice Reactive Proof of Work Additions (MR POWA): Protecting Bitcoin from malicious miners

Chain work currently means the expected number of sha256d evaluations needed to build a chain. Given that these hash functions are not equally hard, what should the new definition of chain work be? On Mon, Mar 20, 2017 at 9:38 AM, Andrew Johnson via bitcoin-dev <

Re: [bitcoin-dev] Malice Reactive Proof of Work Additions (MR POWA): Protecting Bitcoin from malicious miners

It's possible to switch PoW algorithms with a soft fork rather than a hard fork. You make it so that there are two different PoWs, the old one and the new one, and each old-style block has to reference a new-style block and contain the exact same transactions. The new work rule is that the

Re: [bitcoin-dev] Malice Reactive Proof of Work Additions (MR POWA): Protecting Bitcoin from malicious miners

Hi, Just a thought, Bitcoin developers shouldn't care about miners business model, they can always sell their hw and close the bz as soon as bitcoin hardforks to better ways of doing. Just focus on making a better cryptocurrency, the more decentralized the best. M > By doing this you're

Re: [bitcoin-dev] Malice Reactive Proof of Work Additions (MR POWA): Protecting Bitcoin from malicious miners

> By doing this you're significantly changing the economic incentives behind > bitcoin mining. How can you reliably invest in hardware if you have no idea > when or if your profitability is going to be cut by 50-75% based on a whim? Of course, that's why this is a last resort, successfully

[bitcoin-dev] Malice Reactive Proof of Work Additions (MR POWA): Protecting Bitcoin from malicious miners

I’m very worried about the state of miner centralisation in Bitcoin. I always felt the centralising effects of ASIC manufacturing would resolve themselves once the first mover advantage had been exhausted and the industry had the opportunity to mature. I had always assumed initial