1) PoW is a bad cryptographic protection
2) a block chain is way too much severity of consensus (we don't need the EXACT ORDER of transactions)
3) signatures of different entities can validate transactions much better/cheaper/faster than by putting them into a block that needs PoW protection.
In other words, that most of the principles of bitcoin are, well, improvable. Which is no surprise because it is the oldest, and very first tech that is used.
1. PoW has nothing to do with blockchain size. a 1Kb block or a 1Gb block both result in a 256bit hash. PoW only needs 256bit hash, and doesnt care about blocksize. (hint: you wont see a hard drive in an asic) its about timing I wasn't making that remark in direct relationship to the current subject. PoW is bad cryptographic security, because the "good guy" doesn't have any advantage over the "bad guy". It is simply the one that wastes more that wins. I only mentioned it because digital signatures do have the advantage that PoW doesn't have: the one with the secret key can easily sign, and it is essentially practically impossible to imitate such a signature if you don't have the key. you really need to step back and really understand bitcoin hashpower alone is meaningless.. it doesnt matter if one pool has 50000 exahash and another pool only has 50petahash. the nodes will reject whatever block doesnt follow the rules. Sure, and if there are no other blocks available, then those nodes just stop working. The point is that blocks that are made by the "bad guys" follow the rules perfectly and in PoW, the rule is then that the bad guy wins. The rule in PoW is that someone with sufficient hash rate can undo all the transactions of the 50 last blocks, by just presenting an alternative chain with more PoW than in these 50 blocks. The rule is to orphan the "good" 50 last blocks. If all miners now decide to follow the rule (what else could they do ?), and build only upon the chain (the bad guy chain) with most PoW, then that's the only chain that is available. If your node doesn't agree, then your node will simply stop. I've been explaining this 50 times to you, but you don't want to understand this, because you are stuck to the myth that non-mining nodes have power. |
|
|
|
I remember from my courses in intellectual property that there's a fundamental difference between the way US and for instance, European patent offices work ; even though the end result is the same. The US patent office actually accepts almost any patent that is not blatantly inappropriate (in form or in content). It works mainly as a kind of attorney, where they act the fact that you've deposited a patent. But it has no legal standing, apart from the fact of being deposited. It is only on the very first case in court that the validity of the patent is really tested. European patent offices are much more restrictive in their attribution of a patent, and they essentially only accept a patent if they think that it has good chances to be considered valid the first time it is tested in court. Ultimately, all patents are only tested in court. Only, a US one is totally open and can just as well be rejected as accepted by the judge as valid ; in principle that's the same in Europe, except that the patent office already looked in much more detail at it, and so it has much more chance to be upheld in court if ever the patent was granted. Although, in the end, it is always the judge who decides. So it is probably much easier to patent the trademark "Face" in the US than in Europe, but that doesn't mean that it will be upheld in court. |
|
|
|
Maybe the ASIC circuitry can be patented. I would highly doubt that the mathematics of using a cryptographical scheme more cleverly, can be patented.
Yes, cryptography can be patented. I know. But you cannot patent a way to USE a public cryptographic scheme if that is well-known knowledge. There's nothing special in using the publicly known extention attack of the Merkle-Damgard construction. |
|
|
|
you have to be shitting me....
most poeple think 90% of the bitcoin TX are spam
they complain that "spam" is creating fee pressure.
remove the "spam" and you think we'll fill block with nothing but Big TX willing to TX at anycost?
ya right,at that point poeple are sending there hoards to poloniex so they can buy the digital cash they were promised.
Spam is nothing else but a covert way of the miners to lower the effective block size. It costs them, on average, nothing, if they spam according to their own hash rate (they pay the fees to themselves). If miners spam, it means that they are of the opinion that the blocks are already too big for their optimum profit, and need to lower the available user block room. Note that miners are the only entities that can spam without a cost. All others that would spam, have a cost, the fees of the spam. Miners don't, because they get them back. Note that spam is a self-regulating block size limiter that settles dynamically between miners. A miner that spams more than his fellows will pay net fees to his fellows ; one that spams less will receive fees from his fellows. So spam is only interesting as a "common good" for miners if they can settle on the right amount of spam to squeeze the maximum of fees out of the users. This is BU, but on the low side. Bitcoin's game theory is one big hell of a clusterfuck. |
|
|
|
 i made a few edits to the stock graph to better illustrate what i'm saying as block size goes up fees go down, but fee revenue is at its highest at 2MB, because science. The error in this plot is that you think that fees are elastic. Fees are VERY INELASTIC, meaning your blue curve goes to the sky on the left. If only 10 transactions are possible, people will be paying HUGE fees in order to obtain one of the 10 places. The guy wanting to transact 10000 BTC for a huge cocaine deal will need to get the transaction through, no matter what, or they'll get him, so he'll pay 200 BTC of fee. 10 of these transactions, and you earn 2000 BTC per block in fees. From the moment that you relax, fees will drop drastically per transaction, much more so than your straight line suggests. And then you see that the optimum is on the left side of the plot, because fees rise much faster than 1/block size, and drop much faster with block size. i think its hard to incress fee pressure without increasing TX demand and simply limiting blocksize. Demand comes from people "locked into" bitcoin, and NEEDING to transact (the only thing bitcoin is good at). If you HOLD bitcoin, the only reasonable thing you can do with it, is transact, sooner or later. That's the demand. at one point fees are so high a lot of potential TX can't happen anymore, and this removes some fee pressure,
Uh, no, that is exactly the pressure. All TX have to happen. If they can't happen, or aren't needed to happen, then the bitcoins involved in them are useless. If you mean, however, this will limit bitcoin's usage to only big transactions, you're perfectly right. Bitcoin with small blocks is not a payment system that can be used for small transactions, only for big ones, at low transaction rates. In as much as this has an incidence on the bitcoin market value, this will probably not even matter. If the fees increase 10-fold, the market cap must fall 10-fold before this starts to be negative for the miners. So squeezing fees out of users, even if this crashes the market price, is still interesting for miners if the inelastic wall of "I absolutely need to get my big transaction through" is steeper than the price crash. |
|
|
|
Apparently, Jihan Wu has been covertly using some patented exploit called asicboost to gain 20%+ efficiency on his hardware that’s incompatible with SegWit. It all makes sense now. Hope he gets his ass sued off.
Maybe the ASIC circuitry can be patented. I would highly doubt that the mathematics of using a cryptographical scheme more cleverly, can be patented. After all, this is just using a smarter way of scanning through the hash space. It is a bit as if you could take a patent on the fact that you don't have to re-compute the Merkle hash each time you want to use a new header nonce. That's all there is to it: not re-doing a computation that is not needed in a well-known cryptographic weakness in the Merkle-Damgard construction (extension attack). The idea is that in the iteration of the hash compression function, you don't have to re-do the previous hash calculations if only the last block changes (or if you want to add an extra block, hence the name "extension attack"). Depending on the application, this extension attack is a problem or not. For a normal hash application, it isn't a problem. But it can speed up attacks (and hence, proof of work). This is well known and in several crypto intro books. It is just one more "error" in the whole of bitcoin's cryptography. |
|
|
|
1) PoW is a bad cryptographic protection
2) a block chain is way too much severity of consensus (we don't need the EXACT ORDER of transactions)
3) signatures of different entities can validate transactions much better/cheaper/faster than by putting them into a block that needs PoW protection.
In other words, that most of the principles of bitcoin are, well, improvable. Which is no surprise because it is the oldest, and very first tech that is used.
1. PoW has nothing to do with blockchain size. a 1Kb block or a 1Gb block both result in a 256bit hash. PoW only needs 256bit hash, and doesnt care about blocksize. (hint: you wont see a hard drive in an asic) its about timing I wasn't making that remark in direct relationship to the current subject. PoW is bad cryptographic security, because the "good guy" doesn't have any advantage over the "bad guy". It is simply the one that wastes more that wins. I only mentioned it because digital signatures do have the advantage that PoW doesn't have: the one with the secret key can easily sign, and it is essentially practically impossible to imitate such a signature if you don't have the key. 2. you do. to then have a checkable history by just knowing the latest contains data of the previous. thus no need to constantly be checking everything, because the previous is locked.
I'm not saying that a block chain is "not good enough". I'm saying it is way too severe. You don't NEED full block chain ordering in order to verify transaction validity. It is much harder to come to "exact order consensus" than it is to come to "correct transaction set consensus". The order is not needed. If you have a consensus on a BAG of valid past transactions (no matter what is the order), that's good enough to find out whether a newly proposed transaction is valid or not: 1) do all inputs correspond to an existing output in a transaction in the bag ? 2) do none of these inputs appear in any existing transaction input in the bag ? That's all that is needed. No order needed. In the bag, or not in the bag. Mathematically, you only need the SET of transactions, you don't need the sequence. But of course a sequence is (more than) good enough. But it is a complication that is not needed. 3. and as we both pointed out signatures of different pools become troublesome of users seeing 20+ pools all with different signatures, plus to offset things like propagation.. the timing of signing then becomes less instant to give room for the network congestion to breath.
which then brings back the issues of "but its not fast enough if your waiting 1mb-10min in a grocery store checkout line hoping a confirm happens soon
Indeed, the "solution" in this thread doesn't bring any solution to any serious problem, but adds problems. |
|
|
|
Randomness!
There are some super smart guys on this forum who think they can predict coins like LTC due to actual facts. It's almost hilarious if it wasn't so pathetic. The truth is 90% of big moves are irrational and based on intangible human moods and whims.
I've made more money than most simply sticking my finger in the air and testing the mood, often being contrarian rather than following the crowd. But seriously logic is the last thing you want to follow.
Efficient market hypothesis. But not as it is usually understood, but rather that the information (even "irrational information") is already included in the price, and that you can't know better than the market, but only gamble on it. |
|
|
|
There is really no difference between putting all these transactions in one big block or making all these "clusters".
to put them into 600 clusters allows for 'semi-confirm' of 1 second. instead of waiting 10 minutes. drawback is the user needs to see 20 different signatures (from all the pools) i explained this already...! Then you are just doing a kind of "20 masternode scheme" of DASH, with the "pools" electing themselves as masternodes. This is nothing else but the instant pay mechanism of DASH, with informal master nodes instead of protocol-defined masternodes. In other words, bitcoin then has 20 certificate authorities, signing the validity of transactions. Once you do that, why not simply use PoS ? Why waste electricity on mining, if you trust miner signatures ? They could simply sign off the main block too, in a PoS scheme, instead of wasting electricity on PoW ! yep i explained it..
Ok, sorry, I misunderstood your post as "being in favour" of this scheme, while it is a total clusterfuck concerning bandwidth etc... If 8 MB blocks are a "bandwidth issue", then 20 times the block size is most probably a "bandwidth issue" ! However, what is positive in these discussions is that people are slowly, very slowly, discovering that: 1) PoW is a bad cryptographic protection 2) a block chain is way too much severity of consensus (we don't need the EXACT ORDER of transactions) 3) signatures of different entities can validate transactions much better/cheaper/faster than by putting them into a block that needs PoW protection. In other words, that most of the principles of bitcoin are, well, improvable. Which is no surprise because it is the oldest, and very first tech that is used. |
|
|
|
i made a few edits to the stock graph to better illustrate what i'm saying as block size goes up fees go down, but fee revenue is at its highest at 2MB, because science. The error in this plot is that you think that fees are elastic. Fees are VERY INELASTIC, meaning your blue curve goes to the sky on the left. If only 10 transactions are possible, people will be paying HUGE fees in order to obtain one of the 10 places. The guy wanting to transact 10000 BTC for a huge cocaine deal will need to get the transaction through, no matter what, or they'll get him, so he'll pay 200 BTC of fee. 10 of these transactions, and you earn 2000 BTC per block in fees. From the moment that you relax, fees will drop drastically per transaction, much more so than your straight line suggests. And then you see that the optimum is on the left side of the plot, because fees rise much faster than 1/block size, and drop much faster with block size. |
|
|
|
ok this is how i see it  We already know that whatever is in purple gets hashed. And that the hash is thrown to ASICS to make a more secure hash with a bunch of zero’s at the start there are [80bytes of data] that is unused in a block..
 now imagine that we used that 80bytes for something as simple as a signature( sidehash).. more precisely a signature hash of data signed by the pools own chosen coinbase(reward) keypair. and then hashed the same as before. now you may well be asking what 'message' could that signature be part of
 the message could be a cluster of tx's and a signature belonging to another previous cluster of tx's.. and so on.. and so on
so how would it work.  well imagine every second new tx's are signed into a cluster (extended block) by the pool making the main blockso timeline, using just 3 clusterblocks/extended blocks for example previous block solved. Previous block hash is added to the new block aswell as 2500 tx added to the new block. 2500 tx added to sideblockA and signed as A by that pool 2500 tx and signature A added to sideblock B data and signed as B by that pool 2500 tx and signature B added to sideblock C data and signed as C by that pool sideblockC signature added to block and the block is hashed and PoW’d as usual all within the same 10 minute window
possibilities, because signatures are involved. clusters/extended blocks can be signed once a second, meaning it can make 600 cluster/extended blocks to allow a tx to get semi confirmed in second of being seen by a pool. yes them 600 clusters instead of 1 extended block may have a 42-48kb extra bloat(600 signatures), but then you gain the feature of 1second semi confirmation instead of just extra tx per single block waiting 10 minutes for a confirm. issues: there are 20+pools so your TX might be in cluster/extended block antpool: 350 of the 600 blocks signed by antpool or 123 of the 600 blocks signed by bitfury or 500 of the 600 blocks signed by btcc all because in the 600 seconds between mainblocks each pool has their own 600 cluster/extendedblocks and tx arrangement that pool has solely/independently chosen resolution: user receives atleast 20 pool responses that the users tx is in a cluster/extended block somewhere in each pools issue: this then causes alot more data flying around the network of 'soft confirming' 12,000 cluster/extended blocks (20 pools*600cluster/extended blocks each) issue: logical minds will think screw it lets make it 60 clusters/extended blocks with a 10 second semi confirm. practical minds then argue that although 10 seconds is better than 10 minutes. there is still 1200 extended blocks flying through the network. and 10 seconds is now slower than visa's 'touchless' NFC swipe and go payment method. my opinion. 1. just using 1 extended block that can hold an infinite amount of tx's is a way of 'going soft' with dynamics. but then the nodes should have a dynamic useragent flag that pools find a consensus of nodes of, to know how many tx's should be put in this extended block where it wont cause issue to the majority of nodes. 2. by using it to also 'speed up' the confirm by having MULTIPLE extended blocks signed every second/10seconds/whatever.. is better than wrecking blockrewards/difficulty/halving schedules like some other lame proposals of just reducing the 10min average to 2minutes, 1min, 30seconds. but again nodes will need to have rules of acceptability to keep pools inline so that pools do not overdo it. i could continue waffling on, but ill stop here for now There is really no difference between putting all these transactions in one big block or making all these "clusters". Note that as long as a pool hasn't built all his clusters together, it CANNOT START HASHING on the main block, because it doesn't know the final signature to include. In fact, the "list" of signatures is more wasteful than the "Merkle tree" hash or signature that is used within a big block. So from the miner's PoV, there is no difference between making his list of linked clusters, to include the final signature into his block on which it will start hashing, or to make one big block with a Merkle tree of hashes (his list is just slightly slower). The "signatures" of the pools are absolutely no guarantee that the whole series will not be orphaned if another pool wins the main block. And, as you point out, not only do the individual transactions fly through the network, but all the *different versions of clusters of all pools* fly through the network with their signatures. That is a large multitude of traffic as compared to one big block. The factor is the number of competing pools (not only the big ones !). So if you see a transaction flying by, and there are 30 mining pools active, you will see 30 different miner clusters containing this transaction fly by within a second or so... You will see this transaction 30 times, you will have to check the validity of 30 clusters, and finally, only one of them will make it as the 25th cluster in a row by a given pool that won the race for the main block. And maybe it is a main block that doesn't, finally include that transaction in one of its side clusters despite the 29 signatures you saw, because these 29 pools that signed it, didn't win the main block. Essentially, if there are about 30 active mining pools, the spent bandwidth is multiplied by about 30 as compared to a single big block. |
|
|
|
Very doubtful.
Where are all these extra lateral blocks going to be stored?
Reminds me of pseudoscience.
Geez.  You never use a Spread sheet Before?Block #52652 A | Block #52652 B | Block #52652 C Block #52653 A Block #52654 A Block #52655 A | Block #52655 B They would be stored in the blockchain like the rest of the blocks. Tell me, do blocks B, C etc... also come within the same 10 minutes as the A-blocks ? Do they also have block rewards ? Do these rewards increase bitcoin's inflation ? If yes --> Mwhahaha If no --> Who mines them ? Does block A have to certify (Merkle of blocks ?) blocks B, C etc.... and hence "wait for them" ? Is there only one miner of blocks A,B and C, namely the one mining block A and getting its rewards ? What's then the difference if the one mining block A is also including the transactions of B and C into block A ? Since no one has wrote the code yet, Just my speculation: Block B & C would be broadcast as quickly as possible, so in the same 10 minute window. ZERO BLOCK rewards for the lateral Blocks, however the Miner would receive the transaction fees for the additional blocks. 1 Miner for each Block #, and the A,B,C or more that follow You are correct , 1 large block A could contain B & C But if it is not a miner, who will "broadcast" blocks B and C ? Will this not be a cacophony of many people broadcasting many slightly different blocks B and C ? Normally, only a miner can "broadcast" a valid block (everybody can claim to be miner and broadcast a block with wrong proof of work of course, but that's quickly discovered in the block header). But who will broadcast blocks B and C ? If it is the miner of block A, he's just cutting his big own block in a few pieces.
The Lateral or adjacent blocks would have to match a checksum included in the main block or fail inclusion into the chain.
Well, then he could just as well make one big block, instead of splitting his one big block he's alone in deciding about, into several small ones. Difference is you have to verify the block, so doing it Clif's way means you can validate a smaller block faster, and only use the lateral blocks when the it is full of transactions. The Additional blocks would be more important , if they can run past the next main block that is found .
Meaning someone tries to spam the network, and a main block plus 20 lateral blocks, eats up the entire spam attack,
and then the next block is only 1 main block again.
But who is broadcasting these non-PoW, non-PoS blocks ? Every node ?
Only the miner of the main block would be able to broadcast the lateral blocks and only for the block he mined the main one.So he's just putting what he'd put in one big block, in several smaller ones. Single Large Blocks can also adapt , but usually BTC miners are not lowering the blocksize now, even when they include only 1 transaction.
At some point the larger blocksizes would not be able to be verified in the time before the next block, therefore limiting the maximum size.
How are you going to be able to verify the gazillion of POSSIBLE and BROADCAST small blocks, while the miner of block A has just picked out two of them ?
Suppose that the mem pool contains, at a certain moment, 10 000 transactions. There are 5000 different ways to put 6000 of these 10 000 transactions into 3 blocks of about 2000 transactions each because there are 5000 nodes doing so, with slightly different mem pools (not sync of course). So you receive 15000 blocks from 5000 different nodes. The miner of block A has picked 3 of them, which he calls A, B and C. You will indeed find, amongst the 15000 broadcast blocks, that one is block A, another one is block B and still another one is block C. But if you don't have the time to verify the big block {A,B,C}, do you think you have the time to verify those 15000 blocks ??
Only Block A requires Complete Verification, the additional Lateral Blocks are only accepted if they match the Checksums, listed by the verified block.Of course not. There are two "levels" of verification: "header verification", and "full transaction consensus verification". Let us not forget what is the PURPOSE of a block chain: coming to a consensus of *transactions*. You want to know whether a given transaction is part of the past consensus, or not, because the validity of a new transaction depends on that. It is the only reason of existence of a block chain: knowing on what set of past transactions, there is consensus. You can check the validity of the block headers: that makes you know that: 1) the header fits in correctly in the chain 2) it has the right amount of PoW By verifying only the headers, you can verify the block chain structure, and the Merkle tree hashes included in them. But you don't know anything about the consensus of transactions this chain is supposed to bring you. In order to know that, you have to know the transactions themselves. They need two verifications: 1) the validity of the transactions themselves, for which you need previous consensus knowledge: that is, what previous transactions did we agree upon ? They provide the outputs that can be used as inputs in a valid transaction. 2) their inclusion in the consensus the miner decided upon. You combine their hashes into a Merkle tree, and you verify whether that Merkle tree hash corresponds to what is in the block header. If it fits, ALL of them are OK, if it doesn't fit, the block including its block header, is false. But if you need to know this, you need to know ALL THE SIDE BLOCKS and verify all of them. It is sufficient that one single transaction in block C doesn't work, and your block header is, in the end, false. ==> there is no conceptual difference between verifying block A only, or not verifying any block. It is A,B and C or nothing. Because a smart guy could include a transaction in block A, but "screw up" block C. If that's the case, block A is just as invalid as if, in a normal chain, the block itself were false. If you ONLY verify block A, and you think it is OK, and you accept the payment, then if it turns out that block C was erroneous, your block A is JUST AS FALSE and your transaction will not be part of consensus. The block header will turn out to be false, after all, just as if you included a double spend or a wrong Merkle hash in today's chain. Verifying ONLY block A doesn't verify anything: if block B or block C are false, this invalidates the block header, and hence also block A. |
|
|
|
Very doubtful.
Where are all these extra lateral blocks going to be stored?
Reminds me of pseudoscience.
Geez. You never use a Spread sheet Before?Block #52652 A | Block #52652 B | Block #52652 C Block #52653 A Block #52654 A Block #52655 A | Block #52655 B They would be stored in the blockchain like the rest of the blocks. Tell me, do blocks B, C etc... also come within the same 10 minutes as the A-blocks ? Do they also have block rewards ? Do these rewards increase bitcoin's inflation ? If yes --> Mwhahaha If no --> Who mines them ? Does block A have to certify (Merkle of blocks ?) blocks B, C etc.... and hence "wait for them" ? Is there only one miner of blocks A,B and C, namely the one mining block A and getting its rewards ? What's then the difference if the one mining block A is also including the transactions of B and C into block A ? Since no one has wrote the code yet, Just my speculation: Block B & C would be broadcast as quickly as possible, so in the same 10 minute window. ZERO BLOCK rewards for the lateral Blocks, however the Miner would receive the transaction fees for the additional blocks. 1 Miner for each Block #, and the A,B,C or more that follow You are correct , 1 large block A could contain B & C But if it is not a miner, who will "broadcast" blocks B and C ? Will this not be a cacophony of many people broadcasting many slightly different blocks B and C ? Normally, only a miner can "broadcast" a valid block (everybody can claim to be miner and broadcast a block with wrong proof of work of course, but that's quickly discovered in the block header). But who will broadcast blocks B and C ? If it is the miner of block A, he's just cutting his big own block in a few pieces. Difference is you have to verify the block, so doing it Clif's way means you can validate a smaller block faster, and only use the lateral blocks when the it is full of transactions. The Additional blocks would be more important , if they can run past the next main block that is found .
Meaning someone tries to spam the network, and a main block plus 20 lateral blocks, eats up the entire spam attack,
and then the next block is only 1 main block again.
But who is broadcasting these non-PoW, non-PoS blocks ? Every node ? Single Large Blocks can also adapt , but usually BTC miners are not lowering the blocksize now, even when they include only 1 transaction.
At some point the larger blocksizes would not be able to be verified in the time before the next block, therefore limiting the maximum size.
How are you going to be able to verify the gazillion of POSSIBLE and BROADCAST small blocks, while the miner of block A has just picked out two of them ? Suppose that the mem pool contains, at a certain moment, 10 000 transactions. There are 5000 different ways to put 6000 of these 10 000 transactions into 3 blocks of about 2000 transactions each because there are 5000 nodes doing so, with slightly different mem pools (not sync of course). So you receive 15000 blocks from 5000 different nodes. The miner of block A has picked 3 of them, which he calls A, B and C. You will indeed find, amongst the 15000 broadcast blocks, that one is block A, another one is block B and still another one is block C. But if you don't have the time to verify the big block {A,B,C}, do you think you have the time to verify those 15000 blocks ?? |
|
|
|
The ASIC manufacturers are not going to sell their goods to the government so the government can destroy their market.
Governments are the true makers of the rich elite and always have been. An asic producer that can sell to government always will. Hell, he can sell his entire production (larger than the hoped-for market share of "miners") to government, what producer would refuse such a contract ? The governments are bankrupt. They can't afford to battle the whales, especially as the whales of crypto grow more wealthy.
Those "whales" are small maffioso with too big egos, and killing a big crypto is lucrative when you know when. A small-sized war costs more than what is needed to spend on killing a one trillion dollar coin with 2% PoW protection. The Iraq war has cost the US *directly* one trillion dollars. What do you think 20 billion with returns would stop them. Also the whales who want Bitcoin to succeed are the same whales who are engineering the NWO, Basel rounds, and the collapse of the current financial system.
Bitcoin is part of the master plan. They won't kill their own baby.
I really don't believe that. As I said before, don't put on the back of conspiracy what can be explained by ignorance. Bitcoin is absolutely no game for the fiat system. If it stays sufficiently under the radar it may survive, but it will kill itself by PoW inefficiency. |
|
|
|
The whales will change the PoW hash over and over as necessary and bankrupt the idiots who attempt that.
They can't do that fast enough, and if you do that 3 times in a row, nobody's gonna trust your thing any more. 20 billions spend on a YEAR of attacks, remember. If you mess up the block chain for a month or so, the system is entirely dead. Nobody's going to trust it any more. It isn't just the cost of the hashrate, those idiots would have to invest in new ASICs designs, build out the economies-of-scale, etc..
That is what the whales would have to do if they want to change hash rate. That is why their threat wasn't really credible, but just got the miners scared. If you want to change a PoW scheme that *needs to deliver at the next block 20 billions worth of waste*, you need to have produced already truckloads of ASICS for that change. If not, you are delivering your change AFTER the attack open to a much much easier attack. If ever the system comes up again, for the attacker, rinse and repeat. Remember that it didn't cost him anything last time, he got his (fiat) money back by shorting. At a certain point, the whales will run out of ASIC designs. In fact, the next time, the attacker simply has to announce publicly that he shorts massively and that will be sufficient. |
|
|
|
As the value of Bitcoin transactions increases, then the amount paid for security can decrease as a percentage of transaction value.
This is why debasement can be allowed to tail off to 0 over time.
The only way your premise could be true is if Bitcoin never becomes a significant portion of the global economy.
Of course it won't. It will not be allowed to. The higher the market cap, the more geo-political interests there are to kill it, which can be auto-financed by shorting bitcoin while attacking it. The (small) French government just spent 4 billion dollars to keep Guyana calm to keep the Ariane launchpad secure. 4 billion dollars for a small/medium sized country for a relatively small geopolitical advantage. If bitcoin reaches a 100 fold market cap, at 2 trillion, it is still just a few percent of the world economy, but it will start annoying TPTB. At a 2% protection, the PoW effort is 20 billion dollars a year and hence its security level. With 20 billion dollar, you destroy bitcoin. That's peanuts. 5 times the French effort in Guyana this month, to get that thing out of the way. But what's nicer, you don't even have to spend them. You can win much more by shorting bitcoin at the time of attack, and pay back your 20 billion dollars. As you said, the tail doesn't wag the dog, and the dog is the fiat system. Moreover, you don't even need to spend value on it, by shorting you can even win a lot of value in doing so. |
|
|
|
It actually depends on how the cost of securing a PoW network scales with the market cap, if it is linear and above 1% Proof of Work is not sustainable but if it increases less than linear the inflation needed to secure the network will decrease will decrease when the orice of the coin increases.
There are two hard laws in PoW: 1) the security of PoW is exactly equal to the waste 2) the waste of PoW is nearly equal to how much miners gain, which is the cost of the system (inflation cost, and transaction fee cost). The threat model is twofold: 1) economically 2) strategically The economical threat model is that of double spending, but is ridiculous. Indeed, if ever you succeed in double spending, you will KILL THE SYSTEM, and then your holdings aren't worth anything in any case. So the danger of double-spending is largely overrated. Nobody is going to double spend, simply because if someone is going to double spend, and it works, then the confidence and belief in the system is dead, which means that the coins you took back are worthless now (there may be a window of opportunity to sell them before people realize and the market crashes, though). --> there is almost no necessity of security against double spending, because the stake holders that COULD double-spend, would destroy the value of their stake. The true threat model of a crypto is strategically: where you want to destroy the system's confidence, not because you want to obtain value INSIDE the system but because of the system's failure. That threat is worth a certain amount of value to the attacker and the system should be secured such that the cost to the attacker is larger than his incentive is worth. In fact, this threat incentive is most probably more than linearly related with market cap. It can be "outside economical", mainly through shorting the asset of the system ; or it can be "political/strategical", like promoting a rival system, or purely geo-political reasons. It is clear that these are "threshold threats". Below a certain market cap, you won't trigger these threats ; above it, you will have to face a huge incentive to break the system. You can even combine both: you can finance your political threat by shorting the system. Killing a 20 billion market cap thing is most probably not interesting for powerful agencies. Killing a 2 trillion system is. If you need to spend 20 billion on killing a 2 trillion system, that's costly ; but if you can finance that by shorting, you can even get both some financial benefice AND reaching your political goal of blowing up the system. --> the higher the market cap of a PoW coin, the higher the market cap percentage you have to waste on PoW to protect it. Right at this moment, bitcoin is OVER PROTECTED with its 2% waste cost of market cap per year. Do this times 100, and it is vastly under protected and will be killed if you keep just 2% of waste per year. |
|
|
|
Very doubtful.
Where are all these extra lateral blocks going to be stored?
Reminds me of pseudoscience.
Geez. You never use a Spread sheet Before?Block #52652 A | Block #52652 B | Block #52652 C Block #52653 A Block #52654 A Block #52655 A | Block #52655 B They would be stored in the blockchain like the rest of the blocks. Tell me, do blocks B, C etc... also come within the same 10 minutes as the A-blocks ? Do they also have block rewards ? Do these rewards increase bitcoin's inflation ? If yes --> Mwhahaha If no --> Who mines them ? Does block A have to certify (Merkle of blocks ?) blocks B, C etc.... and hence "wait for them" ? Is there only one miner of blocks A,B and C, namely the one mining block A and getting its rewards ? What's then the difference if the one mining block A is also including the transactions of B and C into block A ? |
|
|
|
Very doubtful.
Where are all these extra lateral blocks going to be stored?
Reminds me of pseudoscience.
Yes, there is strictly no difference between making one larger block, or making *several* side blocks having to be signed off by the "main chain block". This is nothing else but unlimited block size. But it is smart propaganda. As BU now has a bad name, we call it "sidewise blocks". |
|
|
|
If by advancement , you mean blocking the ability of the Bankers to enslave the world and its children from a Fractional Reserve Crypto system.
Fractional reserve banking is in any case unavoidable, it has nothing to do with crypto. From the moment there's something that has an established value but may have real or fake, perceived difficulties in handling directly (complexity, transaction price, slowness, security, ...), nothing can stop an entity to give out an IOU of that asset that can acquire more fluidity than the original. In order to keep that IOU in 1-1 relationship, you don't need a full reserve, you only need enough reserve to settle differences with other IOU emitters. Read the first few chapters of "Treatise on Money" by Keynes. He explains this (it is his argument of why banking must be regulated, but that's another story). The only way to avoid fractional reserve banking, is to have perfectly liquid money at no difficulty of usage, at no security risk, immediate and without cost. From the moment you introduce one of those frictions, you will give an opportunity to fractional reserve banking. Hell, bitcoin itself is fractional reserve banking for fiat in a certain way ! You hold bitcoins which you think are going to be "re-imbursed for fiat" in exchanges. Only if you use bitcoin in a closed circuit, you are not using bitcoin as fiat fractional reserve banking ! But most people think of bitcoin as "representing fiat value" and they look at coinmarketcap to see how much fiat they "hold" in their "bitcoin account", thinking that at any moment, they can "withdraw fiat" for it. |
|
|
|
|
Show Posts
