In POW a double spender must wait until a merchant accepts his initial payment (at 1 confirmation, say), and then outpace the network to produce a longer fork and the cost is linear in the number of blocks.
Is a way to increase this cost somehow, to make it quadratic, or higher order in the number of blocks?
The cost isn't really linear. As Satoshi says, the chances of catching up becoming "vanishingly small", therefore the cost becomes exponentially large. It would have to be very expensive coffee for the attacker to do such a thing as they would make a lot more money just by submitting the blocks for the block reward. So in that sense it is quite expensive. and also each block that is mined makes reorging exponentially more expensive as jonald_fyookball states. The idea of making a double spend more expensive is interesting though. However, since there wont be consensus on all nodes as to whether there even was a double spend (we are talking about the chain reorging here), then I dont see how you can make double spending a specific input require more PoW in a way to achieve global consensus. Unless... If there was a separately maintained consensus of all 1 conf transactions (I think it can be proven this cant be done with 0confs), then we would have a global consensus on any attempt to double spend any outputs from this 1 conf list. So theoretically it would be possible to make the weight of any new chain that is attempting to double spend any output from the 1 conf list to be arbitrarily lower. Just need to maintain a tree of such 1 conf txlists, and each reorg would spawn some sort of alternate 1 conf list. I think it is quite a lot of work, but probably not impossible to do. However, considering this is a hardfork and orders of magnitude more difficult than fixing malleability, it is unlikely that it will ever be done. James |
|
|
|
Ignoring compatibility issues, the following would fix this once and for all, wouldnt it?
This is a hard fork, since old clients would consider those signatures invalid. With a hard fork, there are lots of solutions to the problem. Lets hardfork! |
|
|
|
Is it possible to create 2 txns with the same normalised txid ?
I have seen two pairs of identical txids, back around block 90000 and they are in the blockchain To fix this once and for all, would need to have a first come first served allocation of txid, so duplicates would be rejected. Kind of a mess if a reorg happens though... |
|
|
|
You are not alone...  I'd love a solution. The Only one I could think if, is as you mention at the end, to have a 3rd signer. So you would make a 2-of-3 address, and if there is a TXN malleability issue, AND the other party tries to blackmail you (which he may not do), then you can always fall back on the 3rd signer to process the refund. BUT - the issue with that is that you and the 3rd signer could send the funds whenever you like, without waiting for the required locktime. So the 2nd Party, the one you are trying to trade with, would then be at the mercy of the first and 3rd signer.. I can't think of a way of preventing the 3rd signer from 'not' signing until a reasonable amount of time has passed, as otherwise the other party would not get involved in the first place. Other than TRUST of course. I wanted to implement this in an exchange, as I'm sure many of us do, but it's just not quite there yet.. .. OP_CHECKLOCKTIME !? When please..? other than during the malleability attack last year, how often are random third parties messing with txids of others? There seems to be no gain from this, so just vandalism? It just seems like preventing tampering of txid by unrelated third parties should be fixed after all these years. Any other solution is just a workaround and needless complexity James |
|
|
|
|
Thanks for everybody's feedback, its good to know I am not alone.
Anyway, it seems that there is the possibility that some vandal to just intercept, modify and rebroadcast transactions, which would invalidate the refund transaction and if Bob can wait out the expiration time for the other half of the trade, he could cash in the coins safely.
I sure hope some BIP in upcoming hardfork will fix this problem as allowing unrelated third parties to change the txid is just wrong.
So for big money transactions, even a small risk like this is not a good thing. Alternative is to break up the trade into multiple pieces, which already can be done just by not trading increments larger than pain threshold.
I will also add an optional third signer for the multisig address, so that in the event that the txid was changed via malleability, the refund will be processed. Since if the refund is processed, then Bob is not out anything and if he just spends the funds, Alice can approve the NXT tx, so it might even be something safe enough to automate.
James
|
|
|
|
Ignoring compatibility issues, the following would fix this once and for all, wouldnt it? ********** #define SIGHASH_TXID 0x40 change https://en.bitcoin.it/wiki/OP_CHECKSIG: Final signature check An array of bytes is constructed from the serialized txCopy appended by four bytes for the hash type and if SIGHASH_TXID is set followed by the txid. This array is sha256 hashed twice, then the public key is used to check the supplied signature against the hash. The secp256k1 elliptic curve is used for the verification with the given public key. ********** also the txid cant include the sig. Not sure why the txid calc isnt using the same data as the signature calc. James |
|
|
|
So if Alice is trying to cheat by making the funding tx invalid
The known problem is the refund transaction being invalid, not the funding transaction. Bob quits, and Alice has no valid refund transaction. (I didn't read your protocol carefully, but there is a fundamental problem with a refund transaction, at least at the moment.) If Bob quits, then how does that invalidate the refund transaction? Alice creates funding tx and doesnt broadcast this until she is satisfied that the refund tx (and phased tx) are all valid. Funding tx -> Refund tx, but also Bob can spend the Funding tx -> Bob's spending But in the latter case, the pubkeyhash is revealed and Alice can approve the phasedtx Alice creates the funding tx, Alice broadcasts the funding tx, the refund tx uses the funding tx as its input. If Bob bails after he signed the refund tx, then Alice would wait for her refund tx to mature and then submit it. By giving control over the funding tx to the party that relies on it, I think this is they key reason that my protocol works. Having NXT involved in the process acts as a sort of an independent third party as it makes Bob's side totally atomic and with one side totally atomic it is possible (just barely) to make Alice's side secure. So what is the fundamental problem? James |
|
|
|
So if Alice is trying to cheat by making the funding tx invalid
The known problem is the refund transaction being invalid, not the funding transaction. Bob quits, and Alice has no valid refund transaction. (I didn't read your protocol carefully, but there is a fundamental problem with a refund transaction, at least at the moment.) |
|
|
|
4. Alice verifies the refund is proper and if it is, broadcasts the funding transaction, which creates a spendable output
Bitcoin refund transactions have a known problem. A refund transaction works only for a specific txid, but the funding txid included in a block can be something else (malleability), which would cause the refund transaction to become useless. Do you have a solution for this? I dont think there is a problem with the way I am doing it. require Bob to wait for the funding tx to be confirmed in the blockchain. At that point malleability is not an issue. So if Alice is trying to cheat by making the funding tx invalid, Bob never spends the funds (since the funds arent there he cant spend them anyway) and as long as he never uses the onetime address (prior to finish height), then his side of the tx within the NXT phased tx will never get confirmed. The sequence is: Bob sends Alice the pubkeyhash and a phased tx that can only be approved when the pubkey to that pubkeyhash is revealed and this must happen for Bob to be able to spend the output. The unspent output is created by Alice, but only the unsigned txbytes and the txid is sent to Bob. He can then send to Alice a signed refund transaction using the 2of2 multisig side. Alice verifies everything is good at this point she has a fully signed refund transaction, but she cannot submit it to the network yet as it is timelocked. At this point if she fiddles with the funding txid taking advantage of malleability, then she is just making it so that she cant get her refund, so it doesnt seem to make sense for her to do. And even if she did, Bob wont spend the funds until it is in the blockchain. The edge case is that it gets into the blockchain and then reorgs, giving Alice a chance to make it malleable, but Bob already disclosed his pubkey. However, Bob controls the timing of his spend (up to timelock deadline), so he can wait until he is comfortable with the risks. The malleability is a nasty issue, but unless anybody can find a specific malleability that breaks the protocol, it would seem that I have solved this. Alice is the one that creates the funding transaction and the refund will be based on the txid for this, so it is only Bob that is at risk and he controls this by making sure there are enough confirms. Does anybody see a malleability issue that isnt solved by the protocol? James |
|
|
|
|
Based on Tier Nolan's idea, I have made a way to atomically trade between BTC and NXT/NXTassets. I should be able to combine two such swaps so effectively a BTC <-> ALT (that supports p2sh) would be able to be done.
I lobbied for NXT to support pay on reveal of secret (to specific destination) where the funds are locked using rmd160(sha256(secret)) and it is released when the secret that hashes to that value is submitted.
It took several attempts to solve this and there could well still be some edge cases, and this will be going into InstantDEX as a meta-exchange called "wallet". So best to find any flaws before it goes into beta test.
Here is the protocol:
0. Alice and Bob agree to the terms of the trade and share the pubkeys of their published address. Bob sends the rmd160(sha256(onetimepubkey)) to Alice along with a NXT release on secret linked to the same hash.
1. Both calculate the same p2sh address which allows redemption via 2of2 multisig or normal spend by Bob's onetimepubkey
2. Alice sends to Bob an unsigned funding transaction to the p2sh address for the amount agreed upon.
3. Bob creates a multisig refund tx for the entire amount back to Alice timelocked into the future, signs and sends to Alice.
4. Alice verifies the refund is proper and if it is, broadcasts the funding transaction, which creates a spendable output
5. Due to malleability, Bob needs to wait until it has enough confirms (1 should be enough?) for the value being traded. When he is satisfied, he spends the funds from the p2sh address using the normal path and this publishes his pubkey.
6. Alice submits this pubkey to release the NXT side of the transaction.
The above is the theory, in reality there are a few nasty surprises. If you use timelock and have a sequenceid of -1, timelock is ignored and it gets into the blockchain right away and the input is marked as spent immediately. If you have a sequenceid that is not -1, it is rejected with {"code":-26,"message":"64: non-final"}. So, Alice will have to keep in pocket the refund transaction and make sure to submit it if Bob hasnt revealed his pubkey.
This was from a manual run:
Alice addr:14XrJHhqMvDszMMwKR2d6u5PPvDeRieQoG -> 03b4143b6e7a064a78bc66dab0ca72251fea3d6fd8db1f4c48b91996d7af62dd05
Bob addr: 17Y5rr67RpTtuCd929dS6muyKZmjqJZQpr -> 037387677a21b8ebb472ff2d00892098dcd990a9a21b09b8e22aefece8b1cbbdc0
Bob's onetime addr 1NBKFDmmHSpSzFnP9bX5bDWnm9zqD6nUv4 -> 03c8a7e64c763e908549aa0f93974ab346a559b486eba32bf14338542b4282b916 -> e84e0808b8cd32c38fa2093a490efabc6be53d7a
Both can now calculate p2sh address of 37FsSwJ59z5UuRjNFjtfNYWVFquBEsUGHC from the redeemscript:
OP_IF OP_2 03b4143b6e7a064a78bc66dab0ca72251fea3d6fd8db1f4c48b91996d7af62dd05 037387677a21b8ebb472ff2d00892098dcd990a9a21b09b8e22aefece8b1cbbdc0 OP_2 OP_CHECKMULTISIG
OP_ELSE OP_DUP OP_HASH160 e84e0808b8cd32c38fa2093a490efabc6be53d7a OP_EQUALVERIFY OP_CHECKSIG
OP_ENDIF
I just combined a standard 2of2 and standard pubkeyhash into an conditional, but having never dealt with p2sh till this weekend, nor with signing of bitcoin tx, it was quite a lot of work to get this working as there doesnt seem to be any real support for custom p2sh scripts. Anyway, thanks to jgarzik's libbcoin, I was able to get the signing working in a day and stumbled about figuring out the "obvious" things about p2sh scripts.
[As an aside, if there is a way to verify that e84e0808b8cd32c38fa2093a490efabc6be53d7a is from the third pubkey of a 2of3 multisig address, then there would have been no need for any custom redeemscript. Just normal spends to a 2of3 multisig would have worked (with bob having 2 of the three addresses). Unfortunately I think it is crypto hard to go from msig address + pubkeyhash and 2 of 3 pubkeys to the third pubkey. And if that is not possible, then Alice has no way to know that bob didnt just give her a bogus pubkeyhash]
Bob sends to Alice: e84e0808b8cd32c38fa2093a490efabc6be53d7a
NXT tx: 1117487717739855000 hashed_secret: cc863b881f35bbeca374b25d018d4e17dc4aa19b Hash: RIPEMD160_SHA256
and Signed refund tx in pocket: 0100000001a9b3602a28960f1d855d1f52eea54f5e8b6fff469d54083ce433962b1c16dfe100000 000f800483045022100d1439b9170a6d14e07dc6a11dd5c1aab80df302fe4f1de77e12c7859ba20 361f02202dcc946b75995b62fb798b68e9bd443988c4004187f3c5cae52831b9415a712c0147304 40220754d43345edbeffd25cdfc6cbed16f59b1ef25c02092ff1752f0386e6a624e3d022075ef75 78ccb2bbd0a8c58394ed7e4c5803b6ee66691623342fe19862146fda9f01514c6363522103b4143 b6e7a064a78bc66dab0ca72251fea3d6fd8db1f4c48b91996d7af62dd0521037387677a21b8ebb4 72ff2d00892098dcd990a9a21b09b8e22aefece8b1cbbdc052ae6776a914e84e0808b8cd32c38fa 2093a490efabc6be53d7a88ac68a510ec550130750000000000001976a91426be0216d0089626b3 fc3a81f7d844f31a47e0fd88ac34b20500
then Alice broadcasts funding tx e1df161c2b9633e43c08549d46ff6f8b5e4fa5ee521f5d851d0f96282a60b3a9
Bob sees it on the blockchain and spends: 176026872b52b952c4649ee0b44026f87e2282aaaea7994117659a699662ae0a which reveals 03c8a7e64c763e908549aa0f93974ab346a559b486eba32bf14338542b4282b916.
Alice see's Bob's spend and submits an NXT phasing approval tx.
Prior to Alice funding the p2sh address, at worst some of Bob's temporary NXT reserves are held up for a time. After the trade is funded, we have a few cases:
a) Bob spends, Alice approves, both are happy
b) Bob doesnt spend to his address, then after timelock, Alice is able to submit the timelocked refund
c) edge cases: ?
clearly the timelocks need to be set properly, maybe 10 BTC blocks ahead and make it double the estimated time on the NXT side
All steps other than 5, can happen in seconds, so this is a BTC block timeframe in the mainstream case, 10 BTC blocks in the refund case. Not bad for a fully decentralized trade.
Once I verify a timelocked tx I am making can be submitted after the specified block, then I will fully integrate this into InstantDEX
James
|
|
|
|
Hello!
I have security issue. For example I prepared p2sh address, created rawTx and signed it. As a result, have got tx hex with status 'true'. Can I share final tx hex ? Can some body decrypt final tx hex and get private keys and destination address ?
BR!
as long as you used high entropy R value, your privkey should be safe. However, the destination address should be viewable by anybody that does a decoderawtransaction as it isnt encrypted and just packed in the txbytes https://en.bitcoin.it/wiki/Transaction |
|
|
|
With ramchains I have encoded all unspents (actually all addresses and txids too) in a 32 bit integer (rawind). 4 billion should be enough for a while, though it will need to be expanded in size in a few years for some of the tables. Internally all operations are 10x (or more) faster due to just dealing with small integers. As long as this is used internally, it actually doesnt matter about reorgs where the renumbering that will be different on different nodes. However, by having a strict ordering of each block, txid within a block, vin and vout within tx, then given that all nodes are in consensus then all the 32 bit rawinds will be in consensus. Since the exact value associated with each rawind is not needed as much as the rawinds themselves, the actual values can be stored in a memory mapped file without any overhead for indexing since they are fixed size. Just multiply the rawind by the itemsize to get the offset in the file. The total size of all the rawinds with enough information to construct multisig spends and update all address unspent balances in realtime, it is just several gigabytes and even counting all of the data, it is around 10gb, so it achieves a nice space savings, especially with about 70% of that in memory mapped files and not using up RAM. However I dont have this as the native block format yet, so it is in addition to the standard blockchain. On top of the ramchain data structures, I have made an Lchain, which is a snapshot every 1000 blocks of the state of all the tables, along with a cumulative SHA256 for all changes to the state of the tables. This allows for different nodes to verify consensus of the exact state of all the internal tables at specific blocks, via a combined ledgerhash and if there is a discrepancy, the exact table that is mismatched is identified. Internally, each block generates events that change the state of a dozen different tables. So the state at block N+1 is the state of block N as modified by all the events in that block. By having a snapshot every 1000 blocks, the state of any block can be recreated with an average of 500 blocks of event updates. If all nodes are running Lchains, then the nodes can bootstrap by verifying getting the 370 Lchain snapshots in parallel and then also getting the events between each snapshot. I dont think it would need to do it redundantly (except maybe the most recent ones), as each snapshot must match exactly. I dont have this bootstrapping coded yet, but once it is in place, then the blockchain storage requirement for each node can be reduced by 90%+. The way to do that is to have each node archive the Lchain events between 4 random snapshots and the next one. [all nodes can easily store all the 370 snapshots as they are not very large] Since the archive will be decentralized with TOTALNODES/100 coverage, this seems adequate, though some archival nodes would probably want to keep a complete history. This way, all nodes can have a complete distilled blockchain and the ability to reconstruct the total state as of any block quite efficiently. I am quite busy with my projects and I dont think I will have a chance to improve the ramchains/Lchain codebase for a while, so I hope some other devs will be interested. With improvements in this area, a lot more transactions will fit into 1MB. James https://github.com/jl777/btcd/blob/master/libjl777/plugins/coins/coins777.chttps://github.com/jl777/btcd/blob/master/libjl777/plugins/ramchain/ramchain.c |
|
|
|
there is no way to predict which SN will get the next transaction as it is based on human behavior
Ahem. You need to prove mathematically and holistically that is a random process and not subject to game theory. That is essentially the fundamental problem with PoS, its entropy is bounded unlike PoW where the entropy is external. How does http://blog.cr.yp.to/20140205-entropy.html relate to the assertion that bounded entropy is bad? Bitcoin's reused R value attacks arise since it requires new entropy for each transaction, while with the curve25519 this does not seem to be the case. James |
|
|
|
That still doesn't show an economical incentive to stay on the weaker chain.
Maybe you could describe it further? (That is not a rhetorical question. I am really curious.)
The fork will happen if 75% of blocks are mined by miners who support it. This is a quite silly indicator because it's not the miners who decide what changes are good/bad. NotBitcoinXT makes it worse, we can't trust even the number of blocks. What an average Joe will do? A sane average Joe will try to sit on the both chairs until he clearly sees what happens. And the most rational behavior is to follow the guide to maximize profit (minimize loss). I strongly disagree. No sane person will follow your guide, since it is just highly speculative. And again, there is no economical incentive for merchants not to go to the stronger chain. They most likely will just follow the lead, long before the split happened. And as I also said before NotBitcoinXT is a bad joke, no serious business will use it. how is getting corecoin and XT coin both, instead of just one of them speculative? It would seem that someone could make some sort of mathematical proof that (corecoin + XTcoin) >= corecoin and also that (corecoin + XTcoin) >= XTcoin Then again, math is my weak point so I must be missing something James |
|
|
|
It's hard to believe someone with Cryddit's could-be-a-Satoshi level abilities would really not understand the diff between ~100% consensual forks and one predicated on a partially-faked "75%" (with 25% + NotXT spoofs strongly objecting).
I can't imagine the chaotic outcome that you predict. The "fake XT" software is a childish idea; miners are in the game for real money, not for lulz. Yes, the thing about unpredictable outcomes is that their outcome is difficult or even impossible to predict. I blame the unimaginable chaos for that.  Besides the lulz, shorting GavinCoin (especially with element-of-surprise proportional leverage provided by NotXT) can make a lot of money. As the big fat buttcoiner brain bug, are you siding with XT b/c enemy of enemy equals friend or what? I did see your 'I actually like BTC but am very skeptical' and admire your financial conservatism BTW...  I never thought there will be the day I agree with icebreaker |
|
|
|
I dont understand how if 1MB bitcoin survives (as losing fork) how there will be a growing backlog of unconfirmed tx?
Because the transactions issued by clients are in principle executable in both branches. Only a few transactions will be specific to only one branch: namely, those that involve coins that were mined in that branch, after the split. The incoming traffic is now ~120'000 transactions per day, on average. For the last 12 months it has grown almost linearly at ~5000 tx/day per month. If it continues growing at the same pace, by Jan/2016 it wil be ~150'000 tx/day. The effective capacity of the bitcoin mining network, revealed in the recent stress tests, is ~200'000 tx/day or ~1400 tx/block. Suppose that the miners split 90:10 between the 8 MB and the 1 MB branches. The 8 MB branch will have ~130 blocks/day, which will have to carry ~1150 tx/block -- which is still less than the effective capacity ~1400 tx/block. There may be "traffic jams" at peak hours or peak days, but the backlogs should clear after a few hours at most. On the other hand, the 1 MB branch will have ~15 blocks per day only. Each block would have to carry 10'000 tx, which is way over the capacity ~1400 tx/block. So, every 10 minutes, on average, 1400 tx will be confirmed, and 8600 tx will be added to the queue. The backlog will only begin to clear when the difficulty is readjusted and the block rate returns to ~10-15 min. The adjustment happens every 2100 blocks, with is normally 2 weeks but in that chain will be 20 weeks. the XT miners will aggressively attack the original to kill it, then it seems the tyranny of the majority. To be able to make the real bitcoin into an altcoin.... I never imagined this would be possible
Well, right now the 5 largest miners (who have ~70% of all hashpower) could cooperate to starve all the other miners, and take 100% of the block rewards intead of just 70%. Or they could do much nastier things. Let us not quibble over exact details, since it is not possible to predict exact amount. So using your numbers of 90/10 split: "The backlog will only begin to clear when the difficulty is readjusted and the block rate returns to ~10-15 min. The adjustment happens every 2100 blocks, with is normally 2 weeks but in that chain will be 20 weeks." OK, it is 6 months later and blocks are back to normalish rates. With all of the existing bitcoin infrastructure are you saying that it wont be a viable altcoin? That LTC is worth more than old bitcoin? That NMC is worth more then old bitcoin? Did you consider that there are a lot of people that use bitcoin and if dont update to a new wallet and they see that they received an old bitcoin, maybe they just accept it. doesnt even the Mtgox bitcoins sell for amounts > $0? To be so confident that multibillion dollars of existing value will just vanish within weeks, this just does not pass the common sense test. James |
|
|
|
a forced global upgrade across thousands of independent entities, in two weeks.
Yes, two weeks is rather short. Two months would have been better. I suspect that the 75% will be reached very quickly, or never. I suppose that Mike was afraid of some PR counteroffensive that would convince many 8 MB adopters to switch back to 1 MB, if the grace period was too big. After all how hard can it be to force everybody to adopt the new bitcoin, even though they dont agree with it?
Once 75% of the miners have agreed to switch to 8 MB, agreement is irrelevant. The remaining miners and the major services will choose to switch before the 8 MB limit is enabled, even if they didn want to, otherwise they will lose money. They will be aware of the event and capable of upgrading in time. But even you agree that there will be an altcoin created out of this and that altcoin will have nontrivial value, probably more than LTC, certainly more than NMC.
No, I don't agree with that. Litecoin is a functioning coin, that non-experts can use as easily as bitcoin, with no confusion. It has its own exchanges, a large user base, etc.. (It is even used by bitcoin arbitragers, I read somewhere, to quickly transfer value between exchanges, due to its shorter block period.) The "1 MB bitcoin", if it survives at all, will have a very long block period, a huge and growing backlog of unconfirmed transactions, practically no services and exchanges -- and very few people will know how to handle it. Indeed, if the 8 MB sizelimit prevails, its miners may find it worthy to put some of their hashpower to the task of jamming the 1 MB branch, to minimize confusion of clients who failed to upgrade, and to prevent its use for scams. I dont understand how if 1MB bitcoin survives (as losing fork) how there will be a growing backlog of unconfirmed tx? The assumption is that if it loses, fewer people will use it, but maybe if all the miners abandon it CPU mining would become viable again. As long as the diff readjustments happen, the blocktimes will eventually get back to the 10 minutes per block. but if as you say that the XT miners will aggressively attack the original to kill it, then it seems the tyranny of the majority. To be able to make the real bitcoin into an altcoin.... I never imagined this would be possible James |
|
|
|
if XT wins, does this mean all the current alt coins that relies their chain security with merge mining with bitcoin core will loose substantial network hash and end up dying along with the bitcoin core.
so asap get out of the alts that have merge mining with bitcoin core if XT succeeds or can they merge mining with both core and XT?
i think right now the safest bet is ethereum, it came out just the right time for the shaken btc world, people will look into eth for hope that it will take over most of btc marketcap.
ps i have no eth, only have nxt.
I would think that all merge mined altcoins will still work with which ever BTC survives, maybe each such altcoin might need to hardfork too. not sure on the details, but i dont see this as any insoluble issue for merge mined alts |
|
|
|
I dont know the stats on the last bitcoin hardfork and how long it took for "everyone" to upgrade, but my guess is that it took a bit more than 10 minutes
James
Was the last fork as dramatic and full of emotion as this one? Did it involve this much at stake? This much accusation and handwringing about selling out to the fiat players? I mean seriously... comparing THIS fork to one in the past is like comparing getting mad at your wife because she was flirting to how you would feel if you caught your wife in bed with someone. LOTS more emotion being generated in this fork it seems to me. Am I wrong? Did as big a part of the community DIRECTLY THREATEN to intentionally split the chain forever? C'mon. Apples to Oranges. Absolutely! Which takes me back to the reason I made the Cluster F#<K comment which is the fact that if this "Dual Universe Doubling" theory (sorry - I still say it is theory - although possibly I believe a little more after your explanation) is real - then I now understand that this creates a situation that bitcoins could end up flying across the Parallel Universe Rift occassionally, reeking havoc, causing bitcoins to be lost etc. That was proposed as an earlier poster out as a "relative" rarity - but if this split LASTS, the longer it lasts, the bigger the chance for bitcoin loss - and speaking from a simply societal common sense macro picture standpoint - this is, again, a COMPLETE Cluster F#<K for the future of Bitcoin. Mass Markets and Media don't like confusion and uncertainty. And this will do it. If bitcoin was fully centralized and had a command structure where everybody had to obey, then maybe 2 weeks for a global update would be ok, though still on the edge of doable. As it is, with the protocol design, the likely outcome is that the combined market cap will be split between the two variants as long as either has any chance of winning and even after a clear winner emerges, the remaining altcoin (be it original or XT) will still hang on for months What I dont understand is why is this ultimatum sort of mechanism even existing? |
|
|
|
|
Show Posts
