Hello Murch,
It makes sense to me too. Thanks!
Antoine
Original Message
On Apr 5, 2023, 8:54 PM, Murch via bitcoin-dev wrote:
> Hey everyone, Over the years, I have participated in a few conversations
> about various aspects of transactions. Often a chunk of the conversation
Hello Billy,
Yes it's basically a (simple) instantiation of Revault. You can find more at
[https://github.com/revault](https://github.com/revault/) (you most likely want
the `practical-revault` repo). There is a description of the concept, the
specification of a communication protocol between
Hello Salvatore,
It's not something about the specifications of wallet policies, but regarding
the guidelines for implementers on signing devices. Quoting BIP-wallet-policies:
> Moreover, other limitations like the limited size of the screen might affect
> what design choices are available in
Thanks for taking the time to write up about the implementation of output
descriptors on signing devices, and
for proposing a method to overcome encountered difficulties for the following
implementers.
I have some questions with regard to the modifications to the descriptor
language required
Hi Jacob,
I think you are a bit confused about how CTV and (tweaked) APO covenants
compare. Both would commit to the
same template, so one isn't "safer" than the other. Just more efficient in how
it commits to the template.
Replies on the specifics inline.
> While I agree with the arguments in
gt; https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020326.html
>
> [1] https://github.com/darosior/simple-anyprevout-vault
> [2] https://twitter.com/shesek/status/1519874493434544128
>
> On Fri, Apr 22, 2022 at 2:23 PM darosior via bitcoin-dev
> wrote:
- Original Message ---
Le lundi 25 avril 2022 à 6:57 PM, Nadav Ivgi a écrit :
> 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 pr
(and optionally scriptSigs).
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-June/017038.html
--- Original Message ---
Le lundi 25 avril 2022 à 3:35 PM, darosior via bitcoin-dev
a écrit :
> Hi Richard,
>
> > Sounds good to me. Although from an activation perspectiv
Hi Richard,
> Sounds good to me. Although from an activation perspective it may not be
> either/or, both proposals do
compete for scarce reviewer time
Yes, of course. Let's say i was more interested in knowing if people who oppose
CTV would oppose
SIGHASH_ANYPREVOUT too. I think talking about
would actually look like on an APO signet. Or to see
> some working code for a vault using covenants in an APO world.
>
> I haven’t seen much in the way of APO implementations recently, but I also
> haven’t gone looking, so would appreciate any links!
>
> Thanks
>
> On Fri
I would like to know people's sentiment about doing (a very slightly tweaked
version of) BIP118 in place of
(or before doing) BIP119.
SIGHASH_ANYPREVOUT and its precedent iterations have been discussed for over 6
years. It presents proven and
implemented usecases, that are demanded and (please
Hi Larry,
Thanks for bringing this up. I'm curious to know if this is helpful for pinning
as long as you have a way to
statically analyze Script to prevent witness stuffing [0]. I agree it *could*
still be useful for miners, but
subject to all the complications of RBF.
> An advantage of this
Hi ZmnSCPxj,
Thanks for the feedback. The DLC idea is interesting but you are centralizing
the liveness requirements,
effectively creating a SPOF: in order to bypass the revocation clause no need
to make sure to down each and
every watchtower anymore, just down the oracle and you are sure no
vault standard and guess other leaves and
>> replace the witness to use the highest-feeratespending path. You could
>> require a signature from any of the participants. Or, at the cost of
>> anadditional depth, in the tree you could "salt" each leaf by pairing it
>> w
The idea of a soft fork to fix dynamic fee bumping was recently put back on the
table. It might
sound radical, as what prevents today reasonable fee bumping for contracts with
presigned
transactions (pinning) has to do with nodes' relay policy. But the frustration
is understandable
given the
> Necromancing might be a reasonable name for attacks that work by getting an
> out-of-date version of a tx mined.
It's not an "attack"? There is no such thing as an out-of-date transaction, if
you signed and broadcasted it in the first place. You can't rely on the fact
that
a replacement
James,
You seem to imply that the scenario described isn't prevented today. It is. The
mempool acceptance for a replacement not only
depend on the transaction feerate but also the transaction fee [0]. That's why
i raised it in the first place...
Antoine
[0]
> Such a construct would present dangerous implications to the fungibility of
> individual UTXOs by introducing a totally different risk model in being paid
> with such a coin compared to any other coin not encumbered by such a condition
How is that different from being paid in an altcoin?
It
Well because in the example i gave you this decreases the miner's reward. The
rule of increasing feerate you stated isn't always economically rationale.
Note how it can also be extended, for instance if the miner only has 1.5vMB of
txs and is not assured to receive enough transactions to fill 2
(I have not yet read the recent posts on RBF but i wanted to react on the
"additive feerate".)
> # Purely additive feerate bumps should never be impossible
It's not that simple. As a miner, if i have less than 1vMB of transactions in
my mempool. I don't want a 10sats/vb transaction paying
ding that somewhere?) and you don't reveal the script, they don't
> see your timelock deadline yes?
It *could* be once we move to Taproot (2weeks). Yep! They would only know about
it on a successful spend which would reveal the branch with the timelock. It's
a good point in that the attack abo
aps could be found...
Unfortunately, given current mining centralisation, pools are in a very good
position to offer pretty decent SLAs around that. With a block space insurance,
you of course don't need all these convoluted fee-bumping hacks.
I'm very concerned that large stakeholders o
Hi everyone,
Fee-bumping is paramount to the security of many protocols building on Bitcoin,
as they require the
confirmation of a transaction (which might be presigned) before the expiration
of a timelock at any
point after the establishment of the contract.
The part of Revault using
Hi Niftynei,
I share the concerns raised about direct connections to mining pools being a
centralization pressure: de-anonymization and an inevitable higher barrier to
entry. Making it more difficult to reach smaller miners is another one.
Regarding fee estimation you state:
> Initial feerate
Hi Gloria,
> In summary, it seems that the decisions that might still need attention/input
> from devs on this mailing list are:
> 1. Whether we should start with multiple-parent-1-child or 1-parent-1-child.
> 2. Whether it's ok to require that the child not have conflicts with mempool
>
Hi Anthony,
This post is a follow-up to your insight on Twitter [0], sent here for better
posterity, accessibility and readability than Twitter. And also to motivate this
idea by giving another concrete [1] usecase for it.
Revault [2] is a multi-party "vault" protocol. It involves 2 sets of
Hi Jeremy,
I think it would be nice to have and suggested something similar (enforce
minimality) in the context of
Miniscript a few months ago [0].
However your code:
const bool seq_is_reserved = (txin.nSequence < CTxIn::SEQUENCE_FINAL-2) && (
// when sequence is set to disabled, it is
> Note, I think that the tx mutation proposal relies on interactivity in the
> worst-case scenario where a counterparty wants to increase its fee-bumping
> output from the contract balance. This interactivity may lure a counterparty
> to alway lock the worst-case fee-bumping reserve in the
Hi,
Another thing to consider when comparing these two techniques is anti-fee
sniping protection. If you are going to feebump directly
your revocation transaction by adding inputs to it, the nLockTime has already
been signed in advance. Therefore your are sponsoring
a transaction that could be
> Oh yes, I should have mentioned this pinning vector. The witnessScript I've
> in mind to make secure that type of chain of transactions would be one MuSig
> key for all contract participants, where signature are committed with
> SIGHASH_ANYPREVOUT | SIGHASH_IOMAP, one pubkey per participant
Hi,
> ## Input-Based
>
> I think input-based fee-bumping has been less studied as fee-bumping
> primitive for L2s [1]. One variant of input-based fee-bumping usable today is
> the leverage of the SIGHASH_ANYONECANPAY/SIGHASH_SINGLE malleability flags.
> If the transaction is the latest stage
Hi Antoine,
Thank you for the disclosure.
> * Onchain DLC/Coinswap/Vault : Those contract protocols have also multiple
> stages of execution with time-sensitive transactions opening the way to
> pinning attacks. Those protocols being non-deployed or in early phase, I
> would recommend that
Hi Antoine, and Kevin,
>> * Proposed improvement: The HW should display the Bitcoin Script itself when
>> possible (including the unlock conditions).
>
> What level of script literacy are you assuming on your users ? I can see
> enterprise/hobbyist folks to know enough of Script to understand
The fee bumping construction I described in the previous post is potentially
vulnerable
to transaction pinning.
We shared a SINGLE | ANYONECANPAY signature for the first (and only) input of
revaulting
transactions to allow any party to append an input and an output in order to
bump the
Hi all,
Kevin Loaec and I have been working on a new multiparty vault architecture and
I think it reached the point where we’d welcome some feedback.
Intended usage and limitations
==
The aim is to secure the shared storage of coins without relying on a trusted
35 matches
Mail list logo
