It's always cheaper to mutual close so it's only when you're going to close unilaterally. And at least this peer is very unlikely to open a channel with you again if you're a pratt. It's hard to quantify reputational damage though, to be fair.
nostr:npub1teawtzxh6y02cnp9jphxm2q8u6xxfx85nguwg6ftuksgjctvavvqnsgq5u Verifying My Public Key: "rusty_twit"
There are always many things you can do with your time, but implementing silent payments (https://github.com/bitcoin/bips/blob/master/bip-0352.mediawiki) for Core Lightning is rising in my to-do list.
Unfortunately, we are all PSBT internally, so we need support so we can receive, which the authors argue (sensibly) should be the first priority for wallets. There's a delving post on this, so I did my bit by annoying Ava Chow into looking at it. We can probably hack in some experimental thing if we need for now, but proper support on libwally would smooth the path for Blockstream Green in future, which frankly is a much bigger win than CLN support.
Looking forward to the day when they're not "silent payment addresses" but simply "Bitcoin addresses".
No, because the defense is now *also* much easier. Watchtowers are trivial, since they just spend the latest tx.
I was originally of the same mind as you, but this seems to be our direction anyway, since people want zero reserve for UX reasons...
Um so, I need a *third* nostr client?
If only nostr messages were authenticated somehow so I could send instructions to the site. Or y'know, send a one-time password to log in like humans do.
Everything I press seems to go to "Choose a login method" and then??? I have Amethyst on Android, Gossip on desktop...
One day I will reach the pinnacle of nostr technical capabilities, and be able to access my npub.cash funds. Right, nostr:npub12rv5lskctqxxs2c8rf2zlzc7xx3qpvzs3w4etgemauy9thegr43sf485vg?
I'm delighted to hear that!
There's an old proposal called "eltoo" (or, these days, called "ln-symmetry") where there's no penalty phase if one side accidentally publishes an old state: you just fix it up instead. This does some cool things:
1. No more risky backups, where you can lose all your funds by restoring an old backup.
2. You can now have more than 2 parties sharing a channel, and build on top of that.
3. We can reduce latency for payments in some cases, making it twice as fast.
4. It's generally simpler: you only need to remember the last state, as you can fixup and old ones
As to not knowing who I am, that's totally fair! I would much rather people evaluate a proposal on its merits, not the reputation of the proposer. As a non-expert, it can be impossible to distinguish someone who is good at their job, from someone who is good at self-promotion :(
That's the whole point, though? You said "use lightning" and I said "we needed a protocol change to do that".
To get here, we needed changes. To get to our full potential we need to continue. Obviously it depends on the specifics of the proposal, but I would urge you to keep an open mind.
I am who I am. My voice may well get drowned out by those who are louder, better resourced or more persuasive. But as an engineer working in this space, I need to tell the raw unfiltered truth as best I see it, and I hope others feel the same?
He explicitly argued that a miner who spends $1B on mining infra should not have their investment undermined by protocol changes. It was pretty concrete!
They would definitely argue that a protocol change which increased space efficiency would have a short-term effect on fee revenue, right? It seems a pretty clear-cut case where Saylor's model is directly against most people's understanding of what we should improve.
The balance shifts with fees. I think Lightning is the current obvious go-to as fees rise, and for Lightning 5 txs a month seems a *lot*, so I think that there is at least another order of magnitude here, before we get to shared UTXOs or similar mechanics...
For better it worse, the sophistication of scripting doesn't seem to matter: if you give $1M to the first non-coinbase tx in a block, eventually miners will write systems to take that money :(
If you write any protocol where you let miners choose the winner, you get this problem if the effect of winning is economically significant. Of course you shouldn't create protocols that stupid, but when there's a race to collect money from gullible people, engineering very much takes a back seat.
The real defence seems to be that economically useful actions on Bitcoin can outspend stupidity over the long term. I certainly hope this continues, and I suspect (though cannot prove!) enabling more people to use Bitcoin economically will further tip the balance in its favor.
Weirdly, there's a great deal of pressure *against* ambitious changes. You're signing up for a half-decade grind, whereas other changes have a much better risk-reward profile. There's a reason I've generally stayed out of Bitcoin development and stuck with Lightning, where life is easy:)
That is an amazing and inflammatory take, and why people do often avoid serious discussion on such topics :(
What changed, then? You would not have enabled lightning?
There is a change we want to make lightning simpler and more efficient as well as multi-party. It's not a complex change: in fact there are several ways we could do this. But I assure you that the reduced Script we have today does not allow " everything else... built on layers" :(
I agree. There are changes which could be done to squeeze more stuff into the existing blocks, but it's like a max 20% improvement.
Fundamentally, there's no point owning a UTXO smaller than the cost to spend it. Below that, some compromise is always necessary, such as:
1. UTXO shared with a group of friends/community.
2. Trust, but if they screw up/over they can't steal your funds, only burn them.
3. Trust, but if they fail it costs them far more than they gain.
4. Trust, but they can only try to rug *everyone*, not you specifically.
5. Trust, but you and your friends can combine to pay fees to get a UTXO like #1.
You can add reputation and anonymity in there, you can combine these options, you can play with the balance (e.g. size of bond required) but the minimum UTXO size seems to be a fundamental limit. And it's almost certainly one we will reach for many people.
This approach leads us to an increasingly complex and awkward scripting system, as we add more and more special cases which must be maintained forever.
If we can restore script as it was originally, as a general programming language, we don't have to try to "pick winners", and you don't have to ask permission to do what you want with your own UTXOs. Doing this safely and cleanly is my current area of research.
My favourite thing about this approach is that following soft forks become less about "is we had this new feature we could do X” and more "this would make existing scripts more efficient and allow us to do X% more in a block" which is a much more quantifiable assessment.
I certainly haven't felt his support of lightning, but perhaps I missed it? It seems like he very much would have opposed the changes which made it practical, and now he sounds opposed to changes which would make it more effective. Hard to tell, since the conversation was in analogies, not specifics though!
Indeed! But if I try to argue the analogy, I might say "Satoshi glued the ailerons into a fixed position as an emergency stabilization procedure and we've been flying like that ever since". But there's no evidence that any conclusions we you might draw from that are actually useful in real life!