Search content
Sort by
Showing 18 of 18 results by 1440000bytes
⭐ Merited by vapourminer (2)
Currently, in a 3-of-5 wallet, all 5 keys are treated as equals. While this may be fine for a majority of uses, it might not be best for all.
Lets assume there are 5 users (alice, bob, carol, david and eva). You can create a 3-of-5 multisig using miniscript in which alice and bob should be a part of 3 users that sign the spending transaction. The third signer could be anyone among the remaining.
It was possible to test miniscript and visually see different policies using bdk playground but it doesn't exit anymore.
⭐ Merited by vapourminer (2)
There is no Wiki about that and no post explaining:
That's not true, see https://en.bitcoinwiki.org/wiki/Running_Bitcoind
%b gets replaced by the block hash if transaction is confirmed or 'unconfirmed' as long as the transaction is still in the mempool waiting to be confirmed.
%h gets replaced by the block height or -1 if not yet confirmed.
Correct link: https://bitcoinwiki.org/wiki/running-bitcoin
Re: New ashigaru whirlpool coordinator can de-anonymize users
How much do you make from coordinator fee?
Re: New ashigaru whirlpool coordinator can de-anonymize users
Lucas has shared another method that can be used by the coordinator to link inputs and outputs:: https://njump.me/nevent1qqsqqqpslx5y7asqkckk92d2vfcat535t5r5k4pt7xy0ynmcepd4lcgpz4mhxue69uhkummnw3ezummcw3ezuer9wchsygy7xr55qguvm847h33js9md6ngsnqfp99zz72nv8pe8l3n05l4fpgpsgqqqqqqsqg4s4v
The coordinator can use different mixid for each input. At this point it wouldn't be wrong to say that zerolink protocol (as implemented in whirlpool) has multiple vulnerabilities that could be exploited by the coordinator. I do not expect Ashigaru team or the delusional cult to ever acknowledge and fix these vulnerabilities.
Code:
String mixId = confirmInputMixStatusNotification.mixId;
this.bordereau = ClientUtils.generateBordereau();
String blindedBordereau64 =
WhirlpoolProtocol.encodeBytes(
clientCryptoService.blind(this.bordereau, blindingParams));
String userHash = premixHandler.computeUserHash(mixId);
ConfirmInputRequest confirmInputRequest =
new ConfirmInputRequest(mixId, blindedBordereau64, userHash);
this.bordereau = ClientUtils.generateBordereau();
String blindedBordereau64 =
WhirlpoolProtocol.encodeBytes(
clientCryptoService.blind(this.bordereau, blindingParams));
String userHash = premixHandler.computeUserHash(mixId);
ConfirmInputRequest confirmInputRequest =
new ConfirmInputRequest(mixId, blindedBordereau64, userHash);
The coordinator can use different mixid for each input. At this point it wouldn't be wrong to say that zerolink protocol (as implemented in whirlpool) has multiple vulnerabilities that could be exploited by the coordinator. I do not expect Ashigaru team or the delusional cult to ever acknowledge and fix these vulnerabilities.
Re: New ashigaru whirlpool coordinator can de-anonymize users
⭐ Merited by vapourminer (2)
They specifically mention this in their update. And there seems to be a coordinated effort across all platforms by the Wasabi fans to just pump FUD. It’s becoming very cultish.
Maybe you should’ve done your testing before making the post. You make a conclusion in your title that has not yet been tested.
Maybe you should’ve done your testing before making the post. You make a conclusion in your title that has not yet been tested.
I am not associated with Wasabi. This is a free review and testing unlike others who trust the anonymous developers or not competent enough to review. Denying the bugs based on an announcement to use suboptimal tools sounds cultish.
The conclusion is still the same. Too many red flags to trust this coordinator and everyone should do their own research before wasting money in coordinator fees.
Re: New ashigaru whirlpool coordinator can de-anonymize users
- The coordinator can link input-outputs even with the hardcoded key
The client doesn't verify that the unblinded signature is actually a valid RSA signature for the hardcoded public key. The coordinator can still do tagging and link inputs-outputs after output registration.
- A new DoS vector is introduced in the code
If you confirm an input getting a blind sig, and then just time out, you can later use the same unblinded sig in a subsequent session and register an additional output which is a DoS issue.
[/list]
Related tweets by nothingmuch: https://xcancel.com/not_nothingmuch/status/1937176085461930033
Re: New ashigaru whirlpool coordinator can de-anonymize users
It seems they aren't using code from whirlpool-client repository in the terminal. Instead hardcoded a public key for signing:
-----BEGIN PUBLIC KEY-----
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAp5iSNzsR0S77fby4CFkG
OHF2oKNKsAYyK8e8SEwQrqmheYHF2t3mRAoYa0iN1OUXqhl3AkN5pOZQxJosIUFL
GR2tVNtYFv0ehzxUwYWBTIFNblNysccayBlFwQMuZaCa7/Cz/MGuemmn9/tBh1Vp
7CxfYRYVXHlSe08cYImtVg6dtrcarw/rm24ke1siUxLnrM6/LbgCWfvR6SKTZ7Zm
Ox5pi0TRTkcL1dJli5QDkUA6sLFUxmvG03rZLJ61LFFqm495VLsRCHVT5jDHz5aK
Xljk9Hhe2II9iHiy3GRy+01w1ZvPZ6Am2mO1usgAu1J5Zilnt0ahxLEQB2wRnXTP
UQIDAQAB
-----END PUBLIC KEY-----
// use receiveAddress as bordereau. keep it private, but transmit blindedBordereau
// clear receiveAddress will be provided with unblindedSignedBordereau by connecting with
// another identity for REGISTER_OUTPUT
final RSAKeyParameters rsaPublicKey;
byte[] publicKey = WhirlpoolProtocol.decodeBytes(confirmInputMixStatusNotification.publicKey64);
if (publicKey != null && publicKey.length > 0) {
throw new ProtocolException("not expected to receive public key for blind signature from whirlpool server");
//rsaPublicKey = ClientUtils.publicKeyUnserialize(publicKey);
} else {
rsaPublicKey = blindSignaturePublicKey;
}
this.blindingParams = clientCryptoService.computeBlindingParams(rsaPublicKey);
String mixId = confirmInputMixStatusNotification.mixId;
this.bordereau = ClientUtils.generateBordereau();
String blindedBordereau64 =
WhirlpoolProtocol.encodeBytes(
clientCryptoService.blind(this.bordereau, blindingParams));
String userHash = premixHandler.computeUserHash(mixId);
ConfirmInputRequest confirmInputRequest =
new ConfirmInputRequest(mixId, blindedBordereau64, userHash);
confirmedInput = true;
return confirmInputRequest;
}
This introduces other issues in the coinjoin process. I will add more details after doing some research and testing.
Code:
-----BEGIN PUBLIC KEY-----
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAp5iSNzsR0S77fby4CFkG
OHF2oKNKsAYyK8e8SEwQrqmheYHF2t3mRAoYa0iN1OUXqhl3AkN5pOZQxJosIUFL
GR2tVNtYFv0ehzxUwYWBTIFNblNysccayBlFwQMuZaCa7/Cz/MGuemmn9/tBh1Vp
7CxfYRYVXHlSe08cYImtVg6dtrcarw/rm24ke1siUxLnrM6/LbgCWfvR6SKTZ7Zm
Ox5pi0TRTkcL1dJli5QDkUA6sLFUxmvG03rZLJ61LFFqm495VLsRCHVT5jDHz5aK
Xljk9Hhe2II9iHiy3GRy+01w1ZvPZ6Am2mO1usgAu1J5Zilnt0ahxLEQB2wRnXTP
UQIDAQAB
-----END PUBLIC KEY-----
Code:
// use receiveAddress as bordereau. keep it private, but transmit blindedBordereau
// clear receiveAddress will be provided with unblindedSignedBordereau by connecting with
// another identity for REGISTER_OUTPUT
final RSAKeyParameters rsaPublicKey;
byte[] publicKey = WhirlpoolProtocol.decodeBytes(confirmInputMixStatusNotification.publicKey64);
if (publicKey != null && publicKey.length > 0) {
throw new ProtocolException("not expected to receive public key for blind signature from whirlpool server");
//rsaPublicKey = ClientUtils.publicKeyUnserialize(publicKey);
} else {
rsaPublicKey = blindSignaturePublicKey;
}
this.blindingParams = clientCryptoService.computeBlindingParams(rsaPublicKey);
String mixId = confirmInputMixStatusNotification.mixId;
this.bordereau = ClientUtils.generateBordereau();
String blindedBordereau64 =
WhirlpoolProtocol.encodeBytes(
clientCryptoService.blind(this.bordereau, blindingParams));
String userHash = premixHandler.computeUserHash(mixId);
ConfirmInputRequest confirmInputRequest =
new ConfirmInputRequest(mixId, blindedBordereau64, userHash);
confirmedInput = true;
return confirmInputRequest;
}
This introduces other issues in the coinjoin process. I will add more details after doing some research and testing.
New ashigaru whirlpool coordinator can de-anonymize users
⭐ Merited by LoyceV (12) ,NotATether (6) ,cAPSLOCK (5) ,d5000 (5) ,theymos (2) ,DireWolfM14 (1) ,ABCbits (1)
Ashigaru announcement: https://ashigaru.rs/news/announcement-whirlpool/
https://i.ibb.co/Q7G2rDBr/rsa.png
Background: Nothingmuch had reported a vulnerability in whirlpool in December 2024: https://groups.google.com/g/bitcoindev/c/CbfbEGozG7c/m/w2B-RRdUCQAJ
This allows a malicious coordinator to link inputs and outputs by providing each input with a unique RSA public key. Since the unblinded signatures are made by different keys, the server can learn the mapping from inputs to outputs.
The blind signing process requires a server or coordinator to share the public key. The highlighted text in the announcement is misleading. I looked at the code in [Whirlpool-Client](http://ashicodepbnpvslzsl2bz7l2pwrjvajgumgac423pp3y2deprbnzz7id.onion/Ashigaru/Ashigaru-Whirlpool-Client) and [Whirlpool-Server](http://ashicodepbnpvslzsl2bz7l2pwrjvajgumgac423pp3y2deprbnzz7id.onion/Ashigaru/Ashigaru-Whirlpool-Server) and found that the vulnerability is not fixed.
// generate a secret bordereau. keep it private and register INPUT with blindedBordereau
// bordereau will be provided with unblindedSignedBordereau to register POSTMIX with another
// identity
this.bordereau = ClientUtils.generateBordereau();
byte[] publicKey = WhirlpoolProtocol.decodeBytes(confirmInputMixStatusNotification.publicKey64);
RSAKeyParameters serverPublicKey = ClientUtils.publicKeyUnserialize(publicKey);
this.blindingParams = clientCryptoService.computeBlindingParams(serverPublicKey);
String mixId = confirmInputMixStatusNotification.mixId;
String blindedBordereau64 =
WhirlpoolProtocol.encodeBytes(clientCryptoService.blind(bordereau, blindingParams));
String userHash = premixHandler.computeUserHash(mixId);
ConfirmInputRequest confirmInputRequest =
new ConfirmInputRequest(mixId, blindedBordereau64, userHash);
confirmedInput = true;
return confirmInputRequest;
}
http://ashicodepbnpvslzsl2bz7l2pwrjvajgumgac423pp3y2deprbnzz7id.onion/Ashigaru/Ashigaru-Whirlpool-Client/src/commit/a64bd8b4e0ee8a4cfab03da4565f166d07caa7ec/src/main/java/com/samourai/whirlpool/client/mix/MixProcess.java
// register confirming input
String publicKey64 = WhirlpoolProtocol.encodeBytes(mix.getPublicKey());
ConfirmInputMixStatusNotification confirmInputMixStatusNotification =
new ConfirmInputMixStatusNotification(mix.getMixId(), publicKey64);
mix.registerConfirmingInput(registeredInput);
http://ashicodepbnpvslzsl2bz7l2pwrjvajgumgac423pp3y2deprbnzz7id.onion/Ashigaru/Ashigaru-Whirlpool-Server/src/branch/main/src/main/java/com/samourai/whirlpool/server/services/MixService.java
Conclusion: Users should not trust this centralized coordinator and do their own research before paying 5% coordinator fees.
https://i.ibb.co/Q7G2rDBr/rsa.png
Background: Nothingmuch had reported a vulnerability in whirlpool in December 2024: https://groups.google.com/g/bitcoindev/c/CbfbEGozG7c/m/w2B-RRdUCQAJ
This allows a malicious coordinator to link inputs and outputs by providing each input with a unique RSA public key. Since the unblinded signatures are made by different keys, the server can learn the mapping from inputs to outputs.
The blind signing process requires a server or coordinator to share the public key. The highlighted text in the announcement is misleading. I looked at the code in [Whirlpool-Client](http://ashicodepbnpvslzsl2bz7l2pwrjvajgumgac423pp3y2deprbnzz7id.onion/Ashigaru/Ashigaru-Whirlpool-Client) and [Whirlpool-Server](http://ashicodepbnpvslzsl2bz7l2pwrjvajgumgac423pp3y2deprbnzz7id.onion/Ashigaru/Ashigaru-Whirlpool-Server) and found that the vulnerability is not fixed.
Code:
// generate a secret bordereau. keep it private and register INPUT with blindedBordereau
// bordereau will be provided with unblindedSignedBordereau to register POSTMIX with another
// identity
this.bordereau = ClientUtils.generateBordereau();
byte[] publicKey = WhirlpoolProtocol.decodeBytes(confirmInputMixStatusNotification.publicKey64);
RSAKeyParameters serverPublicKey = ClientUtils.publicKeyUnserialize(publicKey);
this.blindingParams = clientCryptoService.computeBlindingParams(serverPublicKey);
String mixId = confirmInputMixStatusNotification.mixId;
String blindedBordereau64 =
WhirlpoolProtocol.encodeBytes(clientCryptoService.blind(bordereau, blindingParams));
String userHash = premixHandler.computeUserHash(mixId);
ConfirmInputRequest confirmInputRequest =
new ConfirmInputRequest(mixId, blindedBordereau64, userHash);
confirmedInput = true;
return confirmInputRequest;
}
http://ashicodepbnpvslzsl2bz7l2pwrjvajgumgac423pp3y2deprbnzz7id.onion/Ashigaru/Ashigaru-Whirlpool-Client/src/commit/a64bd8b4e0ee8a4cfab03da4565f166d07caa7ec/src/main/java/com/samourai/whirlpool/client/mix/MixProcess.java
Code:
// register confirming input
String publicKey64 = WhirlpoolProtocol.encodeBytes(mix.getPublicKey());
ConfirmInputMixStatusNotification confirmInputMixStatusNotification =
new ConfirmInputMixStatusNotification(mix.getMixId(), publicKey64);
mix.registerConfirmingInput(registeredInput);
http://ashicodepbnpvslzsl2bz7l2pwrjvajgumgac423pp3y2deprbnzz7id.onion/Ashigaru/Ashigaru-Whirlpool-Server/src/branch/main/src/main/java/com/samourai/whirlpool/server/services/MixService.java
Conclusion: Users should not trust this centralized coordinator and do their own research before paying 5% coordinator fees.
It is possible to prove that you own a UTXO of certain amount without revealing UTXO details using one of these methods:
1. Anonymous usage tokens from curve trees
2. taproot-ringsig
3. OutputZero
1. Anonymous usage tokens from curve trees
2. taproot-ringsig
3. OutputZero
Without having looking into this, could any of it be implemented in a nice web interface where people can request proof of funds of your company and then you get back the results showing the BTC is indeed there, or you need to do some convoluted things? Since this is aimed for the general public to check funds of a company, not to generate your own cryptographic proof only, it has to be well presented to the average joe.
[/quote]
Yes it is possible.
Related IRC conversation: https://bitcoin-irc.chaincode.com/bitcoin-core-dev/2025-05-08#1119190;
Quote
17:00 <Murch[m]> Next testnet reset should have a substantial premine for any dev that signs up in advance to get one
17:00 <Murch[m]> That should make it easier to get coins to anyone that needs them and provide ample coin to sell into any exchanges that might start trading it
17:01 <Murch[m]> Like maybe 1'000'000 coins per party that wants any
17:15 <_aj_> 10.5M coins divided by how many people sign up, and block reward halves every 105k blocks would make the maths easier maybe
17:16 <laanwj> dzxzg: a fun idea but i'm afraid giving them unique colors will only encourage people to collect them all
17:28 <laanwj> Murch: yes you'd say if the premine is that large it will discourage people from trading them for real money, on the other hand, crypto people...
17:31 <Murch[m]> Given that Testnet 4 was immediately monopolized and traded after launch, it seems like another thing that could be tried
17:32 <Murch[m]> Giving out half the coins in advance and halving the reward schedule like _aj_ suggests sounds good
17:00 <Murch[m]> That should make it easier to get coins to anyone that needs them and provide ample coin to sell into any exchanges that might start trading it
17:01 <Murch[m]> Like maybe 1'000'000 coins per party that wants any
17:15 <_aj_> 10.5M coins divided by how many people sign up, and block reward halves every 105k blocks would make the maths easier maybe
17:16 <laanwj> dzxzg: a fun idea but i'm afraid giving them unique colors will only encourage people to collect them all
17:28 <laanwj> Murch: yes you'd say if the premine is that large it will discourage people from trading them for real money, on the other hand, crypto people...
17:31 <Murch[m]> Given that Testnet 4 was immediately monopolized and traded after launch, it seems like another thing that could be tried
17:32 <Murch[m]> Giving out half the coins in advance and halving the reward schedule like _aj_ suggests sounds good
⭐ Merited by stwenhao (1)
It is possible to prove that you own a UTXO of certain amount without revealing UTXO details using one of these methods:
1. Anonymous usage tokens from curve trees
2. taproot-ringsig
3. https://github.com/halseth/output-zero
1. Anonymous usage tokens from curve trees
2. taproot-ringsig
3. https://github.com/halseth/output-zero
Since it's megathread located on Bitcoin parent board, how about making list of some Bitcoin software or service which use Nostr? For example, https://joinstr.xyz/.
Thank you for mentioning joinstr
Agree. A list of bitcoin projects that use nostr would be more relevant on bitcointalk.
Secondly is there any possibility that a BIP get merged and isn't part of an upcoming Bitcoin Core release?
BIPs are just documents that describe improvement proposals. They don't need to get merged in a specific repository however there is a repository maintained for most BIPs. Every BIP is not created to be implemented in bitcoin core.
Is there an easy way to know whether a given BIP has been merged or whether its still in work?
Yes it's easy, just refer to Bitcoin GitHub Repository's doc directory.Link: https://github.com/bitcoin/bitcoin/blob/master/doc/bips.md
For the dates, most of the entries in the link above have notes on which version it's implemented, do a quick research of when those specific versions are released.
These are BIPs implemented in bitcoin core. Its not necessary that you will find all the BIPs in this list.
Re: Can Coinjoin transactions be traced? Busting Bitcoin privacy myths!
Bitcoin Optech: https://bitcoinops.org/en/newsletters/2024/12/13/#deanonymization-vulnerability-affecting-wasabi-and-related-software
Mailing list: https://groups.google.com/g/bitcoindev/c/CbfbEGozG7c/m/w2B-RRdUCQAJ
I think users should not trust your coordinator if you are still being dishonest and misleading about the vulnerabilities.
Mailing list: https://groups.google.com/g/bitcoindev/c/CbfbEGozG7c/m/w2B-RRdUCQAJ
I think users should not trust your coordinator if you are still being dishonest and misleading about the vulnerabilities.
The discloser and publisher did not respond to my comment, which I would expect if the accusations were made in good faith: https://x.com/Kruwed/status/1870559181486645687
I see that nothingmuch has replied to your tweets. I doubt you completely understand the issue and I would suggest you to do more research.
Re: Can Coinjoin transactions be traced? Busting Bitcoin privacy myths!
Wabisabi coordinators can link inputs with outputs and multiple inputs belonging to same user.
Vulnerability details: https://github.com/GingerPrivacy/GingerWallet/discussions/116
Related tweet thread: https://xcancel.com/not_nothingmuch/status/1866138694920344055
Vulnerability details: https://github.com/GingerPrivacy/GingerWallet/discussions/116
Related tweet thread: https://xcancel.com/not_nothingmuch/status/1866138694920344055
This describes a client level bug, not a protocol level vulnerability.
Bitcoin Optech: https://bitcoinops.org/en/newsletters/2024/12/13/#deanonymization-vulnerability-affecting-wasabi-and-related-software
Mailing list: https://groups.google.com/g/bitcoindev/c/CbfbEGozG7c/m/w2B-RRdUCQAJ
I think users should not trust your coordinator if you are still being dishonest and misleading about the vulnerabilities.
Re: Can Coinjoin transactions be traced? Busting Bitcoin privacy myths!
Wabisabi coordinators can link inputs with outputs and multiple inputs belonging to same user.
Vulnerability details: https://github.com/GingerPrivacy/GingerWallet/discussions/116
Related tweet thread: https://xcancel.com/not_nothingmuch/status/1866138694920344055
Vulnerability details: https://github.com/GingerPrivacy/GingerWallet/discussions/116
Related tweet thread: https://xcancel.com/not_nothingmuch/status/1866138694920344055
⭐ Merited by dkbit98 (1)
Sorry this plugin was never tested on Windows and not updated since months as I was busy with mobile apps for joinstr.
You could try this on Android: https://gitlab.com/invincible-privacy/joinstr-kmp/
Thanks for testing the plugin. I am looking for more contributors.
You could try this on Android: https://gitlab.com/invincible-privacy/joinstr-kmp/
Thanks for testing the plugin. I am looking for more contributors.