pull down to refresh
0 sats \ 0 replies \ @denationalized OP 21 Feb \ parent \ on: How do I stop my lightning node from propagating USDT and other taproot assets? mempool
I see. In order to transact with those assets on lightning one would need to have an LND node plus some software. But taproot assets can also be sent onchain.]
I would like to know if there is way to apply filter to transactions both issuing and moving them onchain.
Still don’t understand who has the utxo data if all nodes are pruned:)
Me neither ;) I guess it has something to do with their pruning points. Kaspa nodes store only the last 3 days of historical data and the UTXO set and the nodes do not rely on even one single archival to fully sync.
It gives a hint to Bitcoin: Do not abandon historic verifiability unless you have to offer much more than Kaspa.
obvious trade off is centralization due as only few people will be able to run their own nodes
There may be few of us running Kaspa nodes but as of now Kaspa's node takes 15GB on my PC. And its size is not going to grow linearly with the growth of historical transactions.
As a source for forks attempting to provide with anonymity on their layer one it is very promising indeed.
I even think custodial solutions are eventually fine for everyday purposes. I don't care if I have a few sats for groceries on a normal bank account in the future.
No. Bitcoin is not a P2P cash, although it was designed with this intent, if you need a custodian to transact with it.
Assuming the network of sequencers is the solution. L1 Bitcoin miners might as well perform citrea's sequencing and proving. Otherwise, what could be the mechanism of selecting a sequencer from the network of sequencers?
npub.cash is so minimalist that it cannot be even called a wallet. One can receive LN only through and address. Receiving e-cash, not implemented. Sending lightning not implemented. Good solution for betting on https://www.bitcoinprediction.market , though.
How is that possible to pay a lightning invoice with nutshell and get Invoice paid Mint did not provide a preimage. as described in this issue: https://github.com/cashubtc/nutshell/issues/682
I though that lightning payments work like this: Upon the completion of the payment the recipient reveals the preimage to claim the funds.
How would you explain this behaviour of the wallet / mint ?
My is a non-routing one, and so fee are not a problem. My payments fail despite setting 3% fees. You are a third person here that says there is no problem with payments - but two of you are routing nodes. Perhaps the gag orders are not meant to destroy the LN but rather co-opt it and centralize it, so that it can be censored. Do you run your node as a company?
Lightning nodes are run by people, so people or algorithms set by people will decide what they do with their nodes / channels.
Yeah, people like the ones running Acinq who pulled out of the US earlier this year. Do you think they pulled out because the fees of their peers rather than due to the perception of a prospective threat from the law enforcement. I'm not blaming them, I'm just trying to figure out how to survive - I have had no fiat income / savings for several years..
The fact that you have your channel open doesn't mean the other party cannot disable the channel while not closing the channel.
And this other party may disable such channels because such is the gag order from above, from the law enforcement, or from some government agencies. I am afraid that this is going in the direction of whitelisting - hence my question in order to find out if other people observed similar issues. I don't feel comfortable with mobile devices, that's why I would not use lightning noncustodially. On the other hand, I tend to stay at home a lot in from of a Linux terminal, am comfortable with Bash and scripting. Hence Core Lightning felt like a natural choice. And for a couple of years it worked fine even for large amounts.