Re: [bitcoin-dev] maximum block height on transaction
You could accomplish your rough goal by having: tx A: desired expiry at H tx B: nlocktime H, use same inputs as A, create outputs equivalent to inputs (have to be sure no relative timelocks) Thus after a timeout the participants in A can cancel the action using TX B. The difference is the coins have to move, without knowing your use case this may or may not help you. On Fri, Apr 9, 2021, 4:40 AM Russell O'Connor via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > From https://bitcointalk.org/index.php?topic=1786.msg22119#msg22119: > > We can't safely do OP_BLOCKNUMBER. In the event of a block chain reorg >> after a segmentation, transactions need to be able to get into the chain in >> a later block. The OP_BLOCKNUMBER transaction and all its dependants would >> become invalid. This wouldn't be fair to later owners of the coins who >> weren't involved in the time limited transaction. >> >> nTimeLock does the reverse. It's an open transaction that can be >> replaced with new versions until the deadline. It can't be recorded until >> it locks. The highest version when the deadline hits gets recorded. It >> could be used, for example, to write an escrow transaction that will >> automatically permanently lock and go through unless it is revoked before >> the deadline. The feature isn't enabled or used yet, but the support is >> there so it could be implemented later. >> > > Unfortunately, limiting the maximum block height for a specific > transaction would have exactly the same problem as cited above for > OP_BLOCKNUMBER. > > On Fri, Apr 9, 2021 at 7:21 AM Erik Aronesty via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> is there any way to specify a maximum block height on a transaction? >> >> ie: this tx is only valid if included in a block with a certain height or >> less >> >> i feel like this would be useful >> ___ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> > ___ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Proposal: Bitcoin Secure Multisig Setup
Thanks for the detailed response. Just 1 thing I needed to clarify: > To the list of concerns at the top of the BIP, I would add one: losing > multisig setup context. E.g. in the event of a fire where you only recover > your steel engraved mnemonic(s), but no longer have the wallet descriptors. > > Good point. > > > If you still have all devices and know (or guess) the threshold then BIP48 > and sorted_multi descriptors will save you. But if you have a 2-of-3 setup > and lost 1 device then without the metadata your coins are lost. In a future > with musig(?) and miniscript increasingly the setup data is just as critical > as the seeds. > > How so? Each signer device should ideally have a copy of the multisig > configuration. If you lose 1 device in a 2-of-3, you can still spend from the > wallet? Unless I'm missing something here. I was thinking about a scenario where all devices are destroyed. All you have left are the mnemonics. But indeed if at least one of your devices is still intact AND it has the configuration, you're also good. But there are plenty of devices out there that can't do this. Those devices can still be useful, even if they can't fully check everything. Sjors signature.asc Description: Message signed with OpenPGP ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Proposal: Bitcoin Secure Multisig Setup
(Continue off last email: also keep in mind, that just like BIP174, Coordinator and Signer are abstract roles. This means in theory a Signer can be the Coordinator too. The same criteria for trust applies equally to a Signer and a Coordinator.) The use case I personally find most interesting is not a multi-party setup, > but rather just combining a bunch of my own devices. Those might even be in > the same room during the setup, only to be moved to my moon base later. > And that's fair. Both use cases (local and remote multisig) are valid and currently being used. But IMO a standard should accommodate both. > To the list of concerns at the top of the BIP, I would add one: losing > multisig setup context. E.g. in the event of a fire where you only recover > your steel engraved mnemonic(s), but no longer have the wallet descriptors. > Good point. > > If you still have all devices and know (or guess) the threshold then BIP48 > and sorted_multi descriptors will save you. But if you have a 2-of-3 setup > and lost 1 device then without the metadata your coins are lost. In a > future with musig(?) and miniscript increasingly the setup data is just as > critical as the seeds. > How so? Each signer device should ideally have a copy of the multisig configuration. If you lose 1 device in a 2-of-3, you can still spend from the wallet? Unless I'm missing something here. > A future standard (or extension of this one) should recommend an > encryption convention for the descriptor data, ideally such that with *any* > of the seeds you can decrypt a file that contains the full setup. That file > could then just float redundantly around the internet and pieces of paper > in various locations, without compromising privacy. > Post-wallet-creation, each Signer can apply extra encryption on top of BSMS for the persistence of the configuration file any way it wants :) It doesn't contradict with the current spec. > The proposed encryption system doesn't help with that though, because it's > based on entropy from the Coordinator, rather than from the signers. > They are for different purposes. The TOKEN-based encryption is only needed temporarily for the setup. > Smaller suggestions: > * link to this new mail thread in the BIP > Will do. > * use magic bytes so .bsms so operating systems like Android / iOs can > open the right app for them > * don't use separate file extensions for encrypted vs unencrypted content, > just indicate somehow that a given field is encrypted > * although plain text files are handy for debugging, I think a binary > format like PSBT is much powerful. Any device that can parse and write > binary PSBT should be able to implement a similar parser / writer for a > binary .bsms format. > Will consider these points, but I prefer plaintext for wallet configuration. Human readability for the wallet configuration is a pro not a con IMO. Also helps when backing up. > * BIP48 and sorted_multi descriptors are useful in a loss-of-metadata > scenario. The BIP uses both in the examples, but doesn't explictly endorse > these derivations. It also contradicts them: "If the Signer chooses the > path, it should try to avoid reusing XPUBs for different wallets.". Maybe > this is out of scope. >* one way to resolve xpub reuse would be to make the "BIP48" path a > function of the co-signer fingerprints and wallet threshold, but this > requires an extra communication round > We discussed this in the linked PR ( https://github.com/nunchuk-io/bips/pull/1), and decided that enforcing against path reuse is out-of-scope. We give examples of sorted_multi and multi because different vendors support different things. > * there should be a way for signers to communicate their capabilities, > perhaps with a different xpub for each potential scheme. E.g. there's m/48' > native SegWit now, MuSig and/or or Tapleaf based multisig in the future, or > even generic Miniscript support. > I considered Signers signaling capabilities (for a different reason), but opted against it because it further complicates the scheme. Also BIP48-like proposals are made redundant with the use of output descriptors. > * the idea of only storing the receive descriptor, not the change > descriptor, is fine by me, though I'd prefer an extension to the descriptor > format to deal with this > That's not quite accurate. The spec stores the top-level descriptor (XPUB/*) along with the path restrictions (/0/*,/1/*), not the receive descriptor. The path restrictions would allow you to extend on the spec. There's also a VERSION field. Best, Hugo > > Sjors > > > Op 5 apr. 2021, om 09:02 heeft Hugo Nguyen via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> het volgende geschreven: > > > > Hi all, > > > > Please find below the complete draft of the Bitcoin Secure Multisig > Setup (BSMS) BIP. The spec has gone through a number of important updates > in the last month or so. Thanks everyone who has participated in the review >
Re: [bitcoin-dev] Proposal: Bitcoin Secure Multisig Setup
Hi Sjors Thanks for the feedback! The first step is for the Coordinator to generate a TOKEN, presumably using > its own entropy. But IIUC anyone who intercepts that token can decrypt any > future step in the setup process. This suggests a chicken-egg problem where > you need some pre-existing secure communications channel. > The exchange of the TOKEN is frequently mistaken as the chicken-and-egg problem, but it is not so. To understand why this isn't chicken-and-egg, and why the TOKEN actually adds value, consider *the scale of the communication operation needed to exchange the TOKEN*, and *the scale of the communication operation needed to gather data for the creation of the multisig wallet *(with or without the TOKEN): 1) The TOKEN itself is a single piece of data that is 64- or 96-bit. It is small enough to be easily exchanged (even memorized) and entered into various devices. It requires only a single round of communication, but can protect as many rounds of communication as needed. 2) The data needed to create the multisig wallet, on the other hand, are quite involving: (a) Each Signer needs to share its XPUB, which cannot be memorized (b) The XPUBs also come with their own metadata (c) The creation of the wallet requires at least two rounds of communications since the Signers need to voluntarily share their XPUBs first, only then can a Coordinator combine the XPUBs into a single multisig script and pass back the configuration to the Signers. (Note that without a Coordinator, you'll need O(N^2) rounds of communication). (d) Because Signers are typically off-line cold storage, the paths between the Signers / the Signers <> Coordinator likely involve multiple hops through various media, such as unsecure USB connection. This is the way most multisig solutions are currently being implemented. It means the XPUBs and the multisig configuration are vulnerable to leaking and/or modifications. Note that (d) is especially problematic for remote multisig setups. The more remote, the more potential hops along the way, the more problematic. So you can see that *the TOKEN ultimately reduces the problem of sharing a large amount of sensitive data back and forth, to the sharing of a single, small piece of data upfront.* An added advantage of this approach is that if the parties fail to establish a shared TOKEN, the scheme fails with no harm done. The Coordinator, on the other hand, adds value by solving the O(n^2) communication problem. Some minimal amount of trust is needed for the Coordinator, but this can be greatly mitigated by a number of ways that we have defined in the spec, such as: * Signers must check that their XPUBs are included in the final descriptor * Signers must display to the user the multisig configuration: M/N, relative position(s) of XPUBs, etc. * Signers must display the full descriptor upon user request for manual inspection - this one is important because it means that the new scheme cannot be worse than the status quo. * Signers are recommended to display a preview of the first receive address(es). All in all, the Coordinator's role helps ease the setup process, while its ability to pull off any shenanigans is greatly limited. Best, Hugo ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Proposal: Bitcoin Secure Multisig Setup
Hi all, First of all thanks for your continued work on standardising multisig setup. The use case I personally find most interesting is not a multi-party setup, but rather just combining a bunch of my own devices. Those might even be in the same room during the setup, only to be moved to my moon base later. This means I've paid less attention to the encryption scheme, so I might set TOKEN=0, but nevertheless I am skeptical about it. The first step is for the Coordinator to generate a TOKEN, presumably using its own entropy. But IIUC anyone who intercepts that token can decrypt any future step in the setup process. This suggests a chicken-egg problem where you need some pre-existing secure communications channel. To the list of concerns at the top of the BIP, I would add one: losing multisig setup context. E.g. in the event of a fire where you only recover your steel engraved mnemonic(s), but no longer have the wallet descriptors. If you still have all devices and know (or guess) the threshold then BIP48 and sorted_multi descriptors will save you. But if you have a 2-of-3 setup and lost 1 device then without the metadata your coins are lost. In a future with musig(?) and miniscript increasingly the setup data is just as critical as the seeds. A future standard (or extension of this one) should recommend an encryption convention for the descriptor data, ideally such that with *any* of the seeds you can decrypt a file that contains the full setup. That file could then just float redundantly around the internet and pieces of paper in various locations, without compromising privacy. The proposed encryption system doesn't help with that though, because it's based on entropy from the Coordinator, rather than from the signers. Smaller suggestions: * link to this new mail thread in the BIP * use magic bytes so .bsms so operating systems like Android / iOs can open the right app for them * don't use separate file extensions for encrypted vs unencrypted content, just indicate somehow that a given field is encrypted * although plain text files are handy for debugging, I think a binary format like PSBT is much powerful. Any device that can parse and write binary PSBT should be able to implement a similar parser / writer for a binary .bsms format. * BIP48 and sorted_multi descriptors are useful in a loss-of-metadata scenario. The BIP uses both in the examples, but doesn't explictly endorse these derivations. It also contradicts them: "If the Signer chooses the path, it should try to avoid reusing XPUBs for different wallets.". Maybe this is out of scope. * one way to resolve xpub reuse would be to make the "BIP48" path a function of the co-signer fingerprints and wallet threshold, but this requires an extra communication round * there should be a way for signers to communicate their capabilities, perhaps with a different xpub for each potential scheme. E.g. there's m/48' native SegWit now, MuSig and/or or Tapleaf based multisig in the future, or even generic Miniscript support. * the idea of only storing the receive descriptor, not the change descriptor, is fine by me, though I'd prefer an extension to the descriptor format to deal with this Sjors > Op 5 apr. 2021, om 09:02 heeft Hugo Nguyen via bitcoin-dev > het volgende geschreven: > > Hi all, > > Please find below the complete draft of the Bitcoin Secure Multisig Setup > (BSMS) BIP. The spec has gone through a number of important updates in the > last month or so. Thanks everyone who has participated in the review process. > > As a PR: https://github.com/bitcoin/bips/pull/1097 signature.asc Description: Message signed with OpenPGP ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] maximum block height on transaction
>From https://bitcointalk.org/index.php?topic=1786.msg22119#msg22119: We can't safely do OP_BLOCKNUMBER. In the event of a block chain reorg > after a segmentation, transactions need to be able to get into the chain in > a later block. The OP_BLOCKNUMBER transaction and all its dependants would > become invalid. This wouldn't be fair to later owners of the coins who > weren't involved in the time limited transaction. > > nTimeLock does the reverse. It's an open transaction that can be replaced > with new versions until the deadline. It can't be recorded until it > locks. The highest version when the deadline hits gets recorded. It could > be used, for example, to write an escrow transaction that will > automatically permanently lock and go through unless it is revoked before > the deadline. The feature isn't enabled or used yet, but the support is > there so it could be implemented later. > Unfortunately, limiting the maximum block height for a specific transaction would have exactly the same problem as cited above for OP_BLOCKNUMBER. On Fri, Apr 9, 2021 at 7:21 AM Erik Aronesty via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > is there any way to specify a maximum block height on a transaction? > > ie: this tx is only valid if included in a block with a certain height or > less > > i feel like this would be useful > ___ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Update on "Speedy" Trial: The circus rolls on
I have no problem with coin tosses to decide for example shed colors (an illustrative example discussed by copumpkin, roasbeef on IRC). In this kind of example everyone should recognize it doesn't matter and Approach ACK two competing PRs. No one should be NACKing or Approach NACKing a PR based on shed color. If the maintainers don't care about the shed color either then they are free to use a coin toss to decide which PR to merge. In this example there shouldn't be any NACKs, Approach NACKs or technical opposition from regular Core reviewers. NACKs are not meant to be used for shed colors. However, in this example the organizer of the coin toss had previously NACKed one of the options (block height, though his position seems to change by the day) and others have NACKed MTP. I think you have consistently said it doesn't matter too much although you did previously express a preference for block height. I don't want to belabor the point but can we avoid even suggesting using coin tosses on consensus code decisions in future please? It makes a mockery of those who spent time understanding the technical considerations and have spent months or years working on soft fork activations. Even in the shed color example, leave it to the maintainers to decide whether a coin toss is appropriate rather than creating a circus around a coin toss in a public meeting where the PR authors weren't present and no Core maintainers were present. I understand the frustration and I understand the desire to break deadlocks. But if the coin toss organizer hadn't previously NACKed one of the options (block height) we may have avoided getting into this deadlock in the first place. Your recent review notes of PR #21377 look great and are proving very helpful to me as I look at the PR. https://gist.github.com/harding/e622323eaf80d620826a7cb74ab3fb40 Thanks Michael On Thu, Apr 8, 2021 at 10:57 PM David A. Harding wrote: > > On Thu, Apr 08, 2021 at 12:40:42PM +0100, Michael Folkson via bitcoin-dev > wrote: > > So the latest circus act is apparently a technical decision made by a > > coin toss [organized by] Jeremy Rubin > > Actually, the coin toss was my idea[1], used a bash oneliner I wrote[2], > and is the same method I've been using in Bitcoin-related discussions > for over seven years[3] to help people transition from ancillary arguments > back to working on the things they really think are important. > > I proposed the coin toss because I understood that both the MTP and the > height approaches required tradeoffs that were, to a certain degree, > unresolvable to the best of our current knowledge. MTP is harder to > analyze for unexpected edge cases; heights would create extra work for > seasoned developers working on post-taproot soft forks. MTP would > require developers of currently-planned UASF software either do extra > work or wait to release their software; heights don't guarantee a > minimum amount of time for a large number of economic full nodes to > upgrade. > > Different people gave different weights to the different tradeoffs. In > cases like this where there's no known way to eliminate the tradeoffs > and no way to objectively rank them, I think it's better to begin > working on something concrete than it is to try to persuade everyone to > adopt the same subjective ranking of the tradeoffs---or, as the IETF > published in RFC7282: > > "There are times where the result of [an informal open-ended > conversation] is a pretty even split. In practical terms, that > means it doesn't matter where the chair starts the discussion. And > in fact, we've had working groups where a coin flip decided which > proposal to start with. That doesn't mean that the coin flip > determined the outcome; if a fatal technical flaw was found in the > solution that won the coin flip, it is still incumbent upon the > group to address the issue raised or abandon that solution and find > another. Rough consensus on the technical points, in the end, is > always required. Any way to find a place to start, be it the hum or > the coin flip, is only getting to the beginning of the discussion, > not the end." > > As Jeremy wrote, in this occassion, we didn't actually need the coin > toss. The authors of the two PRs we were considering found a compromise > solution that seems to be good enough for both of them and which so far > seems to be good enough for the handful of people who agreed to the coin > toss (plus, it seems, several others who didn't agree to the toss). > > In short, I think the coin toss was a good attempt. Although we didn't > use its results this time, I think it's something we should keep in our > toolkit for the future when a group of people want to coordinate their > work on getting *a* solution released, even in cases where they don't > necessarily start out in agreement about which solution is best. > > > I dread to think what individuals and businesses all over the
[bitcoin-dev] An Electrum server using libbitcoin
Hi. I've been working on an Electrum server implementation that uses zmq and libbitcoin as its backend. I wanted to use the Electrum wallet with my libbitcoin server and this makes it possible now with (unfinished) libbitcoin v4. The code is here: https://github.com/parazyd/obelisk (Yes, it's named Obelisk because of historical reasons :p) As the Electrum/ElectrumX protocol is getting some new stuff in protocol version 1.5, I will keep tracking the protocol and implement it in Obelisk as it comes. Eventually, the end-goal is to merge Obelisk into Electrum and simply use libbitcoin public (or self-hosted) servers directly, without the need of a boilerplate protocol/server between a client and a daemon. In current Electrum git, this seems relatively simple to do (and I personally already have done about 70% of it on my local code repository), but the problem is that it's a breaking change and replaces the old protocol, which invalidates all old servers if/when this change happens. However, I don't doubt that removing the boilerplate and querying a libbitcoin server directly is a bad idea at all. I'll see if I can make upstream progress on this once I get feedback. In general, regarding Obelisk I'd appreciate some feedback, review, and a bit of help with certain TODOs in the code. The entire codebase is around 1000 lines of Python 3 with no external dependecies besides pyzmq. Thanks, Ivan ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] maximum block height on transaction
is there any way to specify a maximum block height on a transaction? ie: this tx is only valid if included in a block with a certain height or less i feel like this would be useful ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
