Dear all,
I have been working on some constructions for cryptographic accumulators
that optimise for quick insertion.
As a brief background, an accumulator is a data structure that maintains
compact commitments to a potentially very large (and dynamic) set, while
keeping proofs of membership
Hi Andrew,
I just have a small suggestion on this proposal.
On Tue, 22 Jun 2021 at 23:29, Andrew Chow via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> | Taproot Leaf Script
> | PSBT_IN_TAP_LEAF_SCRIPT = 0x15
> |
> | The control block for this leaf as specified in BIP 341. The
Hi Andrew,
Thanks for the clarification, I was indeed reading it under the mistaken
assumption that only one leaf would be added to the PSBT.
En passant, for the less experienced readers, it might be helpful if the
key types that are possibly present multiple times (with different keydata)
were
Hi Hugo,
First of all, thank you for the impressive work on leading the
standardization efforts!
I believe one ought to more clearly distinguish the "Signer" (as in: one of
the parties in the multisig setup), from the "*Signing device*" (which is
likely a hardware wallet). BSMS defines a
Hi Andrew,
Thank you for putting this together; these standards will be of great
help for implementations.
The only concern I have is about the utility of supporting KEY
expressions inside musig to contain ranged derivations with `/*`.
Consider a wallet described as follows:
Hi Antoine,
Thanks for your comments and insights.
On Mon, 14 Aug 2023 at 05:01, Antoine Riard wrote:
> I think cross-input inspection (not cross-input signature
> aggregation which is different) is opening a pandora box in terms of
> "malicious" off-chain contracts than one could design. E.g
Hi all,
TL;DR: It is easy to convert from wallet policy to descriptors and back;
imho aliases are better left out of descriptors in real world usage; some
more examples given.
I received some very useful feedback on the wallet policy proposal (in this
list and outside); that also led me to
Hi Antoine and Billy,
Thank you for your comments and for looking into the proposal.
On Mon, 9 May 2022 at 12:36, darosior wrote:
> 1. The `` optimization for the common usecase of using 2
> descriptors at different derivation indices
>for receive and change. [1]
> 2. The `/**`
In the implementation work to implement descriptors and miniscript support
in hardware wallets [a][b], I encountered a number of challenges. Some of
them are technical in nature (e.g. due to constraints of embedded
development). Others are related to the attempts of shaping a good user
experience;
Hi list,
Following up on this topic, I now opened a pull request with the BIP
proposal:
https://github.com/bitcoin/bips/pull/1389
I also attempted a proof-of-concept of how an integration of wallet
policies to HWI might look like:
https://github.com/bitcoin-core/HWI/pull/647
which
Hello Rijndael,
On Wed, 30 Nov 2022 at 23:09, Rijndael wrote:
> Hello Salvatore,
>
> I found my answer re-reading your original post:
> > During the arbitration phase (say at the i-th leaf node of M_T), any
> party can win the challenge by providing correct values for tr_i = (st_i,
> op_i,
Hi Antoine,
Thanks for your very interesting suggestions!
On Mon, 23 Jan 2023 at 20:53, darosior wrote:
> Actually you can save a few more characters, and gain some clarity, by
> showing the "semantic policy" instead of the actual Miniscript. If the intent
> is for the user to verify the
Hi ZmnSCPxj, Bram, Peter, David,
Thanks for all your comments; replies below.
On Tue, 8 Nov 2022 at 13:01, ZmnSCPxj wrote:
> Modulo bugs, operator error, misconfigurations, and other irrationalities
> of humans.
>
I agree that making footguns impossible is a much more difficult problem to
Hi list,
I have been working on some notes to describe an approach that uses
covenants in order to enable general smart contracts in bitcoin. You can
find them here:
https://merkle.fun
The approach has a number of desirable features:
- small impact to layer 1;
- not application-specific,
Hi Antoine,
It appears that my explanation of the relationship between the covenant and
the bisection protocol is still unclear; I'll do my best to clarify.
The bisection's Merkle tree never ends up on-chain, in any form. Therefore,
a bigger computation does not end up in a bigger witness size,
Hello list,
TL;DR: the core opcodes of MATT can build vaults with a very similar design
to OP_VAULT. Code example here:
https://github.com/bitcoin-inquisition/bitcoin/compare/24.0...bigspider:bitcoin-inquisition:matt-vault
In my previous emails about the MATT proposal for smart contracts in
otentially
> substantial downside is that it seems the cryptography used to get those
> nice properties of Verkle trees isn't quantum safe. While a lot of things
> in Bitcoin seems to be going down the path of quantum-unsafe (I'm looking
> at you, taproot), there are still a lot of peo
Hi all,
I apologize for a couple of oversights in my last e-mail.
The first is that m_B can't be committed as-is in the contract's
embedded data, with the current semantics of OP_COCV, which
only allows 32-byte values. A solution could be to store its
hash SHA256(m_B), instead.
(I didn't test
23FEE0F
>
> Learn about Bitcoin: https://www.youtube.com/@portofbitcoin
>
> --- Original Message ---
> On Monday, April 24th, 2023 at 20:37, Salvatore Ingala via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> Hello list,
>
> TL;DR:
Hi Johan,
Exciting to finally see some merkleization, which was only confined
within the meme, up to this point!
> A simpler way IMO, would be to make OP_CICV and OP_COCV symmetrical:
> Have OP_CICV take an optional taproot and do the same check as is
> done for the output: Q ==
Hi all,
I have put together a first complete proposal for the core opcodes of
MATT [1][2].
The changes make the opcode functionally complete, and the
implementation is revised and improved.
The code is implemented in the following fork of the
bitcoin-inquisition repo:
Hi Dave,
I apologize for the confusion and the inconsistent use of plurals.
The reason I called it a "complete proposal" is that the opcode is
now functionally complete, unlike the previous attempt where the
approach for the output amount introspection was not yet specified.
The semantics are
Hi Johan,
Thanks a lot for the comments, and the independent implementation!
> - For the opcode parameter ordering, it feels unnatural for the two
> tweaks (data, taptree) to be separated by the internal key. A more
> natural ordering of parameters IMO would be (of course this is all
>
On Thu, 4 May 2023 at 10:34, Johan Torås Halseth wrote:
>
> It sounds like we can generalize the description of the construct to:
> Access to (the hash of) embedded data of inputs and outputs, and the
> enforcement of output keys and (static) taptrees. In other words, as
> long as you can
24 matches
Mail list logo
