Perfectly valid concern.

I would argue that Tor or any browsers of that sort does enough to obfuscate the data such that an adversary wouldn't really be able to correlate the data on a large scale. If that is indeed a threat, then using those SPV wallets which leaks privacy wouldn't be suitable and there are far better things to worry about so this wouldn't really come up as an issue.

They are. Broadcasting transactions generally won't leak privacy more than your SPV wallets. Even if they were to collect data, they would only get as much data as your browser leaks, which in the case of privacy conscious ones, it isn't that much. I would recommend using a privacy-centric browser and using a new identity for each session, which in normal circumstances can't provide sufficient data regardless.

That is already happening. The responsibility of taking care of their own devices lies on the operators themselves. At best, you're trying to make botnet mining harder, while trying to introduce sophisticated schemes also at the expense of the user. Solving pool dominance is not at the core of Bitcoin's issue, because at the end of the day, your network's hashrate is still concentrated with those that has the most equipment and resources.

The way I see it, this scheme does not really benefit the community as a whole, nor does it eliminate the possibility of users using botnets to mine. You will profit as long as you continuously send the funds out as it gets mined, so you'll still be able to net most of the coins. You might be able to implement it in an altcoin but I have my doubts that it would ever materialize in Bitcoin.

Just to be clear, this problem isn't particularly salient in crypto, because it isn't that feasible. Bitcoin is best mined with ASICs and an array of botnets would only be a fraction of what ASICs can mine. Sure, you might be able to gain some money by mining Ethereum, but not much. The solution proposed will mean that the user has to know that a botnet is functioning in the computer and that funds are not locked (ie. moved out immediately) so they'll have a very short timeframe regardless.

Botnets are primary useful for click frauds, DDOS, etc. I don't think it is a particularly prominent issue that is easy to solve.

Running a node isn't like mining. The high power consumption will not be sustained, even if the TDP is designed as such. Your processor should only use as much as it requires, though a full fledged board would likely have additional components that require constant power. If you were to get an older inefficient laptop, then the TDP doesn't matter because it is inefficient.. It is only a metric used to determine the thermal output (and even so, there is some discrepancy for reporting) but it doesn't account for the efficiency at computational operations.

If you care about performance for money, then older laptops might not be the most cost effective because you also need to factor in the cost that goes to the miscellaneous components a node wouldn't need. If you don't have any other choice, then you should look at those old refurb desktops instead.

It is actually a little bit inaccurate to compare them solely based on the number of cores / if HT is enabled or not. The fact is that because Core is dependent on so many factors to synchronize, certain variables can affect the speed of it. For example, if you were to compare a DDR3 NUC vs a LPDDR4 RPi4, then the RPi4 could potentially be faster because the speed at which the cache in memory can be accessed would be faster. Same goes for CPUs (IPCs?), HDD (depends on the interface), too many factors to consider.

It is important to identify the bottleneck of each devices; be it your drive, ram, CPU. Anyways, I think the topic is about whether you can run it, not how fast it would synchronize. The answer is yes, it can be done just increase the size of your drive.

You underestimate the efficiency of the ASICs that we have. My USB ASIC has a higher hashrate than FPGAs while being more efficient and potentially cheaper. FPGA is okay if ASIC isn't mature already. That isn't the case for Bitcoin, anyone would prefer using an ASIC over FPGA for SHA256D unless they don't care about profits.

You are probably looking into the direction of redundancy. Introducing an additional novel method of communication wouldn't make it more "redundant". Reason being, if people needs to get a completely new tech just to use Bitcoin, then you are raising the barrier of entry. You need new equipment which has to be visibly installed or obtained. It would only exist if the government which the users are in supports Bitcoin. Using an infrastructure that doesn't already piggyback on the country's core infrastructure is counterintuitive.

NUCs are generally faster than RPis, if you're comparing the latest ones with each other. If they are one or two generations apart, then a NUC would be faster, but also more expensive and consumes more power. If you were to get the one with the specs that you've described, it will work but a RPi 4 would be faster than the NUC.

Most cryptocurrencies are in fact decentralized by definition, because there isn't an actual central authority that regulates it. The degree of decentralization is the point of discussion here. That has to do with how any entity is feasibly able to control Bitcoin, and the answer for that is that it is not easy. You can restrict access to it, through GFW or something similar but it isn't effective till you block it off entirely.

Even if you establish a hermit empire like NK, you don't compromise the decentralization of Bitcoin. You merely lose access to that part of consumers but it doesn't compromise the decentralization of it otherwise.

The nature of ASICs is that they are highly specialized, which means that it is practically impossible to change it otherwise. Each chip has a specific function, for example BM1385's datasheet[1] has a UART portion that specifically details the data that should be communicated to the chip itself. If an ASIC is as optimized as it gets, which I suspect it does, anything that doesn't have to do with mining will be eliminated.

If you need it to be able to be reprogrammed, you have to use FPGAs.

[1] https://bits.media/images/asic-miner-antminer-s7/BM1385_Datasheet_v2.0.pdf

There is no point trying to obfuscate addresses by sending redundant data, that would just massively increase server load for honest SPV servers while doing little to nothing for the malicious SPV servers. You absolutely can push your transactions to a random node, assuming you're not actively having a targeted sybil attack on you. There was a wallet that actually did exactly this, but I forgot what wallet it was (only vaguely remember looking through the code for that).

The problem is that bloom filter or whatever methods being used by most wallets uses are fundamentally flawed. The onus should be on the wallet to change their ways of querying the server in a bid to improve privacy. Wasabi for example, uses BIP158 which requests for the entire block as well as additional decoys from their peers. This would be far more effective at tackling the root of the issue.

ASICs can't be reprogrammed.

The design of the chip only optimizes it for one task. If the task isn't SHA256D mining, or any other specific mining algorithm for that matter. If you need anything else, then you need an entirely new chip.

You cannot fake a transaction, because every node checks for it's validity. You cannot spend something that doesn't exist or if the signature isn't valid. The only exception being some sort of design flaw which inadvertently causes the node to pass some checks even if it is not supposed to. That would be incredibly rare to say the least, because it isn't that difficult to check for the few simple criteria.

Merchants calculate certain risks that they are able to bear. Be it through the percentage of revenue that they're making or frauds that would happen with other payment methods.
On top of that, merchants evaluates the risk of every transaction, how likely is it for someone to double spend the transactions and what they'll otherwise gain. If the risk is acceptable, then there is nothing wrong with accepting zero-conf transaction.

Of course, LN is practically instantaneous and many merchants have switched to that.

Did you select the correct denomination? Electrum using mBTC by default when displaying values. Go to Tools>preferences>Base unit to change it to BTC.

Change gets sent back to the same address.
Use pay to many, it doesn't increase the fees. For the first line, use the address of your intended recipient and the amount (address,BTC AMOUNT) and for the second line, use this: (Change address, !). The exclamation mark tells the client to send the remainder to that address.
Most people don't need to mess with the nlocktime so I wouldn't really recommend for you to do so either on mainnet though it is relatively risk-free. You can run Electrum in testnet, get some testnet coins from the faucets and experiment with it.
Your wallet will automatically broadcast the transaction once the transaction becomes final (ie. the specified requirement is met). If your wallet doesn't, then you would need to do so manually.

You'll have to select Advanced Preview.



Can't remember if Core has it, don't recall seeing it. You can select both unix and block height.

What stops large farms or botnets from dominating this by hunting through different nonce each set of transaction? Does this impose additional penalty on each node since the factorization has to be done on each transaction when it gets relayed?

Another point that I'd like to highlight is with the block rewards. Would the total supply of the coins be capped or have an increased inflationary trend? The compensation for this has to be adequate to maintain network security while allowing a proportion of the transactions to be essentially free.

The cost of the work done per transaction has to match with the amount of fees being paid per transaction. Or else, this doesn't make sense because it becomes cheaper for an adversary to spam the network or for people to offer their computing power for this. This also means that transaction that relies on the POIW (by your definition) would potentially take more time because your computing power expended has to match with both the current fees and be prohibitively expensive.

In essence, this scheme wouldn't be very useful for the average joe because they would very much rather just pay for the transaction. Botnets can easily circumvent these hurdles while the average joe finds it more of a hassle.

Electrum allows you to set locktime and infact, most wallets already preset a locktime for every of your transaction by default. Locktime simply means that your transaction won't be relayed until the locktime has passed.

Setting a fixed fee is okay, but you would be looking to set a specific fee rate instead of a fixed static fee. Chances are, your transaction might not get relayed if the fees are too low relative to your transaction size. You should instead be trying to fix a fee rate. You can still use legacy addresses and send to a P2SH address without any problems, though wallets like Electrum has started to deprecate those.

Bitcoin Core or Electrum would be your best bet. Please do not manually script your own transaction if you have no idea what you're doing. Using coinb.in without knowing exactly what you're supposed to do is a recipe for disaster.