Both also use the same data directories name - so you would have to write a script to start each one with their own dedicated blockchain and data directories.
You can use the --datadir=/path/to/chain command line switch instead of scripting, both for the bitcoind daemon and the bitcoin-cli command. Be careful with the cookie and access rights though, especially on a multi-user user. |
|
|
|
The market cap doesn't mean much at all at this stage. I predict a massively oversold market within the next few dump days, then a recovery, then  profit or crash  |
|
|
|
Once particular thing with BCash compared to other altcoins (supposing no premine) is that most of the coins are already spread between many, many wallets (any BTC holder), and the remaining money supply is relatively scarce (like BTC, again, 4.5M/21M coins). IMHO, that makes BCash an ideal candidate for pump and dumps, or more graciously, "ballooning between cryptos". I won't dump mine too fast. Let's be honest, I would have if I had it in an exchange, but by the time the shockwave of the dumpers has already hit the viable exchanges, you are condemned to land in a massively oversold market. Let's see what the future holds I guess  |
|
|
|
the first block is mined, but the fork seems to be just another joke...watch out people...it may come back...  Nope, it still isn't from my node point and view, neither is it from this one https://www.btcforkmonitor.info/ |
|
|
|
The site is rekt and no block has been relayed to nodes yet. EDIT: when it's working, the site is just showing blocks up to height 478557 so... nope, you're wrong. With Bitcoin, hashrates do not increase or decrease by orders of magnitude over periods of seconds or minutes. If the info is "legacy" info, it is definitely still flawed.
Of course it's flawed. You are so vehemently defending your point, you should learn to take yes for an answer  |
|
|
|
ViaBTC says the total network hash is equal between BCC and BTC. https://pool.viabtc.com/But statistically, this certainly cannot be. Why anyone would publish such verifiably false information as this is utterly beyond my comprehension. I would say it's merely a legacy of the pre-fork hashrate. No one can determine the network hashrate before blocks actually get mined. That being said, assuming ViaBTC is the only significant BCash pool, we probably won't see blocks before several more hours. |
|
|
|
There's also rules in BCH that will reduce the difficulty mid-adjustment period. Maybe an expert (not me) can comment on what circumstances are needed to reduce the difficulty before the next adjustment.
Here it is: REQ-7 Difficulty adjustement in case of hashrate drop
In case the MTP of the tip of the chain is 12h or more after the MTP 6 block before the tip, the proof of work target is increased by a quarter, or 25%, which corresponds to a difficulty reduction of 20% .
RATIONALE: The hashrate supporting the chain is dependent on market price and hard to predict. In order to make sure the chain remains viable no matter what difficulty needs to adjust down in case of abrupt hashrate drop.
Source: https://github.com/Bitcoin-UAHF/spec/blob/master/uahf-technical-spec.md |
|
|
|
Bitcoin (BTC) is stable. Quoting theymos (read the header), There are no visible Bitcoin issues, so it seems reasonably safe to transact in BTC. So I'd say you can safely go ahead now. |
|
|
|
They spun up a ton of nodes to fake community support (which does not exist).   Who would have thought that Amazon would be the first winner? This won't help mining Bcash blocks though. Now I'm thinking something's like Tor's consensus weight could be useful for blockchain nodes too |
|
|
|
Well that's concerning. I'm running Bitcoin Classic version v1.3.1uahf and get $ ./bitcoin-cli getchaintips
[
{
"height": 478560,
"hash": "000000000000000000e512213f7303f72c5f7446e6e295f73c28cb024dd79e34",
"branchlen": 0,
"status": "active"
}
]
I don't get it either. Maybe the developer could clarify? (any pointers to the correct thread?) The node I pasted from is running ABC 0.14.6 What is the hashrate on BCC?
You can't determine this before BCash blocks actually get mined. |
|
|
|
I don't really get why the new blocks aren't being accepted by the BCC chain, but they aren't.
Because UAHF *mandates* a >1MB block after mean chain time is past Aug 1, 12:20 UTC, which is now past. This is a sort of BCash chain special "milestone" marker block, then blocks on top of it are allowed to be <1MB again |
|
|
|
Yes it has, and there are now enough tx in Bcash mempool to mine a >1MB block So, yeah, it happened. Another confirmation (from Bcash chain) $ bitcoin-cli getchaintips
[
{
"height": 478559,
"hash": "00000000000000000019f112ec0a9982926f1258cdcc558dd7c3b7e5dc7fa148",
"branchlen": 1,
"status": "invalid"
},
|
|
|
|
Previously some exchanges announced that they are not going to give BCC coins for those who hold in particular exchanges. I think we have to wait for a further update regarding BCH and free airdrop of BCC to people who hold bitcoins which have private key.
I think you've been too much into pre-mined alts Unless SN himself provides the airdrop stash, I wonder how that could happen... |
|
|
|
Of course, the accelerated difficulty adjustment will keep ratcheting down 20% every 12 hours, until it is minable by GPU. If it makes ya feel any better, if it goes that long, I'll mine the first damned fork block. I've still got one of those USB FPGA hashing dongles around here somewhere...
Nah, I'll beat you to it!  Fun fact: the one on the top has cost me 50 BTC directly from friedcat, RIP |
|
|
|
Unsurprisingly, the mempool has run so dry it's actually impressive $ bitcoin-cli getmempoolinfo
{
"size": 160,
"bytes": 570044,
"usage": 1013008,
"maxmempool": 300000000,
"mempoolminfee": 0.00000000
}
I guess a few more blocks and they won't even be anywhere near 1 MB |
|
|
|
Byteball looks super interesting, why are there so many useless/p&d/ponzi coins making so much noise in the alt boards, that the really innovative and good quality ones can go unnoticed for so long? Anyway, now I'm looking forward to the next moon |
|
|
|
Thank you for your reply, so essentially they are trading something that isn't even here yet! Maybe something like futures? Wow, what happens if the split does not really take place? or is the split imminent... sorry for the n00b questions, but this is all so confusing! Hilarity ensues, I guess? Seriously, the fork is likely to happen. The value of the forked coin (Cash) is mostly unknown. So is the behavior of the new untested chain, to a certain extent at least. Yes, things might go wrong. |
|
|
|
Confusing because I thought that BIP148 was a non-issue and that BIP91 pretty much nullified BIP148 because it accomplishes the same objectives that are outlined in BIP148 and even BIP148 has language to the effect that it is nullified if segwit BIP141 is in the process of locking in or maybe it has to be locked in for BIP148 to be nullified?
It is very confusing indeed. Here is my understanding, but I might be wrong, feel free to correct me. UASF (BIP148) is logically redundant because of BIP91, which share the same SegWit (BIP141) implementation, but with a different activation time: as I'm writing this, there are still 1325 blocks remaining before BIP141 is expected to lock in, while BIP148 starts just about now. But using SegWit before BIP141 activates would be silly because SegWit requires "protection" from network consensus made for SegWit (sorry for the massive oversimplification), and there are not enough BIP148 nodes on the network to offer this. |
|
|
|
And how can this be done safely and surely without the transaction being accepted on the other chain also?
To "split" your coins safely, assuming you have a trusted environment and BTC wallet in the first place: - Create an completely new BTC wallet, i.e. not sharing any keys with the old one
- After the fork, move all your BTC from the old wallet to the new wallet
- Once your old wallet is empty (on the BTC chain), export its private keys
- Create a new "Bitcoin Cash" wallet, import private keys from your old BTC wallet
Now about the transaction not being accepted on the other chain: The rationale behind replay protection is basically making transactions incompatible with the other chain by design, i.e. by consensus rules. If someone (or your wallet/client/whatever) records and broadcasts your transaction to the other chain, nodes will reject the transaction. You can read the UAHF specs that I linked in my previous post for the gory details. |
|
|
|
I thought that this thing was supposed to go at noon UTC and not midnight UTC? What am I missing? 12 hours earlier than expected?
UASF (BIP 148) should activate within a few minutes as the chain median time reaches midnight UTC. UAHF ("Bitcoin Cash") will activate when median time hits 12:20 UTC. https://www.btcforkmonitor.info/ |
|
|
|
|
Show Posts
