Re: [bitcoin-dev] Transition to post-quantum

On Tue, 2018-02-13 at 08:32 +1100, Tristan Hoy wrote: > In a post-quantum world, your second "d" type transaction is > completely forgeable, which means it is vulnerable to front-running. > An adversary capable of breaking ECDSA needs only listen for these > transactions, obtain "classic_sk" and

Re: [bitcoin-dev] Revisiting BIP 125 RBF policy.

On February 12, 2018 5:58 PM, Peter Todd via bitcoin-dev wrote: > I don't actually see where the problem is here. First of all, suppose we have > a > transaction T_a that already pays Alice with a feerate sufficiently high that > we expect it to get

Re: [bitcoin-dev] [BIP] Stratum protocol specification

When we worked on the extensions for RSK merge mining, I prepared an internal document with the most up to date Straum protocol description I could get. This is the document: https://docs.google.com/document/d/1ocEC8OdFYrvglyXbag1yi8WoskaZoYuR5HGhwf0hWAY/edit?usp=sharing Regards On Fri, Feb 9,

Re: [bitcoin-dev] Revisiting BIP 125 RBF policy.

On Mon, Feb 12, 2018 at 6:42 PM, Peter Todd wrote: > On Mon, Feb 12, 2018 at 06:19:40PM -0500, Russell O'Connor wrote: > > On Mon, Feb 12, 2018 at 5:58 PM, Peter Todd wrote: > > > > > > > > I don't actually see where the problem is here. First of all,

Re: [bitcoin-dev] Revisiting BIP 125 RBF policy.

On Mon, Feb 12, 2018 at 06:19:40PM -0500, Russell O'Connor wrote: > On Mon, Feb 12, 2018 at 5:58 PM, Peter Todd wrote: > > > > > I don't actually see where the problem is here. First of all, suppose we > > have a > > transaction T_a that already pays Alice with a feerate

Re: [bitcoin-dev] Revisiting BIP 125 RBF policy.

On Mon, Feb 12, 2018 at 5:58 PM, Peter Todd wrote: > > I don't actually see where the problem is here. First of all, suppose we > have a > transaction T_a that already pays Alice with a feerate sufficiently high > that > we expect it to get mined in the near future. If we

Re: [bitcoin-dev] Revisiting BIP 125 RBF policy.

On Mon, Feb 12, 2018 at 10:52:30AM -0500, Russell O'Connor via bitcoin-dev wrote: > I think it is worth revisiting BIP 125's replace-by-fee policy for when to > replace transactions. > > The current policy can be problematic. As noted earlier by Rhavar, > sometimes one's transaction becomes

Re: [bitcoin-dev] Total fees have almost crossed the block reward

Peter Todd via bitcoin-dev writes: > Does shabang.io say anywhere how it determines whether or not a transaction > funded a Lightning channel? My guess they simply collect the short_channel_ids which point to on-chain outputs that funded a channel. This

Re: [bitcoin-dev] Total fees have almost crossed the block reward

On Mon, Feb 12, 2018 at 06:23:35PM +0100, Melvin Carvalho via bitcoin-dev wrote: > Finally, I came across this wonderful site that shows lightning network > adoption on mainnet > > http://shabang.io/ > > LN is increasing well. Some blocks are not far off 1% lightning funding, > which I think

Re: [bitcoin-dev] Total fees have almost crossed the block reward

> This lead me to ponder whether the intuitive metric of satoshi/byte is, in > fact, game >theory optimal.  Possibly over the short term it is, but over a longer period, >those > wishing to increase the longevity of proof of work in general might wish to > consider > more progressive fee

Re: [bitcoin-dev] Revisiting BIP 125 RBF policy.

Thank you very much for writing this up.  It's worth noting that there can be multiple roots for the transactions that are getting replaced. So for rule 3, you probably want a feeRate >= the max "package fee rate" of all replaced roots. I am very happy with this proposal in general, as it's

Re: [bitcoin-dev] Total fees have almost crossed the block reward

On 21 December 2017 at 22:30, Melvin Carvalho wrote: > I asked adam back at hcpp how the block chain would be secured in the long > term, once the reward goes away. The base idea has always been that fees > would replace the block reward. > > At that time fees were

[bitcoin-dev] Revisiting BIP 125 RBF policy.

I think it is worth revisiting BIP 125's replace-by-fee policy for when to replace transactions. The current policy can be problematic. As noted earlier by Rhavar, sometimes one's transaction becomes pinned making it infeasible to fee bump with RBF. This happens when one makes a normal payment

Re: [bitcoin-dev] Transition to post-quantum

Hi Tristan, Regarding the "Post-Quantum Address Recovery" part (I haven't read the other parts), you may be interested in my message to the list from last month and the rest of the thread: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-January/015659.html This is an approach which

[bitcoin-dev] Transition to post-quantum

Hi all, Recently I've been exploring what a post-quantum attack on Bitcoin would actually look like, and what options exist for mitigating it. I've put up a draft of my research here: https://medium.com/@tristanhoy/11271f430c41 In summary: 1) None of the recommended post-quantum DSAs (XMSS,