pull down to refresh
100 sats \ 0 replies \ @lightcoin 7 Oct \ on: Does a UASF require a majority of nodes to be aproved? bitcoin_beginners
This section of a post I published before the last UASF in 2017 may be helpful:
https://lightco.in/2017/06/02/segwit-uasf/
And this post is not specific to UASF but may help you build a better understanding of how consensus changes work in bitcoin:
https://lightco.in/2017/07/30/bitcoin-fork-split/
By increasing the size of OP_RETURN, we enable criminals to insert illegal data
The premise of that line of thinking in Vlad's thread is false from the start. Changing the default policy in Bitcoin Core isn't "enabling" any new behavior, it simply makes the existing behavior (via modified -datacarrier settings or custom clients like Libre Relay) standard so that users of larger OP_RETURNs can expect timely confirmations, which are required by some L2 designs.
For the people worried about the legal implications of relaying illegal images embedded in transactions, are you also worried about relaying transactions from US government sanctioned addresses?
No, but if this does become a legal issue, then it has broader implications than just bitcoin. Everyone running a box on the internet that other people's bitcoin data packets flow through could be implicated. INAL but this is probably already protected under the law somehow, since people have been using the internet to do crime since forever.
why is there only a single bulletpoint about bitcoin in this "bitcoin tech talk" newsletter, and it's not even about bitcoin tech?
btw @jimmysong any response to this? Or are you gonna pretend like you aren't spreading misinformation to your followers?
Absolutely! From trust-minimized BTC bridging with BitVM to more scalable and private multisig with FROST and MuSig2, Taproot has given us some really great improvements.
btw @jimmysong any response to this?
fair. your statement "the greatest Bitfinex hack.... that end in creating tether" had a different order of operations but these events could have still been related yeah. I will look at the links you shared (I did not see them before)
Envision a mempool explorer full of JPEGs, BRC20s
this is already happening
It enables BitVM
BitVM is already possible on bitcoin today
Not to mention all the unintended consequences.
such as?
it enables gaming and gambling
gaming and gambling is already possible on/with bitcoin
102 sats \ 1 reply \ @lightcoin OP 12 Sep \ parent \ on: Why all Bitcoiners should support covenants bitcoin
Would introducing covenants require adding code to the code-base?
yes
As AI becomes more useful as agentic systems development tools, what vulnerabilities might not be found and exploited by a human dev, but could by intelligent neural networks working for an adversary?
Not sure how I, a human, am supposed to answer this question. My post does explicitly acknowledge (and set aside) the issue of implementation risks, though.
Will there be certain unforeseen economic attack vectors, such as mempools becoming congested, as seen in the past, that would make the basic operation and utility become an issue? (again, thinking how an adversarial strategist may want to game and disrupt current usage. * I read you covered that, but just wondered if that is not a serious trade-off for you.
A full mempool is a good problem to have as far as I'm concerned. It's also something that could happen with or without a covenant soft fork. So we should have the tooling to deal with that situation in any case.
Would covenants soft-fork increase overheads for running a node?
Maybe, maybe not. Again something that could happen with or without a covenant soft fork, and something we should have the tooling to deal with in any case. See projects like Utreexo and Zerosync for examples of mitigations for node bloat.
202 sats \ 5 replies \ @lightcoin OP 12 Sep \ parent \ on: Why all Bitcoiners should support covenants bitcoin
Spark is an implementation of a statechain, which does something different than a covenant: statechains enable the offchain transfer of UTXOs by essentially passing around the private key to a UTXO offchain. The reason this is considered secure is because it's actually only one private key in a 2-of-2 multisig, with the other key owned by a central "statechain entity", who "promises" to only co-sign transfers that conform to the protocol. There are more details to it than that, but that is the gist. I'm not aware of any improvements that covenants can make specific to statechains.
A "real world" example of a key deletion covenant would be what Rewind wallet does.
100 sats \ 0 replies \ @lightcoin 12 Sep \ parent \ on: Why I'm Against Covenants (Jimmy Song) bitcoin
it is worth noting that this same "problem" would also occur if bitcoin had a large number of UTXOs for other reasons (like lots of users taking self-custody)
it's a problem that would need to be solved (and is being solved by solutions like zerosync and utreexo) regardless of the use-case that caused it.
I think we're talking about two different things... one is about "bitcoin users", who I will gladly listen to feedback from everyone, especially if they are using or could benefit from a product I have built. The other is about "bitcoin activists" and what they choose to focus on. People who want to be "bitcoin adoption" activists and focus on that are great, they are needed. But we shouldn't focus only on that, to the exclusion of continuing to improve bitcoin tech to make bitcoin better money. That is the point I was trying to make there.
So let's see where it goes.
indeed
The changes I push for in the products I work on are entirely customer/user-driven. An idea might start from an insight I have based on my own experience but to invest commercial resources I take additional steps to validate sufficient market demand, which mainly involves a lot of talking to existing or potential users, among other forms of market research and validation techniques.
150 sats \ 1 reply \ @lightcoin 12 Sep \ parent \ on: Why I'm Against Covenants (Jimmy Song) bitcoin
You said:
I would like to have some reassurance that covenants would actually unlock more adoption and more self custody, rather than unlock more memecoinery.
If the information in my post was clear, I would expect it to have at least "some reassurance" of what you're looking for. So I concluded that either I wasn't clear, or you are asking for a stronger assurance than I (or anyone else) could give.
Memecoins have existed on bitcoin since colored coins were first invented over a decade ago. Don't let their existence or possibility scare you away from supporting changes that actually improve the use of bitcoin as money.
little introspection on whether or not these technical solutions are really needed, and whether you're putting the cart before the horse (introducing technology to solve problems that aren't really problems, or aren't technical problems)
how can you say this when my blog post which you linked to in your post does just that?
I'm no expert, but if you were to ask me, I think the lack of bitcoin adoption is not primarily technical
I am actually a bitcoin product manager who talks to users and potential users of bitcoin regularly as part of my job, and I have been building bitcoin products for over a decade, and I can tell you with absolute certainty that bitcoin's technical limitations are holding back adoption.
They deploy, and over time there's no use case.
My blog post which you read gave citations for alts with hundreds of thousands of "wrapped BTC" being used there. I personally know people who use "privacy coins" because they aren't satisfied with bitcoin or Lightning privacy. This "no use case" trope is flat out wrong.
Personally, i'd rather focus my attention on the social and economic aspects of bitcoin adoption/development.
That's fine, you can focus your attention where you want. Nobody needs to be involved or an expert in every aspect of bitcoin. Just stay out of the way of people who choose to focus on improving the tech, unless you have good reason to believe they're actively harming bitcoin.
112 sats \ 16 replies \ @lightcoin 12 Sep \ parent \ on: Why I'm Against Covenants (Jimmy Song) bitcoin
Footnotes 3 and 4 show evidence only of BTC market size, not evidence of demand for covenants.
Footnote 3 shows how much BTC is locked in various kinds of bridges, which are a trusted alternative to covenants.
Footnote 4 shows how much BTC is locked in the Babylon protocol, which uses a trusted multisig in place of a covenant.
Footnotes 5-11 are documents regarding what technologies covenants could enable, not evidence that those services are in demand.
Note that this section header is titled "There is good evidence of their utility", not "there is good evidence of their demand". That said, there are plenty of examples of the developers of the technologies in question publicly "demanding" a covenant soft fork e.g. https://ctv-csfs.com/
I would like to have some reassurance that covenants would actually unlock more adoption and more self custody, rather than unlock more memecoinery.
Prior to the invention of bitcoin, it's likely >99% of the people who currently own bitcoin had no idea what the Byzantine General's Problem was or why a solution would have value to them. (And if I had to guess, they probably still don't know.) Satoshi didn't ask "is there demand for solving the Byzantine General's Problem?" and base his decision to work on bitcoin on that. Similarly covenants are a technical solution to technical problems. It takes a certain amount of insight to extrapolate from there that these solutions also have utility to end users.
In my post I explain as clear as I can the technical problems that covenants solve and how this can provide utility for end users and plausibly lead to increased bitcoin value and/or adoption. I don't know how I can make it any clearer. If you're looking for an ironclad guarantee about future bitcoin adoption, no one can give that to you, neither the covenant supporters nor the covenant opponents -- this is not something that can be known with certainty in advance.
Bitfinex hack was in 2016. USDT was created in 2014.