<unnamed>

Public Key

npub12aguh8y7hacsxc3c7fsjzkqh95nu9cuh4ec6htx9y3sz75722npqmllglz

Profile Code

nprofile1qqs9w5wtnj0t7ugrvgu0ycfptqtj6f7zuwt6uudt4nzjgcp02099fsspzpmhxue69uhkummnw3ezuamfdejssnpwaj

Publishing to

nostr.wine

Last Notes

2023-07-30 22:52:21 UTC

- 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 UTC

- 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 UTC

- 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:04 UTC

- 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 UTC

- 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 UTC

- 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>