Re: [bitcoin-dev] A Replacement for RBF and CPFP: Non-Destructive TXID Dependencies for Fee Sponsoring

2020-09-24 Thread Dmitry Petukhov via bitcoin-dev
В 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

Re: [bitcoin-dev] BIP OP_CHECKTEMPLATEVERIFY

2020-09-03 Thread Dmitry Petukhov via bitcoin-dev
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

Re: [bitcoin-dev] BIP draft: BIP32 Path Templates

2020-07-06 Thread Dmitry Petukhov via bitcoin-dev
В 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

Re: [bitcoin-dev] BIP draft: BIP32 Path Templates

2020-07-03 Thread Dmitry Petukhov via bitcoin-dev
В 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

Re: [bitcoin-dev] BIP draft: BIP32 Path Templates

2020-07-03 Thread Dmitry Petukhov via bitcoin-dev
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

[bitcoin-dev] BIP draft: BIP32 Path Templates

2020-07-02 Thread Dmitry Petukhov via bitcoin-dev
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

Re: [bitcoin-dev] [was BIP OP_CHECKTEMPLATEVERIFY] Fee Bumping Operation

2020-06-08 Thread Dmitry Petukhov via bitcoin-dev
В 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

Re: [bitcoin-dev] BIP OP_CHECKTEMPLATEVERIFY

2020-06-08 Thread Dmitry Petukhov via bitcoin-dev
В 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

Re: [bitcoin-dev] SAS: Succinct Atomic Swap

2020-06-03 Thread Dmitry Petukhov via bitcoin-dev
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

Re: [bitcoin-dev] TLA+ specification for Succint Atomic Swap

2020-06-01 Thread Dmitry Petukhov via bitcoin-dev
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

Re: [bitcoin-dev] TLA+ specification for Succint Atomic Swap

2020-05-14 Thread Dmitry Petukhov via bitcoin-dev
В 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

Re: [bitcoin-dev] TLA+ specification for Succint Atomic Swap

2020-05-13 Thread Dmitry Petukhov via bitcoin-dev
В 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

[bitcoin-dev] TLA+ specification for Succint Atomic Swap

2020-05-13 Thread Dmitry Petukhov via bitcoin-dev
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

Re: [bitcoin-dev] BIP OP_CHECKTEMPLATEVERIFY

2020-02-14 Thread Dmitry Petukhov via bitcoin-dev
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

Re: [bitcoin-dev] PSBT Addition (BIP 174) for authenticating source/output PSBT files

2020-01-11 Thread Dmitry Petukhov via bitcoin-dev
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

Re: [bitcoin-dev] Improving JoinMarket's resistance to sybil attacks using fidelity bonds

2019-08-08 Thread Dmitry Petukhov via bitcoin-dev
В 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

Re: [bitcoin-dev] Improving JoinMarket's resistance to sybil attacks using fidelity bonds

2019-08-08 Thread Dmitry Petukhov via bitcoin-dev
В 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

Re: [bitcoin-dev] Improving JoinMarket's resistance to sybil attacks using fidelity bonds

2019-08-06 Thread Dmitry Petukhov via bitcoin-dev
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

Re: [bitcoin-dev] Improving JoinMarket's resistance to sybil attacks using fidelity bonds

2019-08-06 Thread Dmitry Petukhov via bitcoin-dev
В 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

Re: [bitcoin-dev] Proposed Extensions to BIP 174 for Future Extensibility

2019-08-02 Thread Dmitry Petukhov via bitcoin-dev
В 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

Re: [bitcoin-dev] Proposed Extensions to BIP 174 for Future Extensibility

2019-07-31 Thread Dmitry Petukhov via bitcoin-dev
В 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.

Re: [bitcoin-dev] Improving JoinMarket's resistance to sybil attacks using fidelity bonds

2019-07-31 Thread Dmitry Petukhov via bitcoin-dev
В 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

Re: [bitcoin-dev] Improving JoinMarket's resistance to sybil attacks using fidelity bonds

2019-07-27 Thread Dmitry Petukhov via bitcoin-dev
В 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

Re: [bitcoin-dev] OP_SECURETHEBAG (supersedes OP_CHECKOUTPUTSVERIFY)

2019-07-09 Thread Dmitry Petukhov via bitcoin-dev
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

Re: [bitcoin-dev] BIP174 extension proposal (Global Type: PSBT_GLOBAL_XPUB_SIGNATURE)

2019-06-29 Thread Dmitry Petukhov via bitcoin-dev
В 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 >

Re: [bitcoin-dev] BIP174 extension proposal (Global Type: PSBT_GLOBAL_XPUB_SIGNATURE)

2019-06-29 Thread Dmitry Petukhov via bitcoin-dev
В 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

Re: [bitcoin-dev] BIP174 extension proposal (Global Type: PSBT_GLOBAL_XPUB_SIGNATURE)

2019-06-28 Thread Dmitry Petukhov via bitcoin-dev
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

Re: [bitcoin-dev] BIP174 extension proposal (Global Type: PSBT_GLOBAL_XPUB_SIGNATURE)

2019-06-27 Thread Dmitry Petukhov via bitcoin-dev
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

Re: [bitcoin-dev] Adding xpub field to PSBT to make multisig more secure

2019-05-09 Thread Dmitry Petukhov via bitcoin-dev
> 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

Re: [bitcoin-dev] Adding xpub field to PSBT to make multisig more secure

2019-05-07 Thread Dmitry Petukhov via bitcoin-dev
> > 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

Re: [bitcoin-dev] BIP Proposal - Address Paste Improvement

2018-11-08 Thread Dmitry Petukhov via bitcoin-dev
> > 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

Re: [bitcoin-dev] BIP Proposal - Address Paste Improvement

2018-11-08 Thread Dmitry Petukhov via bitcoin-dev
> 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