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 coin
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.
(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 no
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 secu
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 moo
>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
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
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 nam
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
https
