Hello list,
I have released B'SST: Bitcoin-like Script Symbolic Tracer
It can be found at https://github.com/dgpv/bsst
B'SST analyses Bitcoin and Elements scripts by symbolically executing
all possible execution paths, and tracking constraints that opcodes
impose on values they operate on. It
В Wed, 3 Aug 2022 20:16:52 -0500
Billy Tetrud wrote:
> A descriptor format is simply defining a space of address
> derivation paths. It is not describing in any way what each path is
> intended for - those are conventions outside the scope of this BIP
> IMO. Defining the conventions of
The issue with tuples of lenth more than two is that the purpose for
indexes beyond 'receive' and 'change' are not established, and
therefore various software might start to use extra indexes in a tuple
for their own non-standard purposes. This is bound to create
incompatibilities where different
he encryption key on a 80Mhz MCU. We feel like this is a
> > > > good enough tradeoff for this use case. The assumption here is
> > > > that the secure session is only needed temporarily for a few
> > > > hours, maybe up to one day
here is
> > > that the secure session is only needed temporarily for a few
> > > hours, maybe up to one day.
> > >
> > > The Coordinator and Signers agree and exchange these 2 secrets
> > > prior to the setup. The NONCE can be converted to either:
> >
can be converted to either:
> (a) a 6-word phrase using BIP39 wordlist
> (b) a 20-digit decimal number
> (c) a QR code
>
> Depending on the vendor. This flexibility in the data format allows
> each vendor to customize the UX based on their respective device
> capabili
В Fri, 12 Feb 2021 18:42:31 +0100
Dmitry Petukhov wrote:
> Maybe for the UX it would be better to choose the number of rounds to
> use in PBKDF2, instead of using variable Pwd. Number of rounds will be
> easier to enter on the device (or just choose it from a set of
> pre-defined values). The
В Thu, 11 Feb 2021 05:45:33 -0800
Hugo Nguyen via bitcoin-dev
wrote:
> > > ENCRYPTION_KEY = SHA256(SHA256(TOKEN))
> >
> > This scheme might be vulnerable to rainbow table attack.
> >
>
> Thank you for pointing this out! Incidentally, Dmitry Petukhov also
> told me the same privately.
My
В Fri, 05 Feb 2021 17:51:27 +
Dr Maxim Orlovsky via bitcoin-dev
wrote:
> Testnet path is unhardened from this point & till the end of the
> derivation path: no need to prevent private key leak there,
> simplifies test software (hardened paths require private key access
> for derivation).
I
site, with more documentation.
I am satisfied with how Alloy spec turned out, though - in my opinion,
the node definitions in the spec are very readable.
[1] https://kframework.org/
> On Wed, Nov 25, 2020 at 5:35 AM Dmitry Petukhov via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.o
I have created a formal specification of Miniscript [1] using
the specification language of Alloy analyzer [2]
Link: https://github.com/dgpv/miniscript-alloy-spec
Possible uses for the spec:
- Implementing Miniscript libraries, as additional reference that might
be easier to navigate than
I have added a Python reference implementation of BIP32 path templates,
that is also compatible with micropython:
https://github.com/dgpv/bip32_template_python_implementation
The FSM formal spec has received a small corrections since the
announcement, and the reference implementations (C and
В Wed, 23 Sep 2020 15:10:22 -0700
Jeremy via bitcoin-dev wrote:
> It's not particularly important that a transaction be in the same
> block once sponsored, it could also be in the last 100 blocks (the
> opposite of proposed change 3).
This will in effect enable "inverse timelock" mechanism for
Just had an idea that an an "inverse timelock" can be made
almost-certainly automatic: a revocation UTXO shall become
anyone-can-spend after a timeout, and bear some non-dust amount.
Before the timelock expiration, it shall be spendable only along with
the covenant-locked 'main' UTXO (via a
В Fri, 3 Jul 2020 21:53:44 +0500
Dmitry Petukhov via bitcoin-dev
wrote:
> My hope is that having a clear specification and (possibly, in the
> future) permissibly licensed quality implementations would make
> adopting such format easier for vendors.
I have added a C implementation (MIT
В Fri, 3 Jul 2020 21:53:44 +0500
Dmitry Petukhov via bitcoin-dev
wrote:
> The format for the path templates described in the presented BIP draft
> aims to provide a building block for interoperability between various
> hardware and software vendors in regard to this partic
nd (possibly, in the
future) permissibly licensed quality implementations would make
adopting such format easier for vendors.
В Fri, 3 Jul 2020 10:39:45 -0400
"David A. Harding" wrote:
> On Thu, Jul 02, 2020 at 09:28:39PM +0500, Dmitry Petukhov via
> bitcoin-dev wrote:
> > I
I think there should be standard format to describe constraints for
BIP32 paths.
I present a BIP draft that specifies "path templates" for BIP32 paths:
https://github.com/dgpv/bip32_template_parse_tplaplus_spec/blob/master/bip-path-templates.mediawiki
Matching against these templates allow to
В Sun, 7 Jun 2020 23:43:39 -0700
Jeremy via bitcoin-dev wrote:
> > PFN transaction would still be valid if some of 'ghost parents' are
> >
> already confirmed, so the miners could have more fees than strictly
> necessary. But this is the same as with CPFP.
>
> This is problematic and can't be
В Sun, 7 Jun 2020 15:45:16 -0700
Jeremy via bitcoin-dev wrote:
> What I think we'll eventually land on is a way of doing a tx
> that contributes fee to another tx chain as a passive observer to
> them. While this breaks one abstraction around how dependencies
> between transactions are
I made a version of the TLA+ spec according to the suggested variant,
as I understood it from your description. This version is in
the separate branch in the SASwap repo, 'variant_ZmnSCPxj' [1]
If I understood and specified your variant correctly, there is a
deadlock possible after step 9, if Bob
I've finished specifying the full Succint Atomic Swap contract in TLA+.
I believe the specification [1] now covers all relevant behaviors of
the participants. It even has an option to enable 'non-rational'
behavior, so that it can be shown that the transactions that are there
to punish bad
В Thu, 14 May 2020 07:31:13 +0200
Ruben Somsen wrote:
> Hi Dmitry,
>
> >While refund_tx_1 is in the mempool, Bob gives success_tx to the
> >friendly miner
>
> I see, so you're talking about prior to protocol completion, right
> after Alice sends Bob the success_tx. The reason this is not an
В Wed, 13 May 2020 21:03:17 +0200
Ruben Somsen wrote:
> Or perhaps you're referring to the issue ZmnSCPxj pointed out after
> that, where refund transaction #1 and the success transaction could
> both become valid at the same time. It would make sense for the test
> to pick up on that, but I
The Succint Atomic Swap contract presented by Ruben Somsen recently has
drawn much interest.
I personally am interested in the smart contracts realizeable in the
UTXO model, and also interested in applying formal methods to the
design and implementation of such contracts.
I think that having
I decided to take this thread back on-list because I beleive that the
'revocation utxo' feature enabled by OP_CTV commiting to scriptSig may
have wider implications that can slightly change the behavior of Bitcoin
as a system, and some might not expect such changes or might not find
them
I am not sure that this particular task should be done with data
embedded in PSBT itself, and not with some sort of container that
includes PSBT and the authentication information.
The benefit seems to be in reusing PSBT structure for compatibilty, and
this might be a valid way, although I do not
В Wed, 7 Aug 2019 20:10:17 +0500
Dmitry Petukhov via bitcoin-dev
wrote:
> In shared ownership rent scheme that ZmnSCPxj described in [1],
> the 'TXO rentier' has a signed timelocked 'backout' transaction that
> spends the locked TXO, and assigns the reward to rentier.
>
> If
В Thu, 08 Aug 2019 09:35:24 +
ZmnSCPxj wrote:
> OP_CHECKSIGVERIFY
> OP_CHECKSIG
This anti-snitch protection won't work if there are two snitches, which
is concievable in the case of a large-scale consolidated bonds (one
entity can pretend to be two independent entities with two different
Unfortunately, both described schemes fail the same way as
'require TXOs to be consolidated by the owner', by the fact that with
muSig, shared ownership of TXO is possible, as explained by ZmnSCPxj in
[1]. 2P-ECDSA is also possible, just more complex, so just saying 'ban
musig for the bonds' is
В Mon, 5 Aug 2019 20:04:26 +0100
Chris Belcher wrote:
> So what's needed is a way to make renting out TXOs impossible or very
> difficult.
You can make renting the TXOs risky for the attacker. Make it so that
the entity that rented out the TXO can revoke the participation of said
TXO in the
В Thu, 01 Aug 2019 19:01:06 +
Andrew Chow wrote:
> I spoke to some people OOB and they said that they didn't really like
> the idea of having a prefix string (partially because they've already
> implemented some proprietary types by simply squatting on unused
> types). Matching the prefix
В Wed, 31 Jul 2019 01:13:46 +
Andrew Chow via bitcoin-dev
wrote:
> Firstly, I would like to propose that some types be reserved for
> proprietary use. These proprietary use types are, in general, for
> private use by individuals and organizations who want to use PSBT in
> their processes.
В Tue, 30 Jul 2019 22:39:14 +0100
Chris Belcher via bitcoin-dev
wrote:
> This is where a sacrifice of V bitcoins creates a
> bond of value V^2. The formula provides a strong incentive for
> profit-motivated makers to use all their fidelity bond coins with just
> one maker, not spread them out
В Fri, 26 Jul 2019 10:10:15 +0200
Tamas Blummer via bitcoin-dev
wrote:
> Imposing opportunity costs however requires larger time locked
> amounts than burning and the user might not have sufficient funds to
> do so. This is however not a restriction but an opportunity that can
> give rise to an
If you make ANYPREVOUTANYSCRIPT signature not the only signature that
controls this UTXO, but use it solely for restricting the spending
conditions such as the set of outputs, and require another signature
that would commit to the whole transaction, you can eliminate
malleability, for the price of
В Sat, 29 Jun 2019 09:19:41 +0900
Jonathan Underwood wrote:
> > Other note: you have 'unused' value of 1 for `m` in your scheme, why
> > not require m=1 for single-sig case, and use 0 as indicator that
> > there are a serlal number following it?
> >
>
> 0x00 is single sig, aka, OP_CHECKSIG
>
В Sat, 29 Jun 2019 09:19:41 +0900
Jonathan Underwood wrote:
> Though outside the scope of this BIP, one difficulty of a whitelist
> feature would be revocation of signatures. If we pre-sign a
> revocation cert and somehow make the wallet blacklist if seen... then
> the question is "if your
In your proposed field key format,
{0x02}|{signing_pubkey}|{m}|{xpub}|...|{xpub}
I think you can replace the signing pubkey with just a fingerprint of
the master key, that would save 29 bytes per 0x02 field.
If the only entity that is concerned about the validity of the
signature is those that
Oh, I saw that you covered it in another mail:
> The expire / revoke problem is a larger problem than this feature can
> handle.
> In general, if one of the cold keys is stolen, there is rarely a
> situation where you are completely sure the other cold keys haven't
> been compromised... so the
> Therefore, the input==output check is sufficient: if I use the same
> set of signers for an input and an output, I can be sure that the
> change goes to the same multisig wallet.
This is sufficient, in a simple case.
I consider cases where spending from different wallets ('wallet
> > Even with this additions to the PSBT format, I think PSBT-signing
> > devices still need to store the xpubs of their co-signers. It's not
> > possible to safely show an incoming address to the user without a
> > full understanding of the other keys in a "multisig wallet". Also,
> > it
> > Do you know any reasonably convenient mechanism for end user to
> > transfer an address from, say, a web page to the wallet address
> > input field ?
>
> - QR code scanning of a Bitcoin URI
> - On Android: A "bitcoin:" URI intent or a BIP70 payment message
> intent
> - On desktop OSes
> Copying addresses to the clipboard should be discouraged, rather than
> supported.
Do you know any reasonably convenient mechanism for end user to
transfer an address from, say, a web page to the wallet address
input field ?
The clipboard is just a low-hanging fruit for malware, anyway. It
44 matches
Mail list logo
