FOLLOW
Rusty Russell
npub179e...lz4s
Lead Core Lightning, Standards Wrangler, Bitcoin Script Restoration ponderer, coder. Full time employed on Free and Open Source Software since 1998. Joyous hacking with others for over 25 years.
FOLLOW
MESSAGE
SATS
🧡
5 hours ago
15 hours ago•••
I think about the fate of this “caution: falling rocks” sign a lot.
🧡
5 hours ago
14 hours ago•••
Well deserved. Dunno where our product or Bitcoin research would be in general without these people.
14 hours ago•••
Congratulations to our very own Tim Ruffing and Jonas Nick, along with Yannick Seurin from Ledger, Chelsea Komlo, and Ian Goldberg.
They have received the 2024 Bitcoin Research Prize for their work on MuSig2 and FROST!
🧡
29 hours ago
31 hours ago•••
It was more than a store; it was a statement.
Join nprofile1qyv8wumn8ghj7enfd36x2u3wdehhxarj9emkjmn99uq3samnwvaz7tmrv4kxcctj9ehx7um5wgh8w6twv5hsz8rhwden5te0vf6kx6m9wshxxmmjv93kcefwwdhkx6tpdshsz9nhwden5te0v4jx2m3wdehhxarj9ekxzmny9uq3jamnwvaz7tmhda6zuum4v3hkxctjd3hhxtnrdakj7qg6waehxw309ac82unpwe5kgcfwdehhxarj9ekxzmny9uq32amnwvaz7tmjv4kxz7fww468smewdahx2tcpremhxue69uhkummnw3ez6er9wch8wetvd3hhyer9wghxuet59uq3vamnwvaz7tmhda6zuum0we3xjapwdphhxap0qyvhwumn8ghj7un9d3shjtnddakk7um5wgh8q6twdvhsz9mhwden5te0wdjkzunrdqhxummn9e6x7erp0yhszrnhwden5te0dehhxtnvdakz7qgewaehxw309ac8yetdd96k6tnswf5k6ctv9ehx2ap0qythwumn8ghj7ct5d3shxtnwdaehgu3wd3skuep0qy38wumn8ghj7mrfvfex2ar9vd58x7tnw3jk6uewdehhxarjxyhxxmmd9uq32amnwvaz7tmhda6zuemfwf5kumewdaexwtcprpmhxue69uhkummnv3exjan99eshqup0wfjkccteqyt8wumn8ghj7un9d3shjtnwdaehgu3wdejhgtcpr9mhxue69uhhyetvv9ujuat50phjummwv5hkx6rpwsq3samnwvaz7tmrwfjkzarj9ehx7um5wgh8w6twv5hsqgqzpukjrtsfhu6lehakthk0z3uts3h47u52kvx9a24u6mggr2qu8c0fe49z for a throwback to the first-ever Lightning store powered by the original Core Lightning team of Rusty Russell and Christian Decker.
#Reckless
40 hours ago•••
Trying to do everything, but mainly doing a little of everything badly. #CLN release is late, I've been ignoring the BOLTs changes,, I haven't even looked at GSR since my OP_NEXT talk, and my comprehensive list of opcodes for introspection is still stuck in my head.
I try to take time to post on #nostr over morning coffee though, since doing that every day helps move things forward.
🧡
35 hours ago
40 hours ago•••
feel this
🧡
35 hours ago
39 hours ago•••
appreciate your work
🧡
35 hours ago
36 hours ago•••
The options are that or constantly be annoying other people cause you aren’t doing stuff you promised them to keep focus 😭
39 hours ago•••
🫂
2 days ago•••
More generally, I agree with James' observation that Bitcoin Core devs are paying much less attention to soft forks than they used to.
I can only speak for myself here. Part of the problem is that the current proposals don't excite me, yet. That's even after spending time at the op_next conference.
SegWit (which happened before I was involved) brought the promise of Lightning. Taproot lets you build cold storage with hidden fallback options.
I'm still waiting for MuSig2 to finally have broad adoption, something that's higher on my review list than new soft forks, and I barely get to it.
In that light, talk of a vault soft fork seems premature. The tool development is too far behind even for forks that already activated.
Similarly congestion control doesn't excite me. I'm general I'm skeptical of claims that the masses are suddenly going to self-custody because of a dramatic event in US politics. Especially given that plenty of other countries are in worse shape and we don't see self custody blossom at a scale where it causes congestion. The US is 5% of the world population.
That's not to say that I'm against these ideas. If I see other people work on and activate them in a competent and careful manner I might be fine with it. It's sad that their main proponents and developers burned out, and that certainly won't speed things up. Maybe grants tailored for potential soft fork devs can help here, as long as the right expectations are set.
But not being opposed does not reach the bar of me actively reviewing it, which is part of what pushes things forward.
If I see a more fleshed out design for a (BitVM powered?) sidechain with unilateral (no 1 of N nonsense) exit that gives me full privacy (Shielded CSV?), that would get me more excited. Especially if it's clear which specific opcodes are best to get there.
Other devs will have other things and other thresholds that get them out of their soft-fork winter sleep. There's a "I know it when I see it" aspect to this too.
All that said, it might be the case that one day every single core dev is excited about a soft fork proposal, or would be if they read enough about it, yet is too distracted by their day to day focus. But I'm not sure if that is really what's happening.
47 hours ago•••
Agreed, especially on the false urgency. I do think vaults are cool as a final get-out-of-jail card to prevent my stack from getting stolen. But we can spend a few more years hashing out covenant proposals IMO.
47 hours ago•••
Vaults are useful to prevent your hot (or luke warm) coins from being stolen. They give you a button to send money to cold storage.
Using them toto protect your cold storage is trickier, because then where do you send the coins? What if you fallback cold storage actually has worse security?
There are more subtle ways in which you can use vaults as a dead man switch, which current requires moving your UTXO's on a regular interval.
40 hours ago•••
Vault to a custodian makes sense. In an emergency, you use that dormant Coinbase acct. They don't even know that's why you have it!
But in general, I see OP_VAULT and go "why can't Script do that?". Explicit opcodes for uses strike me as premature optimization or a throwing up of hands on Script as a programming language. I want to fix that, even though I'm unlikely to use vaults.
47 hours ago•••
I had one idea which was to just loop the money back to the cold storage - This basically just adds a time delay to withdrawing.
The point would be to pre-commit to never sending my Bitcoin faster than two weeks, and then I discourage anybody from executing a $5 wrench attack.
Not sure if that's a good idea but it sounds interesting as yet another layer of defense at least.
45 hours ago•••
This is an interesting response to the debate, and further firms up my sense that the real problem with enacting a covenant soft fork is the lack of a genuinely compelling protocol proposal using it.
Don't get me wrong, there are lots of proposals, some of which are useful: vaults seems like the strongest candidate there, but they are not critical to bitcoin's survival/success (important, yes, critical, i suspect no), and congestion control is valuable but neither of these are genuinely compelling. Lightning was, and segwit was propelled by its existence.
To illustrate my point, if you go to utxos.org, another proposal it highlights as an example is "Bitcoin Clique". I read the paper yesterday, and the TLDR is a kind of coinpool construct that requires covenants to allow exchange of funds within the pool. It has some neat tricks (repeated trees with double spend prevention through adaptors), but imo it doesn't reach the "compelling" level because: a) it needs an operator, who needs to put up linear collateral b) exit is unilateral, of course, but is very disruptive (so large groups might never work), c) exit onchain footprint is log_2(n) in pool size which sounds great but that is another size restriction. d) fixed denomination coins!
This protocol is cool but "meh" in terms of it ever getting usage.
We need something that feels very 10x (business/marketing speak). I don't think vaults have that feeling, and congestion control definitely doesn't. That's why I believe Sjors is right to mention sidechains/ShieldedCSV (though I think the latter doesn't actually go in this direction).
You might read this and reasonably ask me: "Well, but if you don't know any super-duper compelling usage of covenants yet, why are you so keen on finding them?" It's not easy to explain, but it's an intuition I've developed, that constraining destination might be the last piece of the puzzle (after malleability fix for presigning, then schnorr for musig, mast for script size) that allows offchain contracting to work to its full extent, which I don't care about to do fancy programming in bitcoin, I care about it because I think it's needed for 50x to 500x more users of Bitcoin.
TLDR someone needs to find a kickass off chain (L2 if you like) protocol that could 50x the usage of bitcoin using covenants, *without centralization *, then needs to write code and deploy it on say Liquid and signet. Then the conversation changes. Before then, we're probably not going to get vaults etc. (I could be wrong!).
2 days ago•••
More generally, I agree with James' observation that Bitcoin Core devs are paying much less attention to soft forks than they used to.
I can only speak for myself here. Part of the problem is that the current proposals don't excite me, yet. That's even after spending time at the op_next conference.
SegWit (which happened before I was involved) brought the promise of Lightning. Taproot lets you build cold storage with hidden fallback options.
I'm still waiting for MuSig2 to finally have broad adoption, something that's higher on my review list than new soft forks, and I barely get to it.
In that light, talk of a vault soft fork seems premature. The tool development is too far behind even for forks that already activated.
Similarly congestion control doesn't excite me. I'm general I'm skeptical of claims that the masses are suddenly going to self-custody because of a dramatic event in US politics. Especially given that plenty of other countries are in worse shape and we don't see self custody blossom at a scale where it causes congestion. The US is 5% of the world population.
That's not to say that I'm against these ideas. If I see other people work on and activate them in a competent and careful manner I might be fine with it. It's sad that their main proponents and developers burned out, and that certainly won't speed things up. Maybe grants tailored for potential soft fork devs can help here, as long as the right expectations are set.
But not being opposed does not reach the bar of me actively reviewing it, which is part of what pushes things forward.
If I see a more fleshed out design for a (BitVM powered?) sidechain with unilateral (no 1 of N nonsense) exit that gives me full privacy (Shielded CSV?), that would get me more excited. Especially if it's clear which specific opcodes are best to get there.
Other devs will have other things and other thresholds that get them out of their soft-fork winter sleep. There's a "I know it when I see it" aspect to this too.
All that said, it might be the case that one day every single core dev is excited about a soft fork proposal, or would be if they read enough about it, yet is too distracted by their day to day focus. But I'm not sure if that is really what's happening.
40 hours ago•••
Agreed. SIGHASH_NOINPUT has a clear use case, but got mired in the fact that it opens covenants.
None of these proposals offer compelling use cases (ie beyond, basically, refining lightning) because they are all incremental. They cater to users who don't want to use a UTXO, not those who can't afford to. And that's likely to be a narrow band of users, in the long term.
The only protocol I can conceive of which does give something to sub-UTXO users is a group structure where all the funds can be burned if any user proves the coordinator misbehaved (Christian Decker named this a "Nero protocol", which I like). But proving every kind of misbehavior, including failure to respond, is a very big, maybe impossible, ask. TBH, I haven't tried...
39 hours ago•••
On noinput/APO, that's interesting, perhaps even a good counter to my point. Do you think that its potential use for covenants is actually the reason it hasn't reached a concrete soft fork proposal (hence muddying the waters or smth)?
It always felt like a very powerful change, and to the extent any of these things could be dangerous, it is so more than say ctv. Or is it that eltoo also is not reaching the threshold of "10x" (colloq. speaking).
38 hours ago•••
Pools are a killer app and Ark (L2) will use them.
They already built a prototype on liquid. CTV works for them which could be upgraded to TXHASH later.
38 hours ago•••
You're right to bring up Ark. But I have trouble with it, first because I don't understand it well (where is it documented properly, in detail?) and also it having "operators"/service providers is a big concern of mine - you're free to disagree on that, though. I really need to understand it but I hate it when there isn't a spec, or paper to read.
With respect to the pools concept generally, I am not so optimistic as you, but I 100% agree it's a tantalizing area. Unless it works with very large numbers (I don't think 100 cuts it, for example) I suspect it won't ever go anywhere, and it's critical that it doesn't effectively require onlineness of all participants etc. I find most designs are fragile, or, they have centralization.
37 hours ago•••
Even I don't like the use of ASPs. However, I beleive a better version of Ark can be built using maker-taker model as used in joinmarket.
In coinjoin it can make transactions less likely to be identified on-chain as cj, more freedom to exit at any time and reduce interactivity.
37 hours ago•••
Re the docs, I was looking at that page earlier today, perhaps unfairly dismissing it as "high level guide" when i want a detailed protocol description. If that's the most detailed description that exists maybe it works.
47 hours ago•••
Re world population: keep in mind that although the US is very rich, they don't have more UTXOs. For congestion only the number of transactions matter, not the amounts.
When there is congestion then the rich will push out the poor.
But my point is that adding a few million Americans to the pool of people-with-a-government-that-actively-hates-Bitcoin is not going to make a dent in the number of transactions.
That requires a global shift towards self custody. I'd love to see that of course.
46 hours ago•••
Expecting global shift without improving UX makes no difference.
46 hours ago•••
It's a two way street. We make non-custodial Bitcoin UX better, governments make fiat and custodial Bitcoin suck more.
2 days ago•••
I responded on Twitter too, but this is such a strange rant to me.
Bitcoin Core (contributor)’s current push for better mempool policy is directly related to multi-party UTXO ownership and scaling. It specifically substantially improves lighting in practice today, and will certainly be required for any future scaling technologies.
In the mean time, lots of folks (like James) continue to do research into how to scale Bitcoin (and cryptocurrencies generally). There’s no reason to care if that happens from Bitcoin Core contributors or others, and we’re still really far from having any particularly good ideas on this front. As that research continues, there’s no reason for concrete software towards short-term soft-forks.
2 days ago•••
My thoughts here are definitely unrefined, but I am sceptical of the "onchain rush solved by covenants" argument.
1. You're assuming fee volatility. I expect this to reduce over time, as regular Bitcoin usages adapt their behaviour and smooth fees
2. You're assuming wallet infrastructure which is pre-built to handle this case.
3. You're changing the deal, so the recipient now pays fees. If you shape things as payment trees, the tradeoff gets worse (approaching twice the weight of just paying normally, requiring that much fee volatility to make sense), and you introduce games between the recipients to figure out who pays fees.
4. You have created a novel financial instrument on fee futures, not something I accept as a "payment", as I have not received it, and you've offloaded an unknown level of costs to me to "collect" it.
5. In real bankruptcy, this is not what you want. You don't want your funds stuck on chain. Many might want theirs transferred in one tx to Coinbase. Others will want payment over lightning, or fiat.
6. You can do this badly, today. You can publish a zero-fee tx which pays everyone, or even a tree. That at least proves you have the funds, and can be seen by existing wallets. This, of course, requires the mempool changes which James complains about.
In summary, I don't see congestion trees actually being used: certainly not for this bank-run-in-high-fee scenario.
2 days ago•••
I responded on Twitter too, but this is such a strange rant to me.
Bitcoin Core (contributor)’s current push for better mempool policy is directly related to multi-party UTXO ownership and scaling. It specifically substantially improves lighting in practice today, and will certainly be required for any future scaling technologies.
In the mean time, lots of folks (like James) continue to do research into how to scale Bitcoin (and cryptocurrencies generally). There’s no reason to care if that happens from Bitcoin Core contributors or others, and we’re still really far from having any particularly good ideas on this front. As that research continues, there’s no reason for concrete software towards short-term soft-forks.
2 days ago•••
Very good points.
It's sad that CTV became the poster-child of those who want soft-forks on Bitcoin since it is kinda useless by itself.
2 days ago•••
I think interesting ideas using it were eventually proposed…..after most people had given up on CTV 🤷‍♂️
2 days ago•••
I wouldn't say it's useless. For our Ark constructions, it is exactly what we need. Anything else would be overkill.
2 days ago•••
For lightning it's far less than we hoped, though not useless: there's a lightly-reviewed proposal to use it to avoid a latency hit for Taproot channels. I haven't examined carefully whether it's the ideal solution, though.
2 days ago•••
I thought I heard Ark had changed its requirements since the initial idea (which if I remember correctly required CTV for non-interactivity), but this is good to hear I guess.
2 days ago•••
I've actually been thinking to restructure the TXHASH BIP as an upgrade of CTV. I believe CTV is mature enough to start activation signaling tomorrow. And I'm in favor of doing that. I don't want TXHASH work to hold it back. It can perfectly be structured as a CTV upgrade without much technical debt.
2 days ago•••
It's not useless.
2 days ago•••
Yea, I think this is basically why most people dismissed congestion trees entirely when CTV came out…
2 days ago•••
Do you disagree with his numbers and prospects for UTXO ownership?
2 days ago•••
Not sure which numbers you’re referring to, but I think I agree with the need, just strongly disagree with the idea that we have any great solutions. From where I sit, the ideas for scaling using covenants often don’t provide all that much scale, and almost always make other tradeoffs.
IMHO one of the more compelling ideas is timeout trees (which sadly was proposed after people had kinda given up on CTV). But it makes a huge tradeoff - if you get screwed it costs you 10-20x more to FC than Lightning. Worse, an operator can create a “ghetto” of poor users and screw them all to steal from them. but it gets you great optimistic-case scaling!
Most things end up looking like that, and it leaves me pretty unexcited…except that the research is moving at a clip! I’m excited to see what the research comes up with, in the mean time I’m still building lightning.
42 hours ago•••
By the way, do we really any prospects of creating a trustless decentralized L2 on Bitcoin ever? Isn't it true that Ethereum has had all the ability to make any covenants they want for years and after so much time trying to find a scalable solution the best they got was zk rollups that centralize everything in the hands of a company and require a ton of space anyway that has to be acknowledged by the chain consensus?
In other words, even if we had all the opcodes we wanted by magic we would still be just as bad at scaling as Ethereum is currently?
42 hours ago•••
Yea, I mean the ETH zkRollups are super centralized but to some extent that’s a consequence of these things being hard to build so they need an “escape valve” in practice. There’s not a lot of motivation to remove that but I assume it’ll get removed eventually…. just may be a while.
I do think it’s somewhat informative that ETH only built rollups, which certainly don’t have a huge scalability multiple themselves (doubly so for payments, though it’s important to note ETH is trying to scale computation, not payments).
42 hours ago•••
I agree with you that all proposed L2 solutions based on covenants are horrible (except for Mercury statechains but it's not fully trustless so I guess that makes everybody ignore them?).
I don't understand the last paragraph. What is this research you're talking about? I want to be excited about something too.
42 hours ago•••
There’s a bunch of research on the limits of things - Shielded CSV/rollups (though want to see the limits of a CSV thing if we build a version you can do lightning on top of), Ark/timeout trees is a cool set of ideas that feels like it could be extended, etc. The results certainly don’t point to us having any silver bullets, but I think some of those things probably with some more tweaks may give us a nice direction. But certainly want more analysis.
5 days ago•••
researching a way to build a minimal perfect hashmap of words to store alongside the binary note in nostrdb so that nostrdb clients (damus ios, damus notedeck, zaptream rust) can do O(1) mute word matching, which is pretty important for performance when you have 100s of mute words.
5 days ago•••
Yeah, you don't need minimal. It's overkill: you'll never get those cycles back in savings. But ccan/htable will keep the damage to a single cache line for the common case (a miss) which is what you want.
5 days ago•••
I mainly care about space savings, since I will be saving this alongside each note in the DB
5 days ago•••
I have realtime requirements in notedeck (144fps+), so I like to have important things precomputed by nostrdb ahead of time, like fast an small datastructure for testing mute words.
5 days ago•••
I'm confused. If you want to know "does this have muted words in it?" that's one bit? If you want to support dynamically changing mute words then you probably do a pair of generation numbers (one for words added to mute list, one for words removed) and then recalc on the fly if it could be a false negative / positive.
The performance difference between a 50% full hash table and a 100% full is minimal in practice. And if you don't use the bitstuffing tricks of ccan/htable you will get a second cache hit to actually validate the miss.
5 days ago•••
I could do this outside of nostrdb in a separate worker pool, but my ingester threads are already worker pools and it seems like this will such a common operation, so having a small and optimized data structure on each note makes sense to me
5 days ago•••
I also have this for note blocks, which are the parsed sections of a note, these are also stored in the database. this way each frame I can simply walk and interact with these structures immediately after they come out of the local database subscription and enter the timeline.
5 days ago•••
is htable a perfect hashmap? whats the perfect_bitnum thing
5 days ago•••
ccan/htable.
6 days ago•••
a life long avowed agnostic, i recently came to the realization that i do believe in good and evil, which unfortunately i think does mean that i definitely believe in god
6 days ago•••
It is the absence of God which makes me reckon with good and evil.
6 days ago•••
I'm not following, why would the belief in good and evil require you to believe in God? Couldn't your subjective take on good and evil differ from what any "God" promotes?
I think I'm just making myself more confused 🤣
6 days ago•••
eh it’s hard to explain, but i believe in good and evil hence i now understand the function of god, as archetype 😂
6 days ago•••
confirmed not a nihilist
6 days ago•••
“god is good” proving to be another of those 80IQ truths ffs
7 days ago•••
We're experimenting with some changes to ZEUS Pay today:
- All payments will incur no fee for the receiver (previously 2.5-10% depending on amount)
- The minimum amount receivable has been lowered to 1 satoshi (previously 10 satoshis)
Happy zapping.
7 days ago•••
Do I need a direct channel? I have a lot of inbound capacity but no direct channel.
7 days ago•••
Zero fee routes are needed. The most straightforward way to do this is with a channel to Olympus.
7 days ago•••
zeus pay still not an option with a core lightning node?
7 days ago•••
Nope. Requires hold invoices which are not supported w CLN out the box
7 days ago•••
What would you be need?
7 days ago•••
If we can get those endpoints for the plugin in CLNRest and perhaps and endpoint to check for installed plugins then we can support it for sure!
That being said we also support Twelve.cash BIP-353 addresses in app for CLN nodes today
7 days ago•••
yes i have used this twelve.cash successfulky, however it does not work for bolt11 invoice generation like a typical ln address, just bolt12 offers right? or should it work to generate either depending on the lightning node trying to pay you via that bip-353 address?
7 days ago•••
so whats new fee structure? what % is charged to sender?
7 days ago•••
0% for all payments >= 1 sat
Just like any lightning payment, sender is charged what it takes to get to the destination from their node. In this case the destination is the Olympus by ZEUS node
12 days ago•••
To recycle an old joke: "Bitcoiners' self-worth reaches 90k."
The price is like the weather. People can discuss it endlessly, but unless you're going out into it, it's trivia.
Don't be the price. It's boring.
🧡
12 days ago
12 days ago•••
This is a level of transcendence I aspire to. But for now, I'm going to allow some self back patting.
14 days ago•••
After a long day going through all 44 issues and pull requests for the milestone, and lots of hard work, I've got it down to 49.
This could take a while...
15 days ago•••
44 tasks on the milestone to go, 44 tasks on the milestone, If I spend all day rewriting your code, There'll still be 44 tasks on the milestone.
Feeling grumpy. Looks like release will be late. Grrr....
15 days ago•••
are you talking to someone specifically?
14 days ago•••
No. No. Definitely not. 😂
16 days ago•••
Here are the very draft interpreter and BIPs for Script Restoration. I'm seeking comments (looking at nprofile1qqsdnpcgf3yrjz3fpawj5drq8tny74gn0kd54l7wmrqw4cpsav3z5fgpz4mhxue69uhk2er9dchxummnw3ezumrpdejqz9rhwden5te0wfjkccte9ejxzmt4wvhxjmcprpmhxue69uhhyetvv9ujuumwdae8gtnnda3kjctvl3x2lg and nprofile1qqs2nep2pjnwfvfqszytdzj06eq8fqd3yps0j9dqlm95ezr524lrwjgpr4mhxue69uhkummnw3ez6ur4vgh8wetvd3hhyer9wghxuet5qyt8wumn8ghj7un9d3shjtnwdaehgu3wvfskueqpz3mhxue69uhhyetvv9ujuerpd46hxtnfdunyshzy here!) on all aspects, including format and what opcodes make sense to combine into a single proposal.
There are definitely some tweaks we could make to costing (it bugs me that the formula for OP_MUL is not symmetric, for example!), but that part is pretty solid.
Once we have a single proposal that we think is well-specified, reasonable and useful, it'll be time to get coauthors (I have a day job, and it's not this!) and formally propose it for broader scrutiny.
And interpreter (not other parts, so not actually usable except bench and test!):
16 days ago•••
Sorry but it's a waste of time.
16 days ago•••
Why?
16 days ago•••
1. It is harder to review, test and get consensus on all the opcodes that are part of this proposal.
2. They can be used to build undesirable things.
16 days ago•••
1. We had them before. Sure, we have to do them properly (not just call out to openssl) but none are particularly complex.
2. People can do undesirable things with their own UTXOs. This is a difficult truth, but fundamentally what Bitcoin was created for.
16 days ago•••
I don't think bitcoin was created for on-chain AMMs.
15 days ago•••
Programmable money was meant to allow you to specify arbitrary things on your funds in a way that was binding.
I'm struggling to find Satoshi's statement on systems which can't be interfered with "no matter how good the intentions", but it applies here. I suggest you take some solace in the trade-off: that while you can't stop people from doing bad things, bad people can't stop you from doing good things, either!
15 days ago•••
I think we disrespected and ignored satoshi when all the funding, efforts etc. went to fedimint, cashu etc.
Not just satoshi but all the people who discussed ecash without trusted third parties before bitcoin on mailing lists. We are just slaves for investors at this moment and there are very few transactions settling payments on bitcoin.
It's a speculative asset that everyone enjoys when price goes up and not the same as when I started researching bitcoin in 2015.
I can assure you all the conferences in US do not affect normal people in this part of world. Asia still prefers other things for payments and I don't know who are you scaling for.
15 days ago•••
I can see this upsets you, and I share some of your concerns about the price distraction.
But my response has always been to continue to do engineering the best I can. I'm my experience, it's the only way I can move the needle (and even then, no guarantees!)
🧡
15 days ago
15 days ago•••
Dropped a few comments while traveling. Putting this on my stack to give a more thorough read and feedback this week! Very excited to see your progress on this. Thanks for the work!
🧡
16 days ago
16 days ago•••
thank you for doing this
15 days ago•••
Awesome!
20 days ago•••
The then status of TXHASH. Tbh not much has changed until now. But intention is to keep moving on the project again soon!
19 days ago•••
I, too, am doing conference-presentation-driven development!
🧡
15 days ago
18 days ago•••
😅 It's sad but it's true. I heard you say you'd try do cln and tgsr 50/50, that not working out then?
16 days ago•••
I forgot the 50% managing my team and 50% with lightning spec work!
LOAD OLDER THREADS