Sure

What I mean to say is this -- if you're paranoid about having your private keys derived due to using a HD wallet, then refrain from using a watch-only wallet. One can still benefit from using a HD wallet without exporting its xpub key.

Even in cases where using an xpub key is absolutely necessary (eg. when automatically generating addresses to accept online payments as a merchant) one is not forced to use the xpub key of their cold storage wallet. Just use the xpub key to generate addresses for incoming payments and forward them to hardcoded cold storage addresses from there.

Granted, in general treating the xpub key like a private key might be a bit excessive. But there are cases where this level of paranoia may make sense or where needless exposure of the xpub key is just taking unnecessary risk.

OP mentioned above that this approach would target a privacy-centric userbase for which phone or ID verification are not an option. While the majority of users don't care about their privacy and personal data there's definitely a need for less intrusive anti-spam measures.

No.

51% attacks may involve withholding blocks, but they not necessarily do.

Withholding blocks is more effective with the majority hashrate, but is not a prequisite for such an attack.



Selfish mining (an economical attack on fellow miners):
https://bitcoinmagazine.com/articles/selfish-mining-a-25-attack-against-the-bitcoin-network-1383578440/

Finney Attack (a double-spend attack):
https://bitcoin.stackexchange.com/questions/4942/what-is-a-finney-attack



An attacker that has the majority hashrate does not even need to bother with withholding blocks. They have full control over which transactions make their way onto the blockchain and can ensure that blocks found by their competitors always end up orphaned due to being able to outmine the minority hashrate for as long as they control more than 50% of the hashing power.




The Finney attack mentioned above is a block withholding attack that can be used to invalidate the recent block without running majority hashrate.

For the most part it seems to be rather uneconomical though and is easily thwarted by waiting for at least 1 confirmation.

For the record, Bitcoin addresses starting with "1" are legacy addresses, which in your case is actually a good thing.

However...


Your transaction number does show up neither on BCH nor on BTC block explorers. Same goes for the address 1Asw9BGefMxkG4TTUhs1fsiKuyCqRmeccy. If you merely sent coins on the wrong Bitcoin blockchain the transaction should have appeared on at least one of the block explorers. However it seems like the address is incorrect as well.

Which wallet did you use to send your coins from? Bitcoin ABC? Can you double-check your transaction history to which address you sent the coins to?

Because people have mined with both physical hardware and mining contracts before, know some basic math and are not as inexperienced as some of the newcomers cloud mining companies try to sell their contracts to.

Even assuming the hashrate actually exists, offering cloud mining services is merely a way to pass on the majority of the risk of the initial investment on to an unsuspecting customer. Why wait for your mining infrastructure to reach ROI some time in the unpredictable future when you, as a mining company, can get your money right now by selling your hashrate to some easy victim? All that for the added bonus that your targetted userbase is willing to pay more for the hashrate than one may ever expect to make from merely mining in the first place.

It's basic economics, really. Everything else is just a fairly tale.

Even ignoring scam ICOs, people simply underestimate how many companies and startups fail.

For every Google, Amazon and Bitcoin there's thousands of companies and projects out there that either underperform or fail miserably. Problem being, to be successful a lot of things need to be right, but to fail it often suffices when just a single factor falls short (eg. great execution is worth nothing if the idea is bad and vice versa; having a great product is worth nothing without a userbase etc). Doesn't matter whether the company is actually legit and whether the people behind the project are publicly known. Companies fail, and that's that.

The thing is, with classical VC investments there's usually 1) a stringent screening process and 2) a wide variety of startups being invested in, as to spread the risk. Most startups will lose you money, but the few that succeed are expected to make up for the losses.

ICO investments usually involves throwing money at pipe dreams sold by a flashy WordPress template with next to no research. Accordingly the ratio between losers and eventual winners is not exactly profitable.



Regulation can't cure stupid.

To add to that, C/C++ compilers are much better understood and tested than compilers of newer languages. If only by merit of being around for much longer. So while newer languages may seem better designed and more appropriate they still have a couple of years, maybe even decades left until they reach the level of trust and performance of C/C++.

I mean just look at Ada. That language is even older than C/C++ but there's a reason why to this day it's still being used for military and avionic software development.

The title is not only clickbait, but also utterly wrong.

Block withholding attacks and 51% attacks are two entirely different things.

51% attacks by definition always include the majority hashrate, block withholding attacks not necessarily do.

Granted, block withholding attacks such as selfish mining are at their most effective with the majority hashrate, but then again every attack on PoW is. In the end once a miner achieves majority hashrate they can attack the network whatever way the like, regardless whether they decide to withhold blocks or not.

Apart from attacks on the incentive structure of PoW such as selfish mining, block withholding attacks are usually thwarted by... waiting for confirmations. That is, by using the protocol the way it was meant to be used.

That being said:


So the solution to block withholding attacks is.... federated trust.

...

*slow clap*

Cryptography is the judge and you are the executioner.

Once your counterparty tries to cheat you by trying to enforce a stale state the protocol provides you with everything you need to withdraw both your and your counterparty's coins from your shared multisig address.

Alright, that's slightly less worrying then.

I was expecting something along the lines of "l0ve1s4lly0un33d" or a 1337 version of "Hey Jude" which would have implied a far vaster lookup table. (assuming it isn't already. well, probably now it will be.)

It not only suggests bots, it also suggests that these bots iterate through rather impressive lookup tables.

Have you checked whether this particular passphrase has been part of a prior leak? You can check here: https://haveibeenpwned.com/Passwords

It would be interesting to know whether our brainwallet sweepers are using publicly available password lists or have some pimped collections of their own.



There seem to be quite a handful of bots competing for the most common passphrases. This talk from 2015 estimates them at half a dozen [1], I wouldn't be surprised if matters have gone worse since then.

[1] https://www.youtube.com/watch?v=foil0hzl4Pg (around the 31:30 mark)

Best of luck. I hope for your sake that you won't learn the significance of "not your keys, not your coins" the hard way. Granted though, if you're actively trading there are currently few other options available unfortunately.

Oh definitely. I still think it's worth repeating though, in case someone starts doing research of their own beyond YouTube and happens to stumble upon a thread like this.



I doubt it would amount to anything unfortunately. It's a slippery slope for one (a couple years back you could have argued the same about Bitcoin -- in crypto the borders between speculative and scammy are very blurred for an outsider), secondly even the advertisements being run on YouTube have sank to a level where I've seen straight up HYIPs being promoted.

Have you checked the list of supported coins lately? Satoshilabs hasn't been sleeping! While the Trezor One still supports a handful less coins than the Ledger Nano S the difference isn't as large as it used to be: https://trezor.io/coins/

Protip for newcomers: Stay away from cloud mining. Worst case you're getting scammed, best case you're getting hashing power for a price that will never turn a profit. Don't underestimate difficulty increases, my friends.

It's an interesting approach, but I'm also doubtful it would be all that effective.

Most large email providers already apply (centralized) anti-bot measures of their own that likely serve as higher barrier of entries than what you describe (ie. requiring a phone number for verification or a small donation). Smaller email providers that don't bother with such anti-bot measures probably won't bother with the coin-holding approach either.

Additionally I'm under the impression that large scale spammers have long since transcended centralized email providers. Most seem to run email servers of their own, playing the anti-anti-spam-filter game at a wholly different level (eg. trying to circumvent their mail servers and domains from being blacklisted).

Obviously the points above only consider email accounts. Other services may be a better fit for such a solution. Still, I think the coins would need to be actually at stake for this approach to be effective (eg. by keeping the coins in escrow or timelocked until a certain grace period).

There are crypto exchanges where you can deposit and withdraw both cryptocurrencies and governmental fiat currencies. Some of which also offer lending functionality, allowing you to earn interest similar to classical banking.

While you can store money long term in a crypto exchange (I guess what you would call an electronic money bank), you definitely shouldn't. Trusted exchanges have failed in the past and trusted exchanges will fail in the future. So unless one wants plans on actively trading, the risk of keeping money on an exchange is not really worth it.

Look into the bitcoin-core and bitcoind-rpc npm packages.

https://www.npmjs.com/package/bitcoin-core

https://www.npmjs.com/package/bitcoind-rpc

Unfortunately they don't seem to be as well maintained as they used to be, but both come with enough example code to get you started.

It is worth noting though that you have to share the xpub key with a potentially compromised machine in the first place. Short of unknown derivation weakenesses there is no security compromise if you treat the xpub key just as you would treat a private key (ie. never have it touch an online device).

I re-read your posts and I think I misunderstood you the first time around. Sorry about that.

So your suggestion is that users should be expected to receive a minimum amount of merits per week, lest they get demoted, did I understood you correctly?

It's an interesting approach, but you'd still have to account for 1) users taking a break from the forums every now and then and 2) high variance in terms of how many merits one receives within a given period. The latter could likely be alleviated by looking at a long enough timeframe (eg. 1 month instead of 1 week), the question of how to handle periodic inactivity is IMO not as easily answered though.