Re: [bitcoin-dev] Private Collaborative Custody with FROST
Good morning Nick, Love the direction of this. > We can achieve this compatibility by having the server sign under a single > nonce (not a binding nonce-pair like usual FROST), which is later blinded by > the nonce contributions from other signers. Can you say more about this? It sounds like the blinding is happening post-signing? Or is it happening during the normal nonce commitment trading? Rijndael On Mon, Aug 28, 2023 at 3:35 PM, Nick Farrow via bitcoin-dev <[bitcoin-dev@lists.linuxfoundation.org](mailto:On Mon, Aug 28, 2023 at 3:35 PM, Nick Farrow via bitcoin-dev < wrote: > Hello all, > > Some thoughts on private collaborative custody services for Bitcoin. > > With multiparty computation multisignatures like FROST [0], it is possible to > build a collaborative custodian service that is extremely private for users. > > Today's collaborative custodians can see your entire wallet history even if > you never require them to help sign a transaction, and they have full liberty > to censor any signature requests they deem inappropriate or are coerced into > censoring. > > With FROST, a private collaborative custodian can hold a key to a multisig > while remaining unaware of the public key (and wallet) which they help > control. By hiding this public key, we solve the issue of existing > collaborative custodians who learn of all wallet transactions even if you > never use them. > > Further, in the scenario that we do call upon a private collaborative > custodian to help sign a transaction, this transaction could be signed > **blindly**. Being blind to the transaction request itself and unknowing of > past onchain behavior, these custodians have no practical information to > enact censorship requests or non-cooperation. A stark contrast to today's > non-private collaborative custodians who could very easily be coerced into > not collaborating with users. > > Enrolling a Private Collaborative Custodian > > Each signer in a FROST multisig controls a point belonging to a joint > polynomial at some participant index. > > Participants in an existing multisig can collaborate in an enrollment > protocol (Section 4.1.3 of [1], [2]) to securely generate a new point on this > shared polynomial and verifiably communicate it to a new participant, in this > case a collaborative custodian. > > The newly enrolled custodian should end by sharing their own *public* point > so that all other parties can verify it does in-fact lie on the image of the > joint polynomial at their index (i.e. belong to the FROST key). (The > custodian themselves is unable to verify this, since we want to hide our > public key we do not share the image of our joint polynomial with them). > > Blind Collaborative Signing > > Once the collaborative custodian controls a point belonging to this FROST > key, we can now get their help to sign messages. > > We believe it to be possible for a signing server to follow a scheme similar > to that of regular blind Schnorr signatures, while making the produced > signature compatible with the partial signatures from other FROST > participants. > > We can achieve this compatibility by having the server sign under a single > nonce (not a binding nonce-pair like usual FROST), which is later blinded by > the nonce contributions from other signers. The challenge also can be blinded > with a factor that includes the necessary Lagrange coefficient so that this > partial signature correctly combines with the other FROST signatures from the > signing quorum. > > As an overview, we give a 3rd party a secret share belonging to our FROST > key. When we need their help to sign something, we ask them to send us (FROST > coordinator) a public nonce, then we create a challenge for them to sign with > a blind Schnorr scheme. They sign this challenge, send it back, and we then > combine it with the other partial signatures from FROST to form a complete > Schnorr signature that is valid under the multisignature's public key. > > During this process the collaborative custodian has been unknowing of our > public key, and unknowing as to the contents of the challenge which we have > requested them to sign. The collaborative signer doesn't even need to know > that they are participating in FROST whatsoever. > > Unknowing Signing Isn't So Scary > > A server that signs arbitrary challenges sounds scary, but each secret share > is unique to a particular FROST key. The collaborative custodian should > protect this service well with some policy, e.g. user authentication, perhaps > involving cooperation from a number of other parties (< threshold) within the > multisig. This could help prevent parties from abusing the service to "get > another vote" towards the multisig threshold. > > Unknowingly collaborating in the signing of bitcoin transactions could be a > legal gray area, but it also places you in a realm of extreme privacy that > may alleviate you from regulatory and legal
Re: [bitcoin-dev] Concern about "Inscriptions"
Good morning Russel and List, That is correct. There is a counterparty-compatible project called STAMPS that breaks up image data into chunks and then embeds the chunks in bare multisig outputs. here is an example on one: https://mempool.space/tx/ee9ed76fa2318deb63a24082a8edc73e4ea39a5252bfb1c1e1c02bd02c52f95f This consumes more space and bloats the UTXO set compared to stuffing data in a witness. There are schemes like Pay-to-Contact ([https://bitcoinops.org/en/topics/pay-to-contract-outputs/](https://bitcoinops.org/en/topics/pay-to-contract-outputs/#:~:text=Pay%2Dto%2Dcontract%20protocols%20allow,that%20commits%20to%20that%20text)) that could be used to tweak a pubkey with a small blob of data, in which case someone could produce a signature proving knowledge of the private key. --- Original Message --- On Monday, August 21st, 2023 at 10:47 AM, Russell O'Connor via bitcoin-dev wrote: > It's been said before, but I'll say it again: > > If we ban "arbitrary data", however you want to define it, then actors will > simply respond by encoding their data within sets of public keys. Public key > data is indistinguishable from random data, and, unless we are willing to pad > the blockchain with proof of knowledge of secret keys, there will be no way > to tell a priori whether a given public key is really a public key or whether > it is encoding an inscription or some other data. > > When certain governments try to censor certain internet protocols, users > respond by tunnelling their protocol through something that appears to be > innocent HTTPS (see Tor bridge nodes). This works because, after a handshake, > the remaining HTTPS stream, like public keys, is indistinguishable from > random data, and can be used as a communications channel for arbitrary data. > If we attempt to ban "arbitrary data", those users will simply respond by > "tunneling" their data over innocent-looking public key data instead. > > Please correct me if I'm wrong, but I believe Counterparty has, in the past, > encoded their data within public key data, so this concern is not > hypothetical. > > On Sat, Aug 19, 2023 at 10:29 AM Chris Martl via bitcoin-dev > wrote: > >> It is already more than a half year since the probably mayor Bitcoin script >> exploit started. >> >> These exploits are nothing new in the Bitcoin history and mostly are due to >> the loose flexibility of the system in regards of processing predicatives >> (Bitcoin script). The very first mayor bug; if you wish, vulnerability, was >> the CVE-2010-5141, which still engages us without end even after 14 years. >> >> Subsequent Bitcoin historical events let to build more “improvements” upon >> this wobbly basis exposing even more ground for exploits. >> >> As long as this loose flexibility is not modified in a way its exposure for >> exploits is eliminated remains nothing else than to pursue other strategies; >> and ones which are compatible with the current status quo and furthermore, >> with a permission-less system. >> >> Here a strategy proposal: >> >> Let’s name it: #Ordisrespector and #Ordislow. >> >> Why #Ordisrespector and #Ordislow are compatible with a permission-less >> system. >> >> #Ordisrespector gives the option to a regular Bitcoin node operator to >> opt-in or not to a self-defense of his/her storage property (and thus of >> his/her integrity); by giving a signal of dissatisfaction with the current >> affairs of aggression via insertion of arbitrary data into the witness >> structure. This dissatisfaction signal is manifested by not taking into the >> mempool and relaying transactions with inserted arbitrary data in the >> witness structure. >> >> #Ordislow gives the option to a regular Bitcoin node operator to opt-in or >> not to a self-defense of his/her storage property (and thus of his/her >> integrity); by increasing the coercion cost of mining-entities relative to >> the cooperation cost of mining-entities due to the current affairs of >> aggression via insertion of arbitrary data into the witness structure. This >> coercion cost increment is manifested by not propagating a found block, >> unless a configurable or maximum delay has elapsed, which contains at least >> a transaction with inserted arbitrary data in the witness structure. >> >> Chris___ >> 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] Concern about "Inscriptions".
Hello, > This cat and mouse game can be won by bitcoin defenders. Why ? Because it is > easier to detect these transactions and make them a standardization rule than > to create new types of spam transactions. One of the things discussed during the mempoolfullrbf discussion is that a small (~10%) of nodes willing to relay a class of transaction is enough for that class of transaction to consistently reach miners. That means you would need to get nearly the entire network to run updated relay policy to prevent inscriptions from trivially reaching miners and being included in blocks. Inscription users have shown that they are willing and able to send non-standard transactions to miners out of band (https://mempool.space/tx/0301e0480b374b32851a9462db29dc19fe830a7f7d7a88b81612b9d42099c0ae), so even if you managed to get enough of the network running the new rule to prevent propagation to miners, those users can just go out of band. Or, they can simply change the script that is used to embed an inscription in the transaction witness. For example, instead of 0 OP_IF…, maybe they do 0 OP_DUP OP_DROP OP_IF. When the anti-inscription people detect this, they have to update the rule and wait for 90%+ of the network to upgrade. When the pro-inscription people see this, they only have to convince other inscription enthusiasts and businesses to update. The anti-inscription patch has to be run by many more participants (most of whom don’t care), while the pro-inscription update has to be run by a small number of people who care a lot. It’s a losing battle for the anti-inscription people. If you want to prevent inscriptions, the best answer we know of today is economic: the cost of the blockspace needs to be more expensive than inscribers are willing to pay, either because its too expensive or because there’s no market demand for inscriptions. The former relies on Bitcoin becoming more useful to more people, the latter is the natural course of collectibles. > Finally, I would like to quote satoshi himself who wrote about spam here is > the link: https://bitcointalk.org/index.php?topic=195.msg1617#msg1617 Appeals to Satoshi are not compelling arguments. Cheers, Rijndael On Sun, Jul 30, 2023 at 2:04 PM, Léo Haf via bitcoin-dev <[bitcoin-dev@lists.linuxfoundation.org](mailto:On Sun, Jul 30, 2023 at 2:04 PM, Léo Haf via bitcoin-dev < wrote: > According to you, the rules of standardization are useless but in this case > why were they introduced? The opreturn limit can be circumvented by miners, > yet it is rare to see any, the same for maxancestorcount, minrelayfee or even > the dust limit. > > This cat and mouse game can be won by bitcoin defenders. Why ? Because it is > easier to detect these transactions and make them a standardization rule than > to create new types of spam transactions. > > As for the default policy, it can be a weakness but also a strength because > if the patch is integrated into Bitcoin Core by being activated by default, > the patch will become more and more effective as the nodes update. > > Also, when it came to using a pre-segwit node, it is not a solution because > this type of node cannot initiate new ones, which is obviously a big problem. > > Finally, I would like to quote satoshi himself who wrote about spam here is > the link: https://bitcointalk.org/index.php?topic=195.msg1617#msg1617 > >> Le 27 juil. 2023 à 07:10, vju...@gazeta.pl a écrit : > >> > >> > >>> not taking action against these inscription could be interpreted by >>> spammers as tacit acceptance of their practice. > >> > >> Note that some people, even on this mailing list, do not consider Ordinals >> as spam: >> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-February/021464.html > >> > >> See? It was discussed when it started. Some people believe that blocking >> Ordinals is censorship, and could lead to blocking regular transactions in >> the future, just based on other criteria. That means, even if developers >> would create some official version with that option, then some people would >> not follow them, or even block Ordinals-filtering nodes, exactly as >> described in the linked thread: >> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-February/021487.html > >> > >>> as spammers might perceive that the Bitcoin network tolerates this kind of >>> behavior > >> > >> But it is true, you have the whole pages, where you can find images, files, >> or other data, that was pushed on-chain long before Ordinals. The whole >> whitepaper was uploaded just on 1-of-3 multisig outputs, see transaction >> 54e48e5f5c656b26c3bca14a8c95aa583d07ebe84dde3b7dd4a78f4e4186e713. You have >> the whole altcoins that are connected to Bitcoin by using part of the >> Bitcoin's UTXO set as their database. > >> > >> That means, as long as you won't solve IBD problem and UTXO set growing >> problem, you will go nowhere, because if you block Ordinals specifically,
Re: [bitcoin-dev] Ordinal Inscription Size Limits
Hello, “Unlimited storage” isn’t really accurate. It’s witness data in a taproot transaction, so the block size limit still applies. Anyone who runs an unpruned bitcoin node should be capacity-planning their disk space assuming that in the future blocks will be more full - as demand for blockspace increases, people will make better use of the space that we already have and average block weight will trend upwards. If you’re thinking about how much disk you will need when we have consistently full blocks, ordinal inscriptions don’t change that number. - rijndael On Fri, Jan 27, 2023 at 7:44 AM, Robert Dickinson via bitcoin-dev wrote: > I'm curious what opinions exist and what actions might be taken by core > developers regarding storing unlimited amounts of NFT (or other?) content as > witness data (https://docs.ordinals.com/inscriptions.html). The ordinal > scheme is elegant and genius IMHO, but when I think about the future disk use > of all unpruned nodes, I question whether unlimited storage is wise to allow > for such use cases. Wouldn't it be better to find a way to impose a size > limit similar to OP_RETURN for such inscriptions? > > I think it would be useful to link a sat to a deed or other legal construct > for proof of ownership in the real world, so that real property can be > transferred on the blockchain using ordinals, but storing the property itself > on the blockchain seems nonsensical to me.___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] OP_VAULT: a new vault proposal
Hey James, Really cool proposal. I’ve been thinking a lot lately about script paths for inheritance. In a lot of the “have a relative time lock that allows a different key to spend coins, or allows a smaller threshold of a multisig to spend” schemes, you have the problem of needing to “refresh” all of your coins when the timelock is close to maturation. In a lot of the “use multisig with ephemeral keys to emulate covenants” schemes, you have to pre-commit to the terminal destination well in advance of the spend-path being used, which leads to all kinds of thorny questions about security and availability of *those* keys. In other words, you either have to have unbound destinations but a timer that needs resetting, or you have unbound time but fixed destinations. This design gets you the best of both because the destination SPKs aren’t committed to until the unvaulting process starts. This (or something like this with destination binding at unvault-time) would be an incredibly useful tool for inheritance designs in wallets. I need to think a bit more about the recovery path not having any real encumbrances on it. Maybe in practice if you’re worried about DoS, you have UTXOs that commit to multiple vault paths that have tweaked recovery destinations or something, or maybe it really is the right move to say that if recovery is triggered, you probably do want it for all of your inflight unvaultings. Looking forward to reading this a few more times and talking more about it. Thanks! rijndael On Mon, Jan 9, 2023 at 11:07 AM, James O'Beirne via bitcoin-dev wrote: > For the last few years, I've been interested in vaults as a way to > substantially derisk custodying Bitcoin, both at personal and commercial > scales. Instead of abating with familiarity, as enthusiasm sometimes > does, my conviction that vaults are an almost necessary part of bitcoin's > viability has only grown over the years. > > Since people first started discussing vaults, it's been pretty clear that > some kind of covenant-enabling consensus functionality is necessary to > provide the feature set necessary to make vault use practical. > > Earlier last year I experimented with using OP_CTV[1], a limited covenant > mechanism, to implement a "minimum-viable" vault design. I found that the > inherent limitations of a precomputed covenant scheme left the resulting > vault implementation wanting, even though it was an improvement over > existing strategies that rely on presigned transactions and (hopefully) > ephemeral keys. > > But I also found proposed "general" covenant schemes to be > unsuitable for this use. The bloated scriptPubKeys, both in size and > complexity, that would result when implementing something like a vault > weren't encouraging. Also importantly, the social-consensus quagmire > regarding which covenant proposal to actually deploy feels at times > intractable. > > As a result, I wanted to explore a middle way: a design solely concerned > with making the best vault use possible, with covenant functionality as a > secondary consideration. In other words, a proposal that would deliver > the safety benefits of vaults to users without getting hung up on > trying to solve the general problem of covenants. > > At first this design, OP_VAULT, was just sort of a pipe dream. But as I > did more thinking (and eventually implementing) I became more convinced > that, even if it isn't considered for soft-fork, it is a worthwhile > device to serve as a standard benchmark against which other proposals > might be judged. > > I wrote a paper that summarizes my findings and the resulting proposal: > https://jameso.be/vaults.pdf > > along with an accompanying draft implementation: > https://github.com/bitcoin/bitcoin/pull/26857 > > I might work on a BIP if there's interest. > > James > [1]: https://github.com/jamesob/simple-ctv-vault___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Trustless Address Server – Outsourcing handing out addresses to prevent address reuse
Hello Andrew and Bryan, > No, as I understand the proposal, the "public key" held by the wallet is > simply > a signing key used to authenticate addresses, and never leaves the wallet. That's right (or at least, that's the intent). Think of importing someone's GPG key and then using it to validate future signed messages from them. In this case, the public key stays in your "address book" entry for a person and then whenever you need to fetch a fresh address for them from the Address Server, your wallet can validate that it's for their wallet. Making sure that you import a legitimate/authentic public key is a problem, but you only need to do it once per recipient, instead of doing it every time you need to transact with that person. Maybe that's something you solve in UI (i.e. Signal has you compare strings with your counter-party), or something you can solve through other metadata (GPG had WoT, or if you're already using an address server maybe there's some PKI scheme that's appropriate, etc.). Rubin, I think you responded on another branch of the thread, but thanks for the podcast link. I'll check it out! Cheers, Rijndael --- Original Message --- On Tuesday, October 18th, 2022 at 8:42 AM, Andrew Poelstra wrote: > On Mon, Oct 17, 2022 at 07:07:07PM -0500, Bryan Bishop via bitcoin-dev wrote: > > > Isn't this the same problem but now for copy-pasting pubkeys instead of an > > address? > > > No, as I understand the proposal, the "public key" held by the wallet is > simply > a signing key used to authenticate addresses, and never leaves the wallet. > Yes, > if the wallet's own memory is compromised, it can be tricked into accepting > bad > addresses, but this is much much harder than compromising data on the > clipboard, > which basically any application can do without any "real" exploits or special > permissions. > > As an extreme, this proposal could be run on a hardware wallet which had some > out-of-band way to obtain and authenticate public keys (similar to Signal QR > codes). > > -- > Andrew Poelstra > Director of Research, Blockstream > Email: apoelstra at wpsoftware.net > Web: https://www.wpsoftware.net/andrew > > The sun is always shining in space > -Justin Lewis-Webster ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Trustless Address Server – Outsourcing handing out addresses to prevent address reuse
Hi all, I'm working on a light wallet and have been kicking around a really similar idea (we already have a hosted component that knows the user's xpub, why not provide an endpoint that can vend fresh receive addresses to senders and try to make the easy-path for sending bitcoin to our users also be the more private one). I wanted to throw in another thing you can build with this setup: address authentication. Bitcoin addresses don't (generally) carry any semantic information that humans can use at-a-glance to distinguish legitimate addresses from illegitimate addresses. There have been instances of clipboard-hijacking malware that have used this fact to steal bitcoin -- a user goes to a webpage (or email, or IM or whatever), copies an address, and then pastes it into their bitcoin wallet. Unbeknownst to them, the clipboard contents have been replaced with an address controlled by some bad actor. The wallet just builds the transaction to whatever addresses the "user" supplied, and the user is none-the-wiser until after the funds have left their wallet. Now imagine instead that the wallet has some address book with a pubkey for each recipient the user wants to send bitcoin to. Alice wants to pay Bob, so she clicks "Bob" in her transaction UI. Her wallet goes and asks the address server for an address for Bob. The address server picks an unused address, and has it signed (depending on the setup, this could be that the address server also has the Address Authentication privkey for bob, or it could be that bob gets some callback or notification, or that bob has pre-signed a batch of addresses. it will depend on the implementation). The address server sends a signed blob back to alice that contains an address and a signature proving that the address is in fact Bob's. Now Alice's wallet can tell whether or not the address it's putting in the transaction output belongs to Bob, even if that data was intercepted between the address server and the wallet (this doesn't help if the address server is malicious or has been compromised, but that's a different problem). It would be really nice to have a protocol here that can make wallets interoperable in fetching fresh addresses from Address Servers and in the return schema that can include signatures and other metadata (like optimistic expirations, maybe other invoice data?). Love the conversation so far. Happy to dig into this further with anyone else interested :) Cheers, rijndael --- Original Message --- On Monday, October 3rd, 2022 at 7:01 PM, Ruben Somsen via bitcoin-dev wrote: > Hi David, > > Thanks for the excellent suggestion, that makes the protocol much more > elegant and actually increases my optimism about its practicality. Also, > interesting observation that there is overlap with BIP78. From the > perspective of the recipient it does mean there's a potential privacy > reduction when a placeholder transaction goes through (these should perhaps > be marked in the wallet?), but I suppose this is still better than no payment > at all. I also like your point that it doubles as a way to potentially bridge > gaps. > > Cheers, > Ruben > > On Mon, Oct 3, 2022 at 12:48 AM David A. Harding wrote: > >> On 2022-09-29 05:39, Ruben Somsen via bitcoin-dev wrote: >>> An alternative mitigation (more user friendly, but more implementation >>> complexity) would be to require the sender to reveal their intended >>> transaction to the server prior to receiving the address[^9]. This is >>> not a privacy degradation, since the server could already learn this >>> information regardless. If the transaction doesn't end up getting >>> sent, any subsequent attempt to reuse one of the inputs should either >>> be (temporarily) blacklisted or responded to with the same address >>> that was given out earlier >>> [...] >>> [^9]: *This would essentially look like an incomplete but signed >>> transaction where the output address is still missing.* >> >> Hi Ruben, >> >> Instead of maintaining a database of inputs that should be blocked or >> mapped to addresses, have the spender submit to you (but not the >> network) a valid transaction paying a placeholder address and in return >> give them a guaranteed unique address. They can then broadcast a >> transaction using the same inputs to pay the guaranteed unique address. >> If you don't see that transaction within a reasonable amount of time, >> broadcast the transaction paying the placeholder address. This makes it >> cost the same to them whether they use the unique address or not. By >> placeholder address, I mean an address of yours that's never received a >> payment but which may have been provided in a previous invoice (e.g. to >> prevent exceeding the gap limit). >> >> In short, what I think I've described is the BIP78 payjoin protocol >> without any payjoining going on (which is allowed by BIP78). BTCPay >> already implements BIP78, as do several wallets, and I think it >>
Re: [bitcoin-dev] Why OpenTimestamps does not "linearize" its transactions
Good morning Undiscussed Horrific Abuse, One Victim of Many, > the reason i call this 'designed to be broken' is that it lets people > rewrite history to their stories by republishing other people's > documents under different contexts. The basic service that a timestamp service provides is “this content (or at least a digest of this content) existed at least as early as this timestamp.” It says nothing about how long before the timestamp the content existed, and says nothing about how long after the timestamp the content continues to exist. It also says nothing about uniqueness or validity of the content. For example, a document that existed for a year before its timestamp and was deleted immediately afterwards, and a document that was created the instant before its timestamp and was retained “forever” afterwards would have timestamp that are equally valid (provided you retained the digest of the document to validate the timestamp in the former case). Assurances around uniqueness (for example, preventing double spends) are a proof-of-publication or set-consistency problem, and assurances around validity are a validation problem. These other semantics can be built into systems that also rely on timestamps, but you can have a useful time stamping system without them. This is what OTS provides. When you say it’s “designed to be broken” do you mean that it claims to provide assurances that it doesn’t, or that the set of assurances that it provides are not a useful set. > I would not be surprised if OTS also fails to add tx history > containing its hashes to associated wallets, letting them be lost in > chain forks. I’ve always used OTS through the cli, which just spits out and works with .ots files, which are sterilized commitment operations. Storage of the ots files for later checking has always been a “problem left to the application” for me. Are there wallets that you’ve seen that incorporate OTS? I’d love to see them! Best, rot13maxi On Tue, Jun 14, 2022 at 7:53 AM, Undiscussed Horrific Abuse, One Victim of Many via bitcoin-dev wrote: > I was privately asked for more opinions. I am sharing them publicly below: > > It's always been clear that OTS proves longness of duration but not > shortness. It doesn't demonstrate that an earlier work was not > published, because it hashes each document hash with private material > the author must separately publicize. Any unpublished private material > could be an earlier equivalent to a public proof. > > the reason i call this 'designed to be broken' is that it lets people > rewrite history to their stories by republishing other people's > documents under different contexts. > > I would not be surprised if OTS also fails to add tx history > containing its hashes to associated wallets, letting them be lost in > chain forks. > ___ > 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] ANYPREVOUT in place of CTV
Good morning darosior, Do you know if there is a working implementation of APO somewhere that people can use to try out some of the proposed usecases? For example, it would be great to see what eltoo 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, Apr 22, 2022 at 7:11 AM, darosior via bitcoin-dev wrote: > 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 someone correct me if i'm > wrong) more widely accepted than > CTV's. > > SIGHASH_ANYPREVOUTANYSCRIPT, if its "ANYONECANPAY" behaviour is made optional > [0], can emulate CTV just fine. > Sure then you can't have bare or Segwit v0 CTV, and it's a bit more expensive > to use. But we can consider CTV > an optimization of APO-AS covenants. > > CTV advocates have been presenting vaults as the flagship usecase. Although > as someone who've been trying to > implement practical vaults for the past 2 years i doubt CTV is necessary nor > sufficient for this (but still > useful!), using APO-AS covers it. And it's not a couple dozen more virtual > bytes that are going to matter for > a potential vault user. > > If after some time all of us who are currently dubious about CTV's stated > usecases are proven wrong by onchain > usage of a less efficient construction to achieve the same goal, we could > roll-out CTV as an optimization. In > the meantime others will have been able to deploy new applications leveraging > ANYPREVOUT (Eltoo, blind > statechains, etc..[1]). > > Given the interest in, and demand for, both simple covenants and better > offchain protocols it seems to me that > BIP118 is a soft fork candidate that could benefit more (if not most of) > Bitcoin users. > Actually i'd also be interested in knowing if people would oppose the APO-AS > part of BIP118, since it enables > CTV's features, for the same reason they'd oppose BIP119. > > [0] That is, to not commit to the other inputs of the transaction (via > `sha_sequences` and maybe also > `sha_amounts`). Cf > https://github.com/bitcoin/bips/blob/master/bip-0118.mediawiki#signature-message. > > [1] https://anyprevout.xyz/ "Use Cases" section > ___ > 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
