[Bitcoin-development] OpenSSL 1.0.0p / 1.0.1k incompatible, causes blockchain rejection.

2015-01-09 Thread Gregory Maxwell
OpenSSL 1.0.0p / 1.0.1k was recently released and is being pushed out by various operating system maintainers. My review determined that this update is incompatible with the Bitcoin system and could lead to consensus forks. Bitcoin Core released binaries from Bitcoin.org are unaffected, as are

Re: [Bitcoin-development] OpenSSL 1.0.0p / 1.0.1k incompatible, causes blockchain rejection.

2015-01-09 Thread Peter Todd
On Sat, Jan 10, 2015 at 04:26:23AM +, Gregory Maxwell wrote: The incompatibility is due to the OpenSSL update changing the behavior of ECDSA validation to reject any signature which is not encoded in a very rigid manner. This was a result of OpenSSL's change for CVE-2014-8275 Certificate

Re: [Bitcoin-development] A look back and a look forward

2015-01-09 Thread 21E14
I think the observation about Target vs Bitcoin exchanges is a sharp one, but I'm not sure how your proposal helps. You say it's an optional identity layer, but obviously any thief is going to opt out of being identified. Let me translate it to this year's vocabulary. Think of BCIs as a

Re: [Bitcoin-development] Bi-directional micropayment channels with CHECKLOCKTIMEVERIFY

2015-01-09 Thread Mike Hearn
The original design is documented at the bottom of here: https://en.bitcoin.it/wiki/Contracts#Example_7:_Rapidly-adjusted_.28micro.29payments_to_a_pre-determined_party In this design, time locked transactions can be broadcast across the network and replaced by broadcasting a new transaction that

Re: [Bitcoin-development] A look back and a look forward

2015-01-09 Thread Mike Hearn
This needn't be so, once an optional identity layer, modeled after the Internet itself, is provided, as proposed in late August of last year on this mailing list I think the observation about Target vs Bitcoin exchanges is a sharp one, but I'm not sure how your proposal helps. You say it's

Re: [Bitcoin-development] Bi-directional micropayment channels with CHECKLOCKTIMEVERIFY

2015-01-09 Thread Mike Hearn
A limitation on most existing micropayment channel ideas is that payments can only flow in one direction. It's worth noting that the original protocol as designed by Satoshi did not have this limitation. It has evolved this way because of ad-hoc DoS fixes over time (btw I'm not saying they

Re: [Bitcoin-development] Bi-directional micropayment channels with CHECKLOCKTIMEVERIFY

2015-01-09 Thread Jeff Garzik
Mike, Can you be more specific? You reference original design without saying how it was different/better. On Fri, Jan 9, 2015 at 8:20 AM, Mike Hearn m...@plan99.net wrote: A limitation on most existing micropayment channel ideas is that payments can only flow in one direction. It's worth

Re: [Bitcoin-development] Bi-directional micropayment channels with CHECKLOCKTIMEVERIFY

2015-01-09 Thread Gregory Maxwell
On Fri, Jan 9, 2015 at 1:20 PM, Mike Hearn m...@plan99.net wrote: A limitation on most existing micropayment channel ideas is that payments can only flow in one direction. It's worth noting that the original protocol as designed by Satoshi did not have this limitation. It has evolved this way

[Bitcoin-development] Bi-directional micropayment channels with CHECKLOCKTIMEVERIFY

2015-01-09 Thread Nathan Cook
A limitation on most existing micropayment channel ideas is that payments can only flow in one direction. This is because the payment receiver can sign -any- transaction you send them, not just the most recent one, and so it's possible to just sign the transaction transferring the largest amount

Re: [Bitcoin-development] Bi-directional micropayment channels with CHECKLOCKTIMEVERIFY

2015-01-09 Thread Gregory Maxwell
On Fri, Jan 9, 2015 at 1:42 PM, Mike Hearn m...@plan99.net wrote: Additionally, there is a school of thought that says Bitcoin must work even if lots of miners are malicious and willing to break arbitrary things in order to try and get more money. I don't think Bitcoin can really be a This