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

On Thu, Apr 06, 2017 at 01:32:03AM +, Gregory Maxwell wrote: > On Thu, Apr 6, 2017 at 12:39 AM, Joseph Poon wrote: > > #bitcoin@freenode: > > 00:04gmaxwell| lol poon pretending that he isn't complicit in all this > > stuff. > > > > Are you *fucking* serious? Is

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

Ahh, sorry all for this public message. :( On Wed, Apr 05, 2017 at 05:39:00PM -0700, Joseph Poon wrote: > #bitcoin@freenode: > 00:04gmaxwell| lol poon pretending that he isn't complicit in all this > stuff. > > Are you *fucking* serious? Is this how you resolve all problems? I'm > taking

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

#bitcoin@freenode: 00:04gmaxwell| lol poon pretending that he isn't complicit in all this stuff. Are you *fucking* serious? Is this how you resolve all problems? I'm taking you seriously and having second thoughts and want to make public commitments to do the right thing without any

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

Hi Greg, On Wed, Apr 05, 2017 at 09:37:45PM +, Gregory Maxwell via bitcoin-dev wrote: > Reverse engineering of a particular mining chip has demonstrated > conclusively that ASICBOOST has been implemented > in hardware. > > On that basis, I offer the following BIP draft for discussion. > This

Re: [bitcoin-dev] New BIP: Dealing with OP_IF and OP_NOTIF malleability in P2WSH

I agree this is an interesting area of transaction malleability to still consider in the future, and minimization of these areas of malleability with regards to its impact on the p2p network should be easy to resolve and (hopefully) well-understood by script writers in the future. On Tue, Aug 16,

Re: [bitcoin-dev] SIGHASH_NOINPUT in Segregated Witness

Hi Bryan, On Thu, Feb 25, 2016 at 07:34:24PM -0600, Bryan Bishop wrote: > Well if you are bothering to draft up a BIP about that SIGHASH flag, > then perhaps also consider some other SIGHASH flag types as well while > you are at it? I'll take a look at those proposals when drafting the BIP. I

Re: [bitcoin-dev] SIGHASH_NOINPUT in Segregated Witness

Hi Greg, On Fri, Feb 26, 2016 at 01:32:34AM +, Gregory Maxwell wrote: > I think to be successful we must be absolutely ruthless about changes > that go in there beyond the absolute minimum needed for the safe > deployment of segwit... so I think this should probably be constructed > as a new

[bitcoin-dev] SIGHASH_NOINPUT in Segregated Witness

As Segregated Witness will be merged soon as a solution for transaction malleability, especially with multi-party adversarial signatures, there may be an additional use case/functionality which is helpful for Lightning Network and possibly other Bitcoin use cases. This requires a new SIGHASH flag

Re: [bitcoin-dev] CHECKSEQUENCEVERIFY - We need more usecases to motivate the change

Hi Peter, On Sat, Oct 03, 2015 at 04:30:56PM +0200, Peter Todd via bitcoin-dev wrote: > So we need to make the case for two main things: > > 1) We have applications that need a relative (instead of absolute CLTV) Lightning network needs RCLTV for bidireciontal payment channels without an

Re: [bitcoin-dev] [BIP-draft] CHECKSEQUENCEVERIFY - An opcode for relative locktime

On Wed, Aug 19, 2015 at 09:21:36AM -0700, Mark Friedenbach via bitcoin-dev wrote: If anyone feels strongly about this, please speak up. On Wed, Aug 19, 2015 at 3:37 AM, Jorge Tim??n bitcoin-dev@lists.linuxfoundation.org wrote: I repeated my nit on

Re: [bitcoin-dev] What Lightning Is

Hi Gavin, On Sun, Aug 09, 2015 at 06:44:08PM -0400, Gavin Andresen via bitcoin-dev wrote: I'd love to see somebody write up a higher-level description of what the user experience is like, what communication happens underneath, and what new pieces of infrastructure need to get built to make it

Re: [bitcoin-dev] Off-chain transactions and miner fees

Hi, On Mon, Aug 10, 2015 at 12:20:36AM +0200, info--- via bitcoin-dev wrote: Off-chain transactions, whether it's Lightning or something else, potentially extract fees, which may otherwise be paid to miners, if the transactions were actually on-chain. In this context, wouldn't it be

Re: [bitcoin-dev] What Lightning Is

Hi Hector, On Sun, Aug 09, 2015 at 09:48:41PM +0100, Hector Chu via bitcoin-dev wrote: Is the Lightning system limited in the number of hops there can be in the payment channel? I am looking at the initial Lightning slides presented in February and it looks like the locktime decrements by