OrangeSurf's avatar
OrangeSurf
_@orange.surf
npub18h0w...ws8m
OrangeSurf's avatar
OrangeSurf 1 year ago
I want to use nostr more but it feels like I am shouting into the void, probably a skill issue
OrangeSurf's avatar
OrangeSurf 1 year ago
Which wallets have taproot multisig support?
OrangeSurf's avatar
OrangeSurf 1 year ago
In Biarritz / SurfinBitcoin? Want to talk about mempools, mining centralization, transaction acceleration? Drop me a dm 🌊
OrangeSurf's avatar
OrangeSurf 1 year ago
Miners use the default bitcoin core (fairly liberal) mempool policies and fee rate based selection algorithm because it’s low risk and the best alternatives are only marginally more profitable. If that changes I’d expect core defaults to change, or increasing divergence.
OrangeSurf's avatar
OrangeSurf 1 year ago
If you are a dev and want to learn more about mempool accelerator hit me up
OrangeSurf's avatar
OrangeSurf 1 year ago
I want to follow more devs, makers, builders. Please share some great people!
OrangeSurf's avatar
OrangeSurf 1 year ago
Panicked or ambivalent about nonce key exfiltration? Don’t be - Focus effort into adding anti-klepto to a new version of PSBT instead of taking shots at each other or dismissing concerns. What is the nonce key exfiltration attack? When signing a bitcoin transaction a number is used to generate the signature, this number is used once, and is therefore called the nonce. This should be a cryptographically secure random number, which is never reused. Suppose an attacker compromises your signing device, and can get it to use a particular nonce, rather than a random number. If they use part of your private key as the nonce, they can leak part of your private key out of your signing device with each transaction you sign and broadcast. If you make enough transactions, they can reconstruct your whole private key, and steal your bitcoin, just by watching the bitcoin transactions being made and decoding each part of the private key. They don't need to compromise your computer, or physically access your device, and all the while your signing device appears to be working correctly, up until all your bitcoin is stolen. There have recently been two new papers expanding on this attack. - Dark Skippy by Lloyd Fournier, Nick Farrow of FrostsnapTech and Robin Linus of ZeroSync and BitVM. - Engineering a backdoored bitcoin wallet by Adam Scott and Sean Andersen at block I think it's great that these researchers have raised attention to this previously known attack vector. Now, there are two types of reaction in my x feed on this issue, panic and ambivalence. ⚠️ Reaction 1 - Panicked Nonce key exfil would enable theft at a distance, on all devices that update to malicious firmware & make 12 transactions. The attack doesn't require compromising the online device the signer talks to. The attack is not mitigated on most signing devices, and therefore large amounts of bitcoin are potentially vulnerable. The attack would be undetectable until the thieving begins 🤷‍♂️ Reaction 2 - Ambivalent This attack requires getting malicious firmware onto a device. Competent signing device firmware devs secure firmware signing key(s) appropriately. Provided the firmware signing keys are not compromised this attack is mitigated because most signing devices check new firmware signatures before upgrading. Malicious firmware would enable many other attacks like generation of compromised wallets or exfiltration of keys in other ways (via screen, microSD or USB). I think both Panic and Ambivalence are extreme. ❌ Panicked - Most hardware wallets verify firmware signatures so this attack requires either malicious firmware or a compromised firmware signing key / build pipeline and for many transactions to be signed with that firmware. Anti-klepto requires the online wallet to participate and adoption is limited. Creating panic leads uninformed users to rush to move their bitcoin to a new setup and this is when mistakes happen. ❌ Ambivalent - This attack is particularly nefarious because it can be done at a distance without needing to compromise any other user devices which makes it very scalable. If any firmware release is compromised all devices that run that version will be compromised. How secure is your signing key? How secure is your build pipeline? If anti-klepto was widely supported you would probably use it, so let's get it widely supported. 💡 Constructive - Focus effort into adding anti-klepto to a new version of PSBT instead of taking shots at each other or dismissing concerns.
OrangeSurf's avatar
OrangeSurf 1 year ago
What is the nonce key exfiltration attack? When signing a bitcoin transaction a number is used to generate the signature, this number is used once, and is therefore called the nonce. This should be a cryptographically secure random number, which is never reused. Suppose an attacker compromises your signing device, and can get it to use a particular nonce, rather than a random number. If they use part of your private key as the nonce, they can leak part of your private key out of your signing device with each transaction you sign and broadcast. If you make enough transactions, they can reconstruct your whole private key, and steal your bitcoin, just by watching the bitcoin transactions being made and decoding each part of the private key. They don't need to compromise your computer, or physically access your device, and all the while your signing device appears to be working correctly, up until all your bitcoin is stolen. There have recently been two new papers expanding on this attack. - Dark Skippy by Lloyd Fournier, Nick Farrow of FrostsnapTech and Robin Linus of ZeroSync and BitVM. - Engineering a backdoored bitcoin wallet by Adam Scott and Sean Andersen at block I think it's great that these researchers have raised attention to this previously known attack vector. Now, there are two types of reaction in my x feed on this issue, panic and ambivalence. ⚠️ Reaction 1 - Panicked Nonce key exfil would enable theft at a distance, on all devices that update to malicious firmware & make 12 transactions. The attack doesn't require compromising the online device the signer talks to. The attack is not mitigated on most signing devices, and therefore large amounts of bitcoin are potentially vulnerable. The attack would be undetectable until the thieving begins 🤷‍♂️ Reaction 2 - Ambivalent This attack requires getting malicious firmware onto a device. Competent signing device firmware devs secure firmware signing key(s) appropriately. Provided the firmware signing keys are not compromised this attack is mitigated because most signing devices check new firmware signatures before upgrading. Malicious firmware would enable many other attacks like generation of compromised wallets or exfiltration of keys in other ways (via screen, microSD or USB). I think both Panic and Ambivalence are extreme. ❌ Panicked - Most hardware wallets verify firmware signatures so this attack requires either malicious firmware or a compromised firmware signing key / build pipeline and for many transactions to be signed with that firmware. Anti-klepto requires the online wallet to participate and adoption is limited. Creating panic leads uninformed users to rush to move their bitcoin to a new setup and this is when mistakes happen. ❌ Ambivalent - This attack is particularly nefarious because it can be done at a distance without needing to compromise any other user devices which makes it very scalable. If any firmware release is compromised all devices that run that version will be compromised. How secure is your signing key? How secure is your build pipeline? If anti-klepto was widely supported you would probably use it, so let's get it widely supported. 💡 Constructive - Focus effort into adding anti-klepto to a new version of PSBT instead of taking shots at each other or dismissing concerns.
OrangeSurf's avatar
OrangeSurf 1 year ago
Using the public @mempool accelerator API you can now fetch a lightning invoice to boost any transaction. Integrate into your app / service today.
OrangeSurf's avatar
OrangeSurf 1 year ago
Replace By Fee (RBF) The sender in an unconfirmed transaction creates a new, higher fee transaction spending some of the same inputs as the transaction being replaced. Often the new transaction will be confirmed instead of the original transaction. Child Pays for Parent (CPFP) 
The recipient in an unconfirmed transaction spends their unconfirmed transaction output, increasing the effective fee of the original transaction. A miner can't confirm the new (child) transaction without also confirming the original (parent) transaction.
OrangeSurf's avatar
OrangeSurf 1 year ago
Am I alone in preferring mobile wallets that do one thing well? I would happily have at least 7 wallets - Managing Lightning Channels - Making Lightning Payments - Receiving Lightning Payments - Making Onchain Payments - Generating invoices to cold storage - Generating invoices to a hot wallet - Receiving Silent Payments
OrangeSurf's avatar
OrangeSurf 1 year ago
Ideally you would run multiple bitcoin core nodes of differing versions and your wallet would connect to all and report discrepancies. Update to the latest release AND run tried and tested versions. Who is building this?
↑