disclaimer: I haven't followed the MuSig work nor do I live on chat channels where this stuff is actively discussed.
It would be nice to see some kind of explanation for core's outright rejection of ed25519 / curve25519 for aggregated signatures.
The guys at Evernym had a solid looking proposal for BIP32-Ed25519 which I never really saw counter-analysis for, much less from core. I'm not a cryptographer, but it seems that their effort to maintain ed25519 compatibility in their scheme would also maintain HD wallet compatibility with aggregated signatures.
The unsettling kick to Bitcoin's nuts is that there are effectively no active counter-proposals for an ed25519 backed implementation of threshold signatures. Given that Segwit is only at 40% adoption, this latest techno-wonder from blockstream feels like 2015 all over again.
I think he's trying to boast about how Schnorr, which BCH will be launching soon, and all developments related to it are primarily owed to the efforts Blockstream/Core. I personally think Core's repudiation of things that were Not Invented Here (NIH) is a big flaw in their development style, so I think it's a good thing BCH repudiates Core's NIH-syndrome.
> Even with a perfect library implementation, there are too many mistakes hardware wallet vendors can make.
(Hardware) wallet vendors already [can and do make mistakes](https://bitcoin.stackexchange.com/questions/83559/what-is-the-origin-of-insecure-64-bit-nonces-in-signatures-in-the-bitcoin-chain/) with ECDSA signatures.
The implementation efforts here aren't exclusive to designing misuse resistance interfaces that only defend against MuSig specific misuse, but which also cover issues that already exist in ECDSA land.
In particular, for hardware wallets I hope to see nonce-side-channel busting become a norm w/ the new signatures.
I thought that the nonces for ECDSA signatures can be deterministically derivated from the master private key and the transaction (though I didn't check), so I don't understand why a random generator is needed for that. This can't be done for MuSig as far as I understand from this blog post.
Is there anything better than Trezor but still practical enough that you can suggest for securely storing Bitcoin?
I went through the glacier protocol, but it was a real mess to do it in real life (it took hours just to be able to run linux on the cheap new laptop that I bought for that purpose, I needed to find out the parameters that I could pass to the Linux kernel for example).
I also tried multisig between different hardware wallets, but Trezor was the only one supporting showing the address on the hardware wallet for multisig signing.
Anyways thanks for all the work you're doing!
> Is there anything better than Trezor but still practical enough that you can suggest for securely storing Bitcoin?
**Most Secure and Most Private hot wallet** For Advanced Users.
Full Node + Hardware Wallet + Metal mnemonic Backup.
This is Typically done with Electrum Personal Server + Hardware wallet(Ledger or trezor) + Electrum
Other advanced multisig hardware wallet guides-
Testing different metal Backups -
As I wrote before, this doesn't help for using multiple different wallets, as Trezor is the only one that implements ,,Show address on device''.
I wanted to implement it for Ledger, but I found out that the developer Slack is closed, I opened Github issue, but got no answer.
It seemed to me that for Ledger adding altcoins is more important than securely storing money on the device... Trezor already did the UX work, they just had to copy it, but they didn't (I appreciate though that the code base is very different).
I think it's a real mess right now, unfortunately.
The existing HW wallets are an almost perfect supply chain target. They also all more or less force you into privacy destroying host software. (and, as you note, multisig isn't really usable with them). ... they still are probably more secure than a windows host, but that is a pretty low bar.
My preferred setup (off-line signer on a old laptop, using Bitcoin and PSBT) is not yet user friendly.
I hope within the next year we'll see nonce-sidechannel defended HW wallet support plus bitcoin core... and there will be a solution I could recommend to at least "ordinarily technical" users.
Probably as a side effect the "use an old laptop as a hardware wallet" path will also become a lot easier to use and would arguably be both a less costly and more secure (though less portable) option.
To mitigate hardware supply chain attacks, what do you think about multisig/musig using multiple devices?
EG, cold storage coins cannot be moved without 2/3 joint authorization from a Tezor, a Ledger, and an old (Purism) laptop or Blackberry?
Thanks, this sounds like a great direction!
One more thing that worries me regarding hardware wallets is that although the hardware wallet software mixes in the random seed that was generated by the computer, it doesn't prove to the computer that it is using the computer's seed as well to generate the master private key. It would be great if there was an easy way to prove it to the computer, but I believe the only secure way (not depending on the discrete logarithm problem) to do it would be to allow the user to reveal the original message that was hashed to create the master private key.
> to reveal the original message that was hashed to create the master private key.
Then user have to take this message and hash it independently to recreate xpriv and cross-check it with the addresses/xpubkey presented by hardware wallet ?
If there's another device involved to cross-check, the user can just re-create xprivkey from mnemonic on this device, and then cross-check with what hw wallet gives out
And btw, the compromized hw wallet may give out first few addresses derived from correct xpriv, but then switch to different xpriv. The host software should check with xpub (but can only do so for non-hardened derivation)
Hi u/my2sats, thanks for tipping u/xiphy **42** satoshis!
*[^(More info)](https://www.reddit.com/r/lntipbot/wiki/index) ^| [^(Balance)](https://www.reddit.com/message/compose/?to=lntipbot&subject=balance&message=!balance) ^| [^(Deposit)](https://www.reddit.com/message/compose/?to=lntipbot&subject=deposit&message=!deposit 10000) ^| [^(Withdraw)](https://www.reddit.com/message/compose/?to=lntipbot&subject=withdraw&message=!withdraw put_invoice_here) ^| ^(Something wrong? Have a question?) [^(Send me a message)](https://www.reddit.com/message/compose/?to=drmoore718)*
I'm already aware of MuSig protocol -- it's a paper they published a year ago. https://eprint.iacr.org/2018/068
Happy to see that they're getting the implementation merged in, finally! There are a number of technical intricacies having to do with avoiding nonce reuse attacks, and I like the "Session ID" approach they have taken. As described in OP's link it's not *perfect* but it's very hard to achieve perfection in this realm.
(BCH can use this too -- it's something purely on the wallet side; the nodes continue to verify the schnorr signatures the exact same way regardless.)
Well, they can do it quickly so why not.
I can't see it being a contentious addition on BTC (at least nothing like as contentious as Segwit) and is a relatively simple implementation. Why is it taking/going to take so long?
BitcoinXioModerator - Bitcoin is Freedom3 weeks ago
Maybe you should find out their [legal council [sic] and sue them](https://www.reddit.com/r/btc/comments/ahu9zo/please_send_me_the_contact_information_for_your/). Shouldn’t be too hard since [you’re working with](https://coingeek.com/former-blockstream-cto-gregory-maxwell-sees-light/) the scammer Craig Wright who also likes to sue others.
He denied it [here](https://bitcointalk.org/index.php?topic=5065996.0)
>lol what. Craig Wright and Roger Ver are both conmen. Coingeek is a conman shilling platform, and their claim that [I have] "come to the realization that Bitcoin SV is the real Bitcoin," is malicious whole cloth fabrication. Now, Is "Bitcoin SV" the real fake bitcoin (bch)? Maybe but who cares.
>I think it's unfortunate that Wright's over the top mania is causing dissension in his bamboozled army, as having a scam run by an obvious scammer is a win-win... but it seems that there is nothing to be done for it now, the psychosis is just too strong now.
Feel free to show us the evidence to the contrary. And I don't care if he technically emailed him. He could have emailed him to say "Screw you." I want evidence that he sent a letter of surrender complete with the moustache twirling, monocle cleaning sort of language that was in that coingeek tripe.
>Offering assistance can mean a lot of things. It can even be used as an under-handed insult. Is Greg "working with CW"? I highly doubt that. Let's keep things in perspective.
I'm sorry, did you even read the email? He was offering "his discreet assistance" to help CSW maintain his influence in BCH and even in earnest suggested some avenues that might prove more fruitful for Craig's shills than the ones he was pursuing.
>He was offering "his discreet assistance" to help CSW maintain his influence in BCH and even in earnest suggested some avenues that might prove more fruitful for Craig's shills than the ones he was pursuing.
Show me the email?
I believe it's just SegWit version bumb, no need to "vote" it in. Current SegWit implementatios should skip verifying unknown (new) SegWit version transactions in backwards compatible way, as pre-segwit implementations evaluate SegWit pubScript to True also. But I might be missing something, please correct me if I'm wrong.