Could this be addressed with an OP_CSV_ALLINPUTS, a covenant opcode that
requires *all* inputs to have a matching nSequence, and using `1
OP_CSV_ALLINPUTS` in the HTLC preimage branch?
This would prevent using unconfirmed outputs in the HTLC-preimage-spending
transaction entirely, which IIUC shoul
Hi Giuseppe,
One side-effect this has is that until enough fees accumulate in the
mempool to satisfy min_fees, the rational behaviour for miners would be to
try and fork the chain tip, competing for the fees in the latest block
(+whatever got into the mempool in the meanwhile and can fit in). This
> Since Taproot (more generally any kind of MAST) spends have variable size
Isn't this the case with any arbitrary script execution? Non-taproot
P2(W)SH can also have multiple (OP_IF-gated) script branches. For example
with ` CHECKSIG IF SHA256 EQUALVERIFY ENDIF`, Mallory can
initially demonstrat
On Sat, May 7, 2022 at 5:08 PM ZmnSCPxj via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> * Even ***with*** `OP_CAT`, the following will enable non-recursive
covenants without enabling recursive covenants:
> * `OP_CTV`, ...
> * With `OP_CAT`, the following would enable recursive co
> via `sha_sequences`
Since you cannot expect txid stability with >1 inputs either way[0], it
should be sufficient to commit just to the current input's
nSequence/scriptSig to get txid stability for single input transactions. I
chatted with Jeremy about this and he appears to agree.
Not committin
Hi darosior,
It's interesting to note that APOAS|SINGLE (with the ANYONECANPAY behaviour
and without covering the spent input index) has some interesting uses for
cases where the covenant only needs to restrict a single output (so useful
for e.g. vaults or spacechains, but not for batch channels o
Correction: thinking about this some more, you can't actually expect to
have a stable txid if you allow additional inputs at all...
So yes, amending BIP 118 to commit to sha_sequences (which indirectly also
commits to the number of inputs) as proposed in the OP should be sufficient
to get stable t
> This is *literally* what the post you are replying to is proposing to
solve.
I thought the changes mentioned in the OP (+ committing to the spent input
index) only solves the half-spend problem, but not the stable txids one?
There can be other inputs with a scriptSig, which doesn't get committe
Here's a summary of the trade-offs I see for using APO as a CTV alternative:
1. The resulting txids are not stable.
CTV commits to enough tx information such that given the txid:vout of the
covenant-encumbered output, you can predict the txid of the spending tx
permitted by CTV (and of the entire
> The whole point of a wallet vault is that you can get the security of a
multisig wallet without having to sign using as many keys.
In my view, the point of a vault is the ability to keep your primary wallet
keys in *highly* deep cold storage (e.g. metal backup only, not loaded on
any HW wallets,
Back in the 2017 block size wars I brought up the idea [0] of using
time-locked-weighted voting as a mechanism to gauge community/hodler
sentiment (lived on testnet for awhile at https://hodl.voting [1]).
Basically, the user locks up some bitcoins with an OP_CSV while committing
to some statement
On Mon, Apr 25, 2022 at 1:36 PM Billy Tetrud via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> If you unvault an output to your hot wallet, the thief could be lying in
wait, ready to steal those funds upon them landing.
One way to mitigate some of the risk is to split up your UTXO
darosior via bitcoin-dev wrote:
> i doubt CTV is necessary nor sufficient for this
I would be interested to hear more on this.
Is it not necessary because you can exchange and store pre-signed
transactions instead?
What purpose is it not sufficient for? There are some vault designs out
there tha
darosior via bitcoin-dev wrote:
> CTV advocates have been presenting vaults as the flagship usecase.
Although as someone who've been trying to
> implement practical vaults for the past 2 years i doubt CTV is necessary
nor sufficient for this (but still
> useful!), using APO-AS covers it. And it's
> nobody's going to benefit from that possibility anyway.
James O'Beirne's simple-ctv-vault appears to be using bare CTV outputs:
https://github.com/jamesob/simple-ctv-vault/blob/7dd6c4ca25debb2140cdefb79b302c65d1b24937/main.py#L217-L218
https://github.com/jamesob/simple-ctv-vault/blob/7dd6c4ca2
> I didn't think DROP/1 is necessary here? Doesn't leaving the 32 byte hash
on the stack evaluate as true?
Not with Taproot's CLEANSTACK rule. It can make sense to always use `DROP
OP_1` even outside of Taproot, just to keep things consistent and to avoid
potential errors when switching from non-T
Having large portions of the network using a different minrelayfee could
make it easier to reliably get different parts of the network to accept
different conflicting transactions into their mempools, which could
potentially be used to double-spend unconfirmed non-rbf transactions with
more ease. N
Hi all,
I recently released Minsc, a high-level scripting language for expressing
Bitcoin Script spending conditions using a simple and familiar syntax.
Minsc is based on the Miniscript Policy language, with additional features
and syntactic sugar sprinkled on top, including variables, functions,
Hi ZmnSCPxj,
You are of course correct. I had considered the effect of reorgs, but the
email seemed to be getting too lengthy to mention that too.
You would need a few spare blocks in which Bob won't be accused of bribery
as a safety margin, which does reduce the time frame in which Alice can get
> I and some number of Lightning devs consider this to be sufficient
disincentive to Bob not attacking in the first place.
An additional disincentive could be introduced in the form of bribery
proofs for failed attempts.
If we assume that "honest" users of the LN protocol won't reveal their
timel
or wrote:
>
> Hi,
>
> I gave a quick look to the http API, and it seems very similar to Esplora's.
> So I wonder : how does
> bwt compares to Esplora, performance-wise ?
>
> Thanks!
> Antoine
>
>
> ‐‐‐ Original Message ‐‐‐
> Le samedi, mai 30, 2
Hi all,
I recently released bwt [0], an HD wallet indexer implemented in Rust, using
a model similar to that of Electrum Personal Server.
It uses the bitcoind wallet functionality to do the heavy lifting and builds
additional indexes on top of that, which can be queried using the Electrum
RPC pro
22 matches
Mail list logo
