Are you talking about the possibility of forks being formed from the slow propagation of blocks? Compact block actually speeds up the process significantly in this regard, to the point which I don't think there would be too much delay from propagation of larger blocks. Given that the block intervals are 10 minutes and that there is no need for excessively large blocks, it wouldn't be too much of an issue.

Having a smaller block size entails that transactions would take longer to be included in the block. If a user is willing to wait, then block size becomes a non-factor with the size of UTXO but yeah, I get that there is some correlation.

I think it wouldn't be difficult to configure Bitcoin Core to ban an entire subnet. Purchasing many addresses across different subnets would be cost ineffective.

You don't need to sign the transaction to get the TXID because the signature is no longer a variable within the TXID. If it's a Segwit transaction, you can determine the TXID without the signature within the transaction as the original position of the ScriptSig only contains a placeholder.

As to why the TXID is empty, OP likely hasn't adjusted his fees yet and thus it cannot calculate the TXID without that.

If it's a legacy address, the behavior will be different.

It's more of a hassle if the User A accidentally sends funds to the address after it's expiration but it has already been assigned to User B. Such a scenario can be tricky to handle.

That being said, I think you might be able to do with having addresses that doesn't have any transactions since those wouldn't incur any resource penalty when querying them with an Electrum server. I missed that.


I wouldn't say Electrum is the best candidate because it isn't designed for heavy workload in the first place and having to rely on someone else's Bitcoin node to tell you the correct information doesn't sit too well with me. You do have a point with the issue about xpub, since Bitcoin Core won't derive any xpub. IMO, it would be complicated to manage and swap wallets every now and then. If that's something that you're able to accommodate then I don't think there's too much of a problem. If you'd like, there are services like Bitpay which helps to streamline the process, at the expense of it being a centralised service.

Unlimited supply, inflationary currency. I think I've heard of that before...

You seem to be ignoring the specific problems of fiat that Bitcoin is designed to address but you're attacking the limitations that would be hard/impossible to solve and isn't realistically a problem at all, actually.

Beauty of Bitcoin is that the supply of Bitcoin is fixed and the rate of production decreases over time. I don't see much of a problem of it being a "premine". I would rather the value of Bitcoin not depreciate to near 0 over time as the supply increases constantly, like you know, Zimbabwe.

Split key generation could work. What you could do is to post your part public key and get people to help you find it and split the reward with whoever gets the correct solution. I don't think there is a verifiable way to validate contributed computing power, or at least none that I've seen.

This[1] was one of the first few vanity pools but I don't think it is pretty active nowadays.

[1] https://vanitypool.appspot.com/

Yeah. But the domain name costs is $10 per year or so, at least that's the case for my namecheap domain. If you're willing to go to a budget barebone server, you can probably push the costs to $10 per month, with kimsufi and that's before the discounts from the larger payment intervals. I never found the need for a domain name with a Bitcoin node. Mine was under a subdomain as I was already paying for the domain.

Yeah. My idea isn't about logging donations because it wouldn't matter for full nodes. No one would bother to see but it's nice to have to help sustain the server costs. That's why I don't think that donations would be able to sustain any nodes at least for a bit. I would use mine for other stuff than purely to host a full node and that's why it makes economic sense to me.

I've previously run mine with a static webpage with QR code and some basic graphs as referenced in this topic[1]. It didn't really consume any significant resources on my fairly cheap server so that's a plus.


[1] https://bitcointalk.org/index.php?topic=5251684.msg54517296#msg54517296

I was talking about one without the domain name but even if it has one, I'll configure it under my subdomain, the cost per year is like $10? I used to have one but I had to unfortunately divert my time to other projects. My goal was to have it display useful information (mempool, fees etc) on the page as well. I'll revisit the project soon and hopefully have a streamlined script for that as well.

Higher chance but I don't think it'll be worth to pursue that. Electrum servers, at least for me, tends to take a much greater resources than Bitcoin Core alone. I'll get a better server and run both but I don't expect to get any donation for either.

No. It does help the Bitcoin network by reinforcing the redundancy through the increase in the node count.  The primary benefits lies within the user of the node itself more than the Bitcoin network through the increase in privacy. Bitcoin node operators do not profit off the activities unlike Lightning nodes which are different.

You can set up a donation webpage and someone might donate through the address but it's pretty unlikely.

Right click the transaction you're interested in, press "Pay...". A window called Create Transaction will show up with your transaction details. Check the receipient, amount and the fees. If all of them looks correct, press Finalize, Sign and Broadcast. Check the details carefully.

Are you trying to send the Bitcoins using the URI on the browser? Ie. some button on Coinbase's website.

No. Hardware wallets are designed specifically to deter these kinds of attack. The USB interface should not leak any private keys and all the signing of the transactions should be done within the hardware wallet itself. ColdCard's ability to sign transactions with only the SD card can be a bit of a hassle for some as compared to the better UI offered by both Ledger and Trezor.

That's not a point to consider. If they can leak private keys with the USB interface, I can guarantee no one would use their devices any more. You should be considering the vulnerabilities reported on both Ledger and Trezor. For example, Trezor is vulnerable to seed extraction attack[1] for which AFAIK Trezor offered a workaround but never a fix. Ledger also has it's fair share of vulnerabilities [2]. For both companies, you'll be happy to hear that there isn't any known vulnerabilities which doesn't requires physical access as of now.


[1] https://donjon.ledger.com/Unfixable-Key-Extraction-Attack-on-Trezor/
[2] https://donjon.ledger.com/lsb/014/

I imagine that it'll be a hassle to keep track of the wallets. You'll probably have to change out for a new wallet everyday. Gap limit is not a limitation, it's just how far your wallet will read ahead so no issues there. You would have to account for those who would generate an address for payment but not pay in the end as well.
It's more of the few developers-centric RPCs (getrawmempool,etc) which wouldn't really affect normal users.

Electrum cannot find the inputs to be used in the transaction. Look at the bubble is it green or red? Are you behind any VPN? What version are you using?

The way I've seen and recommend people to implement if they're using Electrum is to only include the master public key on the production server and store the seeds and the main wallet on a separate server. The payment is usually done by checking against some block explorer APIs or through an Electrum running in watch-only mode on the server.

Okay that aside, the main problem doesn't arise until you need to reload the wallet and/or spend the huge number of UTXOs. Spending such transactions or loading them will cause Electrum to lag as it will involves large amount of data being transferred from the Electrum servers and IIRC, some has restrictions on it as well.

I don't recommend people using Electrum as a merchant because it has loads of limitations combined with the lackluster RPC interface (perhaps I'm asking for too much) that I've encountered. Bitcoin Core is a much better choice in comparison and you won't face much problems either.

Spammers generally tries to paraphrase the posts before them, heck I even had spammers just outright copying my post. They got banned of course but it was pretty disgusting. Your advice is going to fall on deaf ears. Continue reporting those who are posting mindless or off-topic posts and merit carefully.

There's no right or wrong estimation. Electrum's estimation accounts for the possible disparity at instantaneous data points due to various factors. As a result, it tends to be more conservative than other methods, and rightfully so. It is more geared towards those who needs their transaction to be confirmed within X blocks with a high degree of certainty. I've never seen it being smaller than mempool estimation method.

Mempool displays the actual mempool conditions at that instantaneous moment. There is pretty much no wrong answer; what it displays will reflect roughly the actual mempool's situation. You have to take the calculated risks because AFAIK, it won't account for the factors like the avg time between the blocks and history of the fees market. I don't recommend people using mempool unless they know exactly what they're doing and/or they're prepared to wait slightly longer for their transaction to be confirmed.

There isn't. It won't be the selling point of HW wallets either. They are supposed to be able to protect the private keys and the funds in the most demanding conditions (being infected with malware etc).

What you're looking for it probably an airgapped offline wallet. You can easily do it with Electrum[1] and you can set up a watchonly wallet on the online computer to gather the data needed.


[1] https://electrum.readthedocs.io/en/latest/coldstorage.html

Is it from Bitcoin Core alone? It might be the bottleneck thats hindering your synchronization. But 0.08% is pretty slow. How much free ram do you have? You can try going to Settings>Options>Main and increase the size of database cache to try to increase the speed.
You probably can't display pictures. Just upload the picture to imgur and send the link here if you'd like.

Yes. Blockchain.com's wallet is notorious for having poor fees estimate as well as poor support in general. I don't think they offer Segwit? I'm not too sure about that. Please stop using Blockchain's wallet.

Using a Segwit compatible wallet would decrease the fees needed substantially. You can try Bitcoin Core, or SPV wallets like Electrum and Wasabi wallet. Having no transaction fees is impossible. You could have some centralised services offering that but they usually have some catch as well.

Using your task manager. Check your disk usage as well.

---

Have you by any chance shut down your computer before the (shutting down...) dialog disappears after closing Bitcoin Core? I think your debug.log will provide more insight. In your Bitcoin Core, go to Window>Information and click (Open) below the debug log file. After that, scroll to the bottom and see if there's any information indicating block corrupted or connection timeout. Anything that indicates an error of some sort.

Untrue. Reference client do not rebroadcast any transactions to their peers. Nodes tends to purge transactions after a specified amount of time of it being in their mempool. They will not attempt to rebroadcast the transaction. The responsibility of that lies with the client you're running.

It'll be useful to use a service which will rebroadcast it for you periodically if you want it to be confirmed and not dropped.