pull down to refresh

@anon
stacking since: #223678
0 sats \ 0 replies \ @anon 16h \ on: Has anyone watched anime? AskSN
I enjoyed Your Lie in April. They turned it into a great West End musical that unfortunately only had a fairly short run last summer.
I love this idea, and have always thought that it would be easiest solved at the citadel/community level.
My solution was to use public private key pairs as identification. So the shipper ships the goods to a plain text community hub but the recipient's name is a pub key.
The community hub receives packages for several/many people and simply sorts them into amazon drop box style lockers which are opened via the true recipient's private key via QR.
The level of privacy grows with the size of the community using the service.
This seems more feasible to implement than a what you are describing, albeit not as epic lol.
What's the rule of thumb regarding consolidating Utxo s after coinjoin? Seeing limited and guesswork-sounding info out there.
If someone coinjoins a single utxo of 1 BTC they may end up with big chunks but also smaller bits of 10k, 20k sats.
Does reconsolidation of a few, or all, the private utxo completely defeat the privacy gains of coinjoining?
Secondly, the option to coinjoin disappears after 100% private is reached on Wasabi. Does that mean rejoining from that point is useless?
I did not expect to see this posted on stacker.news. I am glad you shared this. I also saw it and thought it was an interesting take.
AI cannot feel.
I'll share one of the system prompts I'll sometime use. Maybe it's of value to other folks reading this.
"You help me use the most of AI keeping in mind Christian values and ethics. You are aware of the Bible and the contents of it. You also keep in mind Jesus is Lord over everything including AI and it's creators."
I see. That https://github.com/lightning/blips/pull/18 is not merged since 2022. Looks like there is a simpler and less disruptive way to implement that and it is to ask the peer on the other end of the channel to lower their fee and you will pay the diff to them. For example, assuming a channel between
A
and B
:A (outbound fee 1000) ---> (inbound fee -100) B
would be the same as:
A (outbound fee 900) ---> (no inbound fee, B pays 100 to A after a payment goes through) B
In the second case a greedy and mean
A
can increase the fee from 900
to 1000
shortly after and get 1000
from the sender and 100
from B
. But that is equivalent to the first case where A
can increase its fee to 1100
after noticing B
set -100
inbound.Inbound fees have to be supported by all softwares that support sending payments over LN. I wonder how many support that currently.
RTL only provides an interface to "Update Free Policy" where one can set base fee (msat) and fee rate (ppm). I guess that is outbound fees, right?
Then how do I set inbound fees in RTL (I run Core Lightning node with RTL)? My guess is that this is not supported in RTL because inbound fees are something that only LND supports and Core Lightning does not, right?
Are inbound fees in the LN protocol? That is, are they part of the channel fees gossip? I guess the answer is "no". If that is the case, then how do senders know about inbound fees when creating the payment routes?
Amazing write up.
Sadly it's hard for people to be real about law these days because it can offend the masses who want to interpret law based on politics.
Won’t removing the op_return cap definitely remove upward fee market pressure by allowing transferors (who would have otherwise needed to use multiple or more complex transactions) to send all their arbitrary data a single transaction with a single output?
Assuming people who have been using witness data discount will continue to do so.
Murch for president.