В Fri, 3 Jul 2020 21:53:44 +0500
Dmitry Petukhov via bitcoin-dev
wrote:
> The format for the path templates described in the presented BIP draft
> aims to provide a building block for interoperability between various
> hardware and software vendors in regard to this particular task of
>
IIUC, key origin identification specify chains of addresses, with
relation to specific keys. As the name suggests, they are for
identidication.
Path templates specify application-specific constraints for the
derivation paths. They are for imposing restrictions.
You could use path templates for
On Thu, Jul 02, 2020 at 09:28:39PM +0500, Dmitry Petukhov via bitcoin-dev wrote:
> I think there should be standard format to describe constraints for
> BIP32 paths.
>
> I present a BIP draft that specifies "path templates" for BIP32 paths:
>
>
Good morning Ittay,
> Hi all,
>
> Itay from MAD-HTLC here. I feel like some details got lost along the way so
> please let me get these sorted out.
>
> 1. Myopic and non-myopic miners:
> When we use the term myopic we mean a miner that optimizes transaction
> selection for the next block with
On Fri, Jul 3, 2020 at 12:17 PM ZmnSCPxj wrote:
>
> > In fact, one rule of thumb might be that wherever watchtowers are
> required, a timelocked bribe might be possible.
>
> I think a better heuristic is that, if the logic of the construction
> assumes "transaction with earlier locktime
Good morning Tejaswi,
> > But if an attack happens during a fee spike, then even though we retain our
> > current default `to_self_delay` of 144, we still have the ability to
> > gradually and automatically move to higher fee regions until our
> > transaction confirms, and we have a good
On Thu, Jul 2, 2020 at 6:06 PM ZmnSCPxj wrote:
> At fee spikes, this x will go higher, and thus (f - x) / (b - x) will be
> far smaller than f / b and might even become negative, in which case the
> Alice transaction will not be confirmed even by myopic miners, because the
> Alice transaction
