And how are you going to get your private keys from Trust wallet if you don't type your seed phrase in first, which you've just said you would never do? If I need to enter my seed phrase somewhere to derive my private keys, then 100% of the time I'm going to choose an open source and verifiable tool downloaded from GitHub and ran on an offline machine, such as Iancoleman, over a closed source and unverifiable tool downloaded from an app store, such as Trust wallet.

Iancoleman's site is perfectly legit and perfectly safe if used properly - downloaded, verified, and airgapped. The existence of a malicious version is not a reason not to use it, otherwise you shouldn't be using this forum, your browser, your OS, or pretty much any piece of software at all.

Marco Falke noted that in his pull request here: https://github.com/bitcoin/bitcoin/pull/26287. Full RBF has been discussed for years. It's pretty surprising that developers of projects which accept/depend on zero confirmation transactions are only learning about it now.

Lots more discussion on this pull request in the last couple of days, and now another new one from Andrew Chow - https://github.com/bitcoin/bitcoin/pull/26456.
This one removes the setting from 24.0 entirely simply to allow 24.0 to be released and to allow ongoing discussion regarding full RBF to happen, but even that seems to be contentious.

As noted in the mailing list discussion, this is the natural state of the system, and as the block subsidy falls and fees make up a larger and larger proportion of miners' income, then they are more and more likely to start accepting higher paying replacement transactions even if the original is opted out of RBF.

You don't do it per word - you do it per bit. 2 tosses per bit, and assuming a close to 50% rejection rate for a minimally biased coin, then you need on average 512 flips for a 128 bit number encoding a 12 word seed phrase.

Quicker, simpler, more secure, and provably unbiased, when compared to the bingo machine suggestion (or any other physical entropy suggestion, for that matter).

Challenge accepted.

So why use it at all, when you can use a von Neumann approach to flipping a coin to have a system which provably has zero bias? Not to mention simpler and quicker as well.

Obviously almost no one would actually do this, which means all your assumptions which follow of the bias being too small to make a difference are flawed. It you don't test what your bias is, then you have no idea if it is too small to make a difference.

Bisq will attempt to connect to your own node if you are running one, but will run perfectly well without a local node to connect to. You only need to run your own node if you want the additional security and verification that running your own node brings you. Otherwise you can use Bisq as an SPV wallet, connecting to other nodes on the network to receive the necessary data. You can also point it at a specific node, so you can install Bisq on your laptop and take it with you to do trades, while having it connected to your own node running at home.

More info here: https://bisq.wiki/Connecting_to_your_own_Bitcoin_node

dkbit98 brought this up in the other Wasabi thread a few months ago in regards to forking Wasabi to avoid its censorship, blacklisting, and surveillance: https://bitcointalk.org/index.php?topic=5405325.msg60551095#msg60551095

My response to your question now will be the same as it was to his - there is no point. We already have a better coinjoin implementation called JoinMarket as you point out, which can be used right now. It does not spy on its users, it does not support blockchain analysis, it is not pro-censorship, it is not reusing addresses. If a user (or group of users) have the requisite knowledge and skills to contribute to a coinjoin project, why would they take a fundamentally flawed project and spend their time mitigating these flaws, when instead they could choose to just contribute to and help develop a project without such flaws?

I don't think such a scenario is even worth entertaining, because it would be fundamentally ridiculous scenario to be in where you are having to restore your hardware wallet to a different device to double spend your own transaction to try to recover your coins. The fact that such a ridiculous scenario is even a possibility (since there is no screen on the hardware device so therefore no way to verify what you are actually signing before you sign it) should be enough to tell you that you don't want to to use this device.

I fail to see what advantages this screenless hardware devices has over a simple 2FA hardware key such as the YubiKey. With both you cannot send a transaction without it, and both are unable to provide the ability to independently verify your transaction prior to signing. The YubiKey will likely end up being significantly cheaper, though, as will all your transactions since they won't be 2-of-3 multi-sig. And of course with your own 2FA set up, you can back up your wallet properly using a seed phrase and not some crazy scheme based on a third party account and social contacts.

Did she get a glance at your browsing history?

I wouldn't use multi-sig for this at all. Instead I would use SIGHASH_ALL | SIGHASH_ANYONECANPAY.

Essentially, Alice creates a transaction which contains her 0.1 mBTC input and a 0.2 mBTC output to the society. She signs it with SIGHASH_ALL | SIGHASH_ANYONECANPAY. This signs her input and the output (meaning they cannot be changed), but allows the addition of further inputs (but not further outputs). She then passes this transaction to Bob. Bob cannot broadcast it as it stands, because the outputs are higher than the inputs and so it is invalid. However, Bob can then add his own 0.1 mBTC input to the transaction, which would make it valid, and can then be broadcast.

Alternatively, Alice could sign with SIGHASH_SINGLE | SIGHASH_ANYONECANPAY, allowing Bob to add his own input as well as additional outputs, in case he doesn't have a 0.1 mBTC ready to go and needs to add a change address.

I don't, but I would recommend reading the three mailing list posts I linked to here for more information about the issue.

True. There is a lot of ongoing discussion on this topic between the CEO of Bitrefill Sergej Kotliar and some of the devs, starting from here: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-October/021056.html. There have been various opinions raised, from "Zero confs were never safe to begin with" to "Use Lightning" to "The receiver can use CPFP". None of them seem entirely satisfactory.

Bump.

There's been another recent flurry of discussion regarding this on the mailing list and GitHub, which stemmed from this post by one of the developers of Muun wallet: [Opt-in full-RBF] Zero-conf apps in immediate danger

His concerns are essentially that full RBF means all their zero confirmation functionality, include submarine swaps and various instant Lightning sends, become too risky and they would have to cease immediately. This spawned a lot of discussion which you can read if you are interested. There is a good summary of the whole issue from Gloria Zhao available here: https://github.com/glozow/bitcoin-notes/blob/full-rbf/full-rbf.md

The discussion spawned several more pull requests:
https://github.com/bitcoin/bitcoin/pull/26287 - remove the full RBF option from 24.0 entirely, and potentially introduce it in 25.0 with a default setting of true
https://github.com/bitcoin/bitcoin/pull/26305 - leave the full RBF option in 24.0 with a default setting of false, and turn the default setting to true in 25.0
https://github.com/bitcoin/bitcoin/pull/26323 - leave the full RBF option in 24.0 but change the default setting to true, but it does not activate until May 1st, 2023
https://github.com/bitcoin/bitcoin/pull/26438 - remove full RBF option entirely

It's not clear yet what the final outcome here is going to be. There seems to be consensus for the full RBF option defaulting to true at some point in the future, but not clear yet if that will be 25.0, a future version, a fixed date 6/12/18 months in the future, or some other point depending on network uptake. Whether or not 24.0 still ships with the full RBF option included but set to false by default is not so clear at the moment, but I suspect it will go ahead as was originally planned.

And do you have a high grade, thoroughly tested, independently audited, state or national level lottery machine in your house? Or do you have some kids toy you bought for 20 bucks? They are not comparable.

That's pretty much how all of science works. We have mountains of data from hundreds of years of global study that says that radioactive decay is random. How much data do you have on your little bingo machine at home?

This is again my point. I don't want entropy I think is random. I want entropy which has been proven to be random.

There we go again. "I would think". What you are proposing may well be safe enough, but we don't know that. And the amount of time and complexity required to exclude bias from a bingo machine is out of reach of the average Joe.

No need to apologize. I was simply stating what I would do in such a situation. But that's the beauty of bitcoin - you are free to use it in any way you desire, and no one stop you.

Don't forget that you are not limited to accepting trades which already exist; you can also post your own trades for others to accept. While you may want to accept some USDT trades now for the sake of speed, you could also post a couple of BTC offers simultaneously and wait for others to accept them in the meantime.

Any seed phrase which is either generated by that site or entered in to the seed phrase box is uploaded to the site's server and therefore accessible by the malicious person behind this site. So yes, the scammer will have your seed phrase and therefore will steal your coins.

There should be no reason to insert an Electrum seed phrase on the Iancoleman site since it will not generate the correct addresses even if it (by chance) passes the checksum,* but you should assume that the scammer behind this site is well aware of the difference between BIP39 seed phrases and Electrum seed phrases, and would also check the seed phrase for any Electrum wallets.

*You can edit the code to make it work with Electrum seed phrases if you desire, but that's not really relevant to this discussion.

Every transaction will be treated as opted in to RBF, so double spending any unconfirmed transaction will be as easy as double spending a RBF opted-in unconfirmed transaction today. So yes, a couple of clicks in a wallet such as Electrum, and you can "cancel" your payment by RBFing it back to yourself.

The default behavior will for nodes to have full RBF disabled, but nodes will be free to enable it if they so choose. The default may change to enabled in the future.

If you opt in to RBF, then your transaction will definitely be replaceable as it is now. If you opt out of RBF, then some nodes will accept a replacement while others won't. Which transaction ends up being mined depends on how many nodes enable full RBF, how many miners are looking at nodes which enable full RBF, and a bit of luck.

It prevents DoS attacks against multi-party funded transactions such as coinjoins and Lightning channels. There's more discussion about why this is the case in this thread: Full RBF

Correct.

You can disable full RBF on your node, but that doesn't mean you can start accepting zero confirmation transactions again if the rest of the network has enabled full RBF. Your node might reject the double spend transaction from its mempool, but that is irrelevant if the double spend transaction finds its way in to a block.

And also the hassle of carrying cash, accepting cash, keeping appropriate amounts of change and coins, the higher risk of theft, the inconvenience, cost, and risk of having to take that cash to a bank to deposit it, and not to mention that many merchants don't accept cash above a certain limit or even don't accept cash at all.

When you consider all the disadvantages of the various types of fiat payment methods, bitcoin is clearly the superior currency as far as I am concerned.

I've just had a quick look through the source code for the .ch site, and here is the scam code which is missing from the real .io site, at line 18,466:


Essentially any mnemonic that you generate using this website is first logged to the console and then uploaded to the server.

And I'll repeat myself as I always do whenever someone ends up on a scam site - follow the instructions below to avoid 99.9% of these scams:


OP: I would suggest you edit the topic title and your first post to make it clear to anyone who stumbles across it or finds it via a search engine that the only real iancoleman site is the .io one. Also, it should only be used after you download it from GitHub at https://github.com/iancoleman/bip39 and run it on an offline machine, and never ran via an online site.

Exactly my point. Neither an unconfirmed bitcoin transaction nor a Visa authorization of payment are final. However, the bitcoin transaction is difficulty and costly to even attempt to double spend (certainly not worth it for the price of a meal in a restaurant) and the double spend attempt has a high chance of failing, while a Visa transaction can be reliably reversed easily and for free with a single phone call claiming that your card was stolen. Further, the window for a bitcoin double spend is ~10 minutes, while the window for a Visa reversal is 180 days.

The only form of money which is instantly confirmed and irreversible is cold hard cash, with bitcoin being a close second. Everything else is a very distant third place.

Having said all that, this situation will change somewhat when full RBF is released with Core v24.0. At that point, zero confirmation transactions will be easily reversed, so you either have to trust your customer not to scam you (as you do with every credit card transaction), wait for a confirmation (still much quicker than 180 days!) or use Lightning.

Wasabi has been reusing addresses, a lot, which has resulted in a lot of post-mix coins being linked back to pre-mix coins and being de-anonymized. And then the devs have been on Twitter, both defending that it is "acceptable" and also lying about it entirely.

Here's an example thread: https://nitter.it/HillebrandMax/status/1586249382097088512#m
Gets shown address reuse, claims it isn't from 2.0 and that it has never happened in 2.0. Then gets shown address reuse from 2.0, and says they've already patched it. How could they have patched it while also claiming it has never happened? They are lying somewhere.

Here's another example: https://nitter.it/ErgoBTC/status/1585671294783311872#m
And dozens more: https://nitter.it/wasabistats

But the devs don't care, because apparently some address reuse is "acceptable": https://nitter.it/HillebrandMax/status/1586321068129939456#m