pull down to refresh
The flat files at https://bitcoin.ninja/ln-replay-data/ probably contain what you need. They're read by https://git.bitcoin.ninja/?p=ln-routing-replay;a=tree;h=refs/heads/main;hb=refs/heads/main but should be easy to adapt.
Honestly, the podcast with Livera on the same topic was much, much better. https://stephanlivera.com/episode/719/
We've got some time, but the good news is there's people on it! eg see this great work by jonas nick https://delvingbitcoin.org/t/shrincs-324-byte-stateful-post-quantum-signatures-with-static-backups/2158 or the research report by chaincode https://chaincode.com/bitcoin-post-quantum.pdf
The BIP goes to great lengths to ensure you never need to type it! Wallets should automatically detect it either with or without the bitcoin symbol and should generally have a fixed UI element there that makes it clear to a payer they don't need to type it. See the bitcoin design guide page for more.
I wouldn't call Spark "shared custody", but the Spark operator is well-known - its Lightspark, they're not trying to hide that. Also, Lightspark's regulated money transmission business is separate from the Spark product, even though its from the same company.
They just announced a new change to the wallet that they're calling "self-custodial" (upgrading from the existing, fully custodial, wallet). The new one is really not "self-custodial", though its also better than a classic, fully custodial, wallet.
I woulnd't say it "becomes custodial" at some threshold (somewhat the opposite, it becomes less custodial after you have enough money to afford the fees), but I would say that every wallet under something like 5k sats is custodial - if you can't afford the fees to punish a counterparty for cheating in an L2, its not custodial.
Spark/the new WoS integration, is not really self-custodial at any threshold, but its also not custodial in the traditional sense (at least if you have enough money to exit).
Its much better than other custodial systems in terms of trust model, but, yea, don't put all that much more in it than you would any other custodial wallet. Of course if you put too little in it its very much not non-custodial cause you can't unilaterally exit/force close without a fairly high fee.
Yep, super simple and straightforward! Its mostly in response to the Samurai and Tornadocash cases, which charged exactly this (and drove Phoenix out of the US in response), fixing exactly the law they were charged with.
There's the Blanche Memo and favorable case law in the hopper.
The Blanche Memo can and will be reversed by the next administration. There is no case law here.
I'm not gonna bother engaging on the Block nonsense, if you think Block is evil, great, go read Coincenter's view on this, Bitcoin Policy Institute's view, CCI, or literally any other lawyer's take on this stuff.
Self-custodial wallets with decent UX require other tech - on-chain Bitcoin for regular transactions is unusably horrible. If you want Ark, Spark, Lightning, Rollups, or literally any of the things that make Bitcoin usable, you need someone (or many someones) to run nodes, sequencers, or many other things. Ensuring those things aren't made illegal in the US is important, no matter how much we pretend it isn't. If only so that developers can build them in the US, and people can run them outside the US later.
The new California bill, that can seize your bitcoin after it has been idle for 3 years and with no login, etc., gives enough alarm bells for me. Those rules will only be loosened in favor of the state, I assume.
This is inaccurate. The California bill actually ensures that the state wont sell your coins if you haven't logged into your custodial account in three years.
Except that (a) it works, and (b) if you want any devs building actual Bitcoin tech over the next few years, the law's gotta allow for that. No one is gonna risk going to jail to bring you free, open-source Bitcoin software, no matter how much you scream that they should.
What? So you think that we should remove regulations on Cash App and Coinbase (custodial wallets) and this is so important that we shouldn't try to get the (actually maybe achievable) outcome of making non-custodial wallets less regulated, and that somehow this is good for Block (the company behind Cash App, that generally drowns in regulations)? Enabling people to better build non-custodial wallets that outcompete Block's products is...good for Block? Okay man.
I hope we never expose users to the idea of options for LSPs and plans in the onboarding flow (maybe somewhere in the settings in an advanced panel or something) - onboarding has to look like "write down your seedword -> here's your invoice, you're ready to go!", anything more and we've lost the vast majority of users already (and even just writing your seedword loses lots of folks).
Most likely, wallets will simply partner with an LSP (or a few) and split some of the fees with the LSP. Users can pick a different wallet if they don't like the fee structure.
IMO If we ever expose a UI with that much detail to the user we've lost. That's wayyyyy too complicated for the vast majority of folks when they're just getting started (sure, in an advanced panel in settings, no problem).
The entire concept of a "channel" (let alone the duration of it or the size of it) should never be exposed to 99% of lightning users, and IMO the quicker people accept that the quicker LN will actually see some real users.
It looks like this has no concept of sybil resistance (ie Chainanalysis can just join and spam things and trivially de-anonymize everyone), it just picks a (few?) peers and CJs with them. Instead, you might want to take a look at JoinMarket, which has existed for quite some time and has reasonably good liquidity and sybil resistance in the form of fidelity bonds.
I would definitely agree with your point here, if it weren't for the wildcard option. While I think its a sad state of affairs that most devs don't know anything about how the DNS works (which is sad cause its wayyyy more simple than HTTP(s)), I agree that its often the case. That's the reason for the wildcard option! With it, large custodial services don't need to know much about DNS, they can add one wildcard record and handle the rest at the app layer. Anyone running a solo name resolver can similarly just add one record, so its all pretty easy.
I assume you saw what a, b, and c referred to :) They're pretty important properties.
You may be interested in reading the BIP draft at https://github.com/bitcoin/bips/pull/1551 specifically the section which lists the drawbacks for HTTP-based solutions. Further, note that a large custodial provider wishing to accept payments for many users only needs a single (wildcard) entry in the lightning case, so it shouldn’t be too hard to handle :)
As far as I understand, the rules apply to the direct stablecoin clients - ie those doing creations and redemptions, not anyone using the stablecoin to transact. IOW this use basically codifying the current state of affairs.