Re: [bitcoin-dev] maximum block height on transaction

2021-04-09 Thread Jeremy via bitcoin-dev
You could accomplish your rough goal by having: tx A: desired expiry at H tx B: nlocktime H, use same inputs as A, create outputs equivalent to inputs (have to be sure no relative timelocks) Thus after a timeout the participants in A can cancel the action using TX B. The difference is the

Re: [bitcoin-dev] Proposal: Bitcoin Secure Multisig Setup

2021-04-09 Thread Sjors Provoost via bitcoin-dev
Thanks for the detailed response. Just 1 thing I needed to clarify: > To the list of concerns at the top of the BIP, I would add one: losing > multisig setup context. E.g. in the event of a fire where you only recover > your steel engraved mnemonic(s), but no longer have the wallet descriptors.

Re: [bitcoin-dev] Proposal: Bitcoin Secure Multisig Setup

2021-04-09 Thread Hugo Nguyen via bitcoin-dev
(Continue off last email: also keep in mind, that just like BIP174, Coordinator and Signer are abstract roles. This means in theory a Signer can be the Coordinator too. The same criteria for trust applies equally to a Signer and a Coordinator.) The use case I personally find most interesting is

Re: [bitcoin-dev] Proposal: Bitcoin Secure Multisig Setup

2021-04-09 Thread Hugo Nguyen via bitcoin-dev
Hi Sjors Thanks for the feedback! The first step is for the Coordinator to generate a TOKEN, presumably using > its own entropy. But IIUC anyone who intercepts that token can decrypt any > future step in the setup process. This suggests a chicken-egg problem where > you need some pre-existing

Re: [bitcoin-dev] Proposal: Bitcoin Secure Multisig Setup

2021-04-09 Thread Sjors Provoost via bitcoin-dev
Hi all, First of all thanks for your continued work on standardising multisig setup. The use case I personally find most interesting is not a multi-party setup, but rather just combining a bunch of my own devices. Those might even be in the same room during the setup, only to be moved to my

Re: [bitcoin-dev] maximum block height on transaction

2021-04-09 Thread Russell O'Connor via bitcoin-dev
>From https://bitcointalk.org/index.php?topic=1786.msg22119#msg22119: We can't safely do OP_BLOCKNUMBER. In the event of a block chain reorg > after a segmentation, transactions need to be able to get into the chain in > a later block. The OP_BLOCKNUMBER transaction and all its dependants would

Re: [bitcoin-dev] Update on "Speedy" Trial: The circus rolls on

2021-04-09 Thread Michael Folkson via bitcoin-dev
I have no problem with coin tosses to decide for example shed colors (an illustrative example discussed by copumpkin, roasbeef on IRC). In this kind of example everyone should recognize it doesn't matter and Approach ACK two competing PRs. No one should be NACKing or Approach NACKing a PR based on

[bitcoin-dev] An Electrum server using libbitcoin

2021-04-09 Thread Ivan J. via bitcoin-dev
Hi. I've been working on an Electrum server implementation that uses zmq and libbitcoin as its backend. I wanted to use the Electrum wallet with my libbitcoin server and this makes it possible now with (unfinished) libbitcoin v4. The code is here: https://github.com/parazyd/obelisk (Yes, it's

[bitcoin-dev] maximum block height on transaction

2021-04-09 Thread Erik Aronesty via bitcoin-dev
is there any way to specify a maximum block height on a transaction? ie: this tx is only valid if included in a block with a certain height or less i feel like this would be useful ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org