Transitive dependencies are a nightmare most wallet developers prefer not to think about. While systems like mobile phones have very good separation of apps - one app cannot see what the other app is doing - same is not true for libraries. A library that lets you more conveniently process your data in your app could do all sorts of other stuff while at it. Like search for private keys in the app's memory and send them to a server if the app using the library has internet access. This is precisely what happened in an attack against a bitcoin wallet[1].
I had this long blog post[2] for some days open in a browser tab before I finally had Claude summarize it for me. It basically suggest to take the same precaution for library function calls as we already take for "apps" or processes in general. As it turns out there are several projects doing this already. Google Sandboxed API [3] and RLBox [4] for example.
At the Mycelium Android Wallet team I had led an effort to also isolate signing functionality from the main app through a separately installed app but it was discontinued for being impractical. It was probably my fault for not overcoming the engineering hurdles fast enough as it still appears to be the only way to well isolate key material from all the other fancy stuff wallet providers want to integrate for their business partners. Or do others know tools I don't know?
[3] https://developers.google.com/code-sandboxing/sandboxed-api
One way is to whitelist all domains that the app can make network requests to. That way a malicious library won't be able to send the payload to itself unless it compromises your servers as well.
Namecheap has BTCPay as the first option before BitPay. They do not require any info and just show a QR code.
$EXOD is trading on NYSE.
Congratulations
Because you can then buy Bitcoin with it.
I'm deficient in #2. Any good recommendations that are low on time commitment?
Is the other tom brady?
https://protos.com/you-can-now-mine-rather-than-inscribe-a-square-bitcoin-block-image/ But looking at it, mempool might have changed something?
Neat! You have to add audit=false
Oooh link?
Read the OP_RETURNS. It was the mining pool itself that paid for it by forgoing the fees it could have earned in the mempool. Some 0.018 BTC that was awarded the next block.
There are folks working on SP for BDK already, you can see some of the required steps for a full impl in this tracking issue:
https://github.com/bitcoindevkit/bdk/issues/1114#issuecomment-2286966409
And checkout some early related work here:
Just going to leave this here https://github.com/bitcoin/bips/pull/1687
P2A yes, but op_returns I think should count as a "transaction". They could represent a "payment" in some way. It could be one op_return and change.
I think outputs per block would be an interesting metric to track as well. A lot of the transactions could be large batch payments.
Canadians have their Thanksgiving second week of October. Got my Christmas lights up already.
Try with https://github.com/bitcoin/bitcoin/pull/31132 :).