rot13maxi [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2022-04-22 to 2023-01-27
💬 Posted a total of 6 messages
📚 Participated in the following categories: bitcoin-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-09-07 11:52:33

- reply

📅 Original date posted:2023-08-29
🗒️ Summary of this message: A proposal for private collaborative custody services using FROST multisignatures. The custodian remains unaware of the public key and can sign transactions blindly.
📝 Original message:
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 at lists.linuxfoundation.org](mailto:On Mon, Aug 28, 2023 at 3:35 PM, Nick Farrow via bitcoin-dev <<a href=)> 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 demands that are now impossible for you to enforce (like seen with Mullvad VPN [3]). Censorship requests made from past onchain behavior such as coinjoins becomes impossible, as does the enforcement of address or UTXO blocklists.
>
> By having the collaborative custodian sign under some form of blind Schnorr, the server is not contributing any nonce with binding value for the aggregate nonce. Naively this could open up some form of Drijvers attacks which may allow for forgeries (see FROST paper [0]), but I think we can eliminate given the right approach.
>
> Blind Schnorr schemes also introduce attack vectors with multiple concurrent signing requests [4], one idea to prevent this is to disallow simultaneous signing operations at the collaborative custodian. Even though Bitcoin transactions can require multiple signatures, these signatures could be made sequentially with a rejection of any signature request that uses anything other than the latest nonce.
>
> Risks may differ depending on whether the service is emergency-only or for whether it is frequently a participant in signing operations.
>
> -------
>
> Thanks to @LLFOURN for ongoing thoughts, awareness of enrollment protocols, and observation that this can all fall back into a standard Schnorr signature.
>
> Curious for any thoughts, flaws or expansions upon this idea,
>
> Gist of this post, which I may keep updated and add equations:
> https://gist.github.com/nickfarrow/4be776782bce0c12cca523cbc203fb9d/
>
> Nick
>
> -------
>
> References
>
> * [0] FROST: https://eprint.iacr.org/2020/852.pdf
> * [1] A Survey and Refinement of Repairable Threshold Schemes (Enrollment: Section 4.3): https://eprint.iacr.org/2017/1155.pdf
> * [2] Modifying FROST Threshold and Signers: https://gist.github.com/nickfarrow/64c2e65191cde6a1a47bbd4572bf8cf8/
> * [3] Mullvad VPN was subject to a search warrant. Customer data not compromised: https://mullvad.net/en/blog/2023/4/20/mullvad-vpn-was-subject-to-a-search-warrant-customer-data-not-compromised/
> * [4] Blind Schnorr Signatures and Signed ElGamal Encryption in the Algebraic Group Model: https://eprint.iacr.org/2019/877.pdf
> * [5] FROST in secp256kfun: https://docs.rs/schnorr_fun/latest/schnorr_fun/frost/index.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230829/adbdd278/attachment.html>

2023-08-22 14:20:56

- reply

📅 Original date posted:2023-08-21
🗒️ Summary of this message: A project called STAMPS embeds image data into multisig outputs, while schemes like Pay-to-Contact allow tweaking a pubkey with data. Banning arbitrary data may lead to encoding data within public keys.
📝 Original message:
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 <bitcoin-dev at lists.linuxfoundation.org> 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 <bitcoin-dev at lists.linuxfoundation.org> 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 at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230821/24e41428/attachment-0001.html>

2023-07-30 22:52:21

- reply

📅 Original date posted:2023-07-30
🗒️ Summary of this message: Bitcoin defenders can win the cat and mouse game against spam transactions by detecting and standardizing them, making it harder for inscriptions to reach miners. Appeals to Satoshi are not convincing arguments.
📝 Original message:
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 at lists.linuxfoundation.org](mailto:On Sun, Jul 30, 2023 at 2:04 PM, Léo Haf via bitcoin-dev <<a href=)> 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, vjudeu at 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, people won't learn "this is bad, don't do that", they could read it as "use the old way instead", as long as you won't block all possible ways. And doing that, requires for example creating new nodes, without synchronizing non-consensus data, like it could be done in "assume UTXO" model.
>
>>
>
>> Also note that as long as people use Taproot to upload a lot of data, you can still turn off the witness, and become a pre-Segwit node. But if you block those ways, then people will push data into legacy parts, and then you will need more code to strip it correctly. The block 774628 maybe contains almost 4 MB of data from the perspective of Segwit node, but the legacy part is actually very small, so by turning witness off, you can strip it to maybe just a few kilobytes.
>
>>
>
>>> I want to emphasize that my proposal does not involve implementing a soft fork in any way. On the contrary, what I am asking is simply to consider adding a standardization option. This option would allow the community to freely decide whether it should be activated or not.
>
>>
>
>> 1. Without a soft-fork, those data will be pushed by mining pools anyway, as it happened in the block 774628.
>
>> 2. Adding some settings won't help, as most people use the default configuration. For example, people can configure their nodes to allow free transactions, without recompiling anything. The same with disabling dust amounts. But good luck finding a node in the wild that does anything unusual.
>
>> 3. This patch produced by Luke Dashjr does not address all cases. You could use "OP_TRUE OP_NOTIF" instead of "OP_FALSE OP_IF" used by Ordinals, and easily bypass those restrictions. This will be just a cat and mouse game, where spammers will even use P2PK, if they will be forced to. The Pandora's box is already opened, that fix could be good for February or March, but not now.
>
>>
>
>>
>
>>
>
>>> On 2023-07-26 11:47:09 user leohaf at orangepill.ovh wrote:
>
>>> I understand your point of view. However, inscription represent by far the largest spam attack due to their ability to embed themselves in the witness with a fee reduction.
>
>>
>
>> Unlike other methods, such as using the op_return field which could also be used to spam the chain, the associated fees and the standardization rule limiting op_return to 80 bytes have so far prevented similar abuses.
>
>>
>
>> Although attempting to stop inscription could lead to more serious issues, not taking action against these inscription could be interpreted by spammers as tacit acceptance of their practice. This could encourage more similar spam attacks in the future, as spammers might perceive that the Bitcoin network tolerates this kind of behavior.
>
>>
>
>> I want to emphasize that my proposal does not involve implementing a soft fork in any way. On the contrary, what I am asking is simply to consider adding a standardization option. This option would allow the community to freely decide whether it should be activated or not.
>
>>
>
>>
>
>>>> Le 26 juil. 2023 à 07:30, vjudeu at gazeta.pl a écrit :
>
>>>> and I would like to understand why this problem has not been addressed more seriously
>
>>> Because if nobody has any good solution, then status quo is preserved. If tomorrow ECDSA would be broken, the default state of the network would be "just do nothing", and every solution would be backward-compatible with that approach. Burn old coins, and people will call it "Tether", redistribute them, and people will call it "BSV". Leave everything untouched, and the network will split into N parts, and then you pick the strongest chain to decide, what should be done.
>
>>>> However, when it comes to inscriptions, there are no available options except for a patch produced by Luke Dashjr.
>
>>> Because the real solution should address some different problem, that was always there, and nobody knows, how to deal with it: the problem of forever-growing initial blockchain download time, and forever-growing UTXO set. Some changes with "assume UTXO" are trying to address just that, but this code is not yet completed.
>
>>>> So, I wonder why there are no options to reject inscriptions in the mempool of a node.
>
>>> Because it will lead you to never ending chase. You will block one inscriptions, and different ones will be created. Now, they are present even on chains, where there is no Taproot, or even Segwit. That means, if you try to kill them, then they will be replaced by N regular indistinguishable transactions, and then you will go back to those more serious problems under the hood: IBD time, and UTXO size.
>
>>>> Inscriptions are primarily used to sell NFTs or Tokens, concepts that the Bitcoin community has consistently rejected.
>
>>> The community also rejected things like sidechains, and they are still present, just in a more centralized form. There are some unstoppable concepts, for example soft-forks. You cannot stop a soft-fork. What inscription creators did, is just non-enforced soft-fork. They believe their rules are followed to the letter, but this is not the case, as you can create a valid Bitcoin transaction, that will be some invalid Ordinals transaction (because their additional rules are not enforced by miners and nodes).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230730/dfc353d3/attachment-0001.html>

2023-06-07 23:18:46

- reply

📅 Original date posted:2023-01-27
🗒️ Summary of this message: Unlimited storage for witness data in taproot transactions is not accurate as the block size limit still applies, and future disk use of unpruned nodes should be considered.
📝 Original message: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 <bitcoin-dev at lists.linuxfoundation.org> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230127/88503ad3/attachment.html>

2023-06-07 23:18:16

- reply

📅 Original date posted:2023-01-09
🗒️ Summary of this message: Vaults are a necessary part of Bitcoin's viability, but covenant-enabling consensus functionality is necessary to make vault use practical. A middle way design is proposed.
📝 Original message: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 <bitcoin-dev at lists.linuxfoundation.org> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230109/80a1b3e0/attachment.html>

2023-06-07 23:14:06

- reply

📅 Original date posted:2022-10-18
📝 Original message: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 <apoelstra at wpsoftware.net> 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

2023-06-07 23:14:04

- reply

📅 Original date posted:2022-10-17
📝 Original message: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 <bitcoin-dev at lists.linuxfoundation.org> 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 <dave at dtrt.org> 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
>> satisfies all the design constraints you've described.
>>
>> -Dave
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221017/6f8d600b/attachment.html>

2023-06-07 23:10:40

- reply

📅 Original date posted:2022-06-14
📝 Original message: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 <bitcoin-dev at lists.linuxfoundation.org> 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220614/883de78f/attachment.html>

2023-06-07 23:07:57

- reply

📅 Original date posted:2022-04-22
📝 Original message: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 <bitcoin-dev at lists.linuxfoundation.org> 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220422/801f1d1e/attachment.html>