Not the worse advice ever. I'm somewhat lucky that I'm generally not transacting every day... so by the time I actually notice there is an update to be had, it's generally been a decent amount of time (ie. days) between the update being released and me noticing

But yes, I certainly don't blindly click the "update now" button... I'll go find the release notes and see what has been updated/fixed/modified... and then have a quick scout of here/reddit/google to see if there are any widespread reports of issues.

Maybe come back and let us know what you think after you have actually read the document fully.


This forum needs a #facepalm emoji...

You don't explicitly set a fee value when creating transactions like this... the fee is implicitly set as the different between sum(inputs) and sum(outputs).

So, if you have:
InputA + InputB + ... + InputN = 0.01 BTC
and
OutputA + OutputB + ... + OutputN = 0.00999500 BTC

0.01 - 0.00999500 = 0.00000500

Then you have effectively set the fee to be 0.00000500 BTC... the hard part is that it isn't "total fee" that generally determines your transactions chances of being picked up and included in a block... it's the fee rate... ie. (total fee / transaction "size"^[1]).

Unfortunately, the estimation tools available (estimatefee and estimaterawfee) give answers in fee rate... and not total fee, so you'll need to do some maths on how big your transaction is going to be, to work out what the "total fee" should be.

Theoretically, you could just do what you've done, and create the transaction with Sum(Inputs) == Sum(Outputs), then check what the transaction size is... then use that value along with the estimated fee rates to calculate how much to reduce the "change" output by... then recreate the transaction using the newly calculated change value and hope for the best



[1] We'll ignore the size vs. weight for the minute.

Is the idea that 2 people would be working on the same machine to send transactions and you need both users to enter their password for this to happen? ie. you're essentially trying to force multisig but using just a password instead of signing with private keys?

I don't think any system exists... at least, I don't know of any such system. Personally, I think you'd be better off just having a 2-2 MultiSig wallet in a wallet like Electrum. Each user would have their own copy of that wallet with their own password.

When you want to send coins, either person would be able to open their wallet and create and partially sign the transaction (using their password) and then pass to the other person to sign and send using their password.


With a standard MultiSig wallet, as described above, each of the user's copies of the multisig wallet would operate independently of the other, so the passwords could be changed independently of the other without issue.

That's the great thing about all of this... there are plenty of ways to skin the proverbial cat   Plenty of options to get up and running in a way that suits your budget, your physical space requirements, power limits, mobility requirements etc.

Pi's tucked away behind your monitor, an old repurposed desktop sitting in your closet, you daily driver laptop etc etc... modern technology is great

What "credentials" are you talking about? Bitcoin Core has exactly one type of "credential"... the wallet passphrase (it's just an encryption password) and for that to be useful, you absolutely 100% require the wallet.dat file.

If you don't have access to the wallet.dat file, you're not recovering your Bitcoin Core wallet.

It likely won't help much... even with USB3.0, the read/write speeds are still orders of magnitude less than with physical RAM... and with a machine with those specs, I'm not even sure it will have USB3.0.

You'll likely find that the HDD I/O is faster anyway... but if you have a spare "hi speed" flashdrive laying around, give it a go and report your findings

If someone has access to your offline, airgapped computer... you have much bigger issues than the fact they might be able to download some tracking metrics from Cortana

So, what happened to the whole SIGHASH_FORKID thing that the Bitcoin Cash devs implemented at the eleventh hour (it went in like a day or 2 before the fork)?

https://bitcoin.stackexchange.com/a/102405

Addresses between BTC and BCH are "compatible" yes... but transactions are not... again, the replay attack stuff was purely with BCH and it's forks (BCHA BSV etc)

A couple of other advantages that the single board units like the Pi have is "size" and "power draw"... Even with a case on it, the Pi is a very compact unit, and easily fits on my desk behind my monitor etc. I don't have a lot of room in my workstation area (or anywhere else in my apartment for that matter) and having a unit like a laptop or old desktop in addition to my actual PC isn't really practical.

Then there is the power draw... the Pi runs on a 5V USB charger. It uses next to nothing in terms of power draw... at max load, the CPU is only consuming something like 6 or 7W! And an external drive will only be adding ~5W more at most.

Isn't this all rather moot considering that BCH implemented 2-way replay protection?

As far as I'm aware, you can't broadcast a BTC transaction on the BCH chain and you can't broadcast a BCH transaction on BTC chain. The replay issue was only really a thing when the BCH/BCHA/BSV forks happened with no replay protection.

This answer by Peter Wuille sums it up nice and succintly: https://bitcoin.stackexchange.com/a/11311

Essentially, it is theoretically possible, but very unlikely, that you could get multiple addresses here.

You can either code it expecting to only ever get 1 address, and then pray it never happens (Bad Plan™ refer: Murphy's Law)... or implement some kind of exception handling to handle the multiple address case so your program doesn't crash... even it is just logs it and then ignores the transaction and continues on it's merry way. ("Better Plan"™).

For wallets that use a seed mnemonic ie. 12/24 words (NOTE: Bitcoin Core does NOT use this backup method)... If you don't have the seed mnemonic (ie. you lost your paper), and you don't have access to the wallet file, then there is nothing you can do. Your coins are lost.

For Bitcoin Core, it doesn't use 12/24 words seed mnemonic... so you absolutely must have the wallet.dat (or some other record of the private key). Without those, you will not be able to recover your coins.

The "generate bitcoins" option just enables the builtin CPU-based miner. It doesn't do anything that a "normal" miner does and, being as old as it is, is probably not terribly well optimised.

What do you mean by a "minus block"? What exactly are you trying to achieve here?

Just as a test I ran Kangaroo using CPU only... (6 core, 12 threads Ryzen 5 3600)... It solved the #63 puzzle in 2:40



Using just the GTX1080, Kangaroo solved it in 26s.



Obviously the #64 puzzle is significantly larger than #63... but then I tried the #65 puzzle (which is even larger) and the GTX1080 solved that in only 1:34



Having such a small range, and the pubkey really does make cracking these private keys very trivial.

Are you talking about the "Generate Bitcoins" menu option that was in the original client?

I'm not aware of any "Earn Bitcoins" tab... mind you, I never used the original client, and, as it turns out, there don't seem to be many screenshots of it floating around on the internet... at least, not of the "options" menu. Only the main screen like this one:


(source: https://twitter.com/bit_fix/status/505105572946247680)

What would you recommend if not "file-based wallets"? Are you talking about hardware wallets?

There isn't... it just perhaps wasn't explained very well.... and possibly the <---> isn't the best way to show things either.

Essentially you have "inbound" traffic flow that goes:
Internet ---> nginx (port 5001) ---> Hypercorn (Port 5000) ---> LNBits

Then the outbound flow that goes:
LNBits ---> Hypercorn ---> nginx ---> Internet


nginx is essentially receiving the inbound packets passing them to Hypercorn to do whatever it needs to do with them (pass to LNBits, dump, return webpage etc)... Hypercorn then passes it's response back to nginx, which then passes them back to wherever they need to be going on "The internet"™.

That's a big ooooof right there... Windows 10 will generally be eating all of that RAM on it's own... let alone trying to have Bitcoin Core do it's thing as well.

If that RAM value is correct, your system is likely page swapping like crazy, which will impact on the disk I/O which is one of the main bottlenecks for Bitcoin Core to sync (hence why SSDs are recommended).

If you can, add more RAM and/or an SSD as well... otherwise, your only real option is to just wait it out

For Pollard's Kangaroo, you need to know the public key that you're trying to match.

OP was theorising that once they publish their transaction, someone could use Pollard's Kangaroo to trivially solve the private key in a matter of minutes and then publish their own transaction stealing their prize.

I'm not overly familiar with the performance of this particular algorithm or the available scripts for it... but if the actual winner just disables RBF and sends with a "decent" fee, the odds of their prize being "stolen" would be pretty minimal, I would think.