2
|
Alternate cryptocurrencies / Altcoin Discussion / do any coins rival Grin's simplicity?
|
on: January 16, 2021, 02:50:20 PM
|
Simplest possible consensus model: Proof of Work. Grin uses Nakamoto consensus just like Bitcoin. Simplest possible emission: 1 grin per second forever. Grin uses Tail Emission from launch, the complete opposite of Bitcoin's Capped Supply. The latter is known to suffer from insecurity and mining instability once the block subsidy becomes insignificant, unless a constant backlog of high fee paying transactions can be created (which Bitcoin seems to manage with its constrained block size). Emission properties are further explored in [1a] and [1b]. Simplest possible blockchain protocol: Pure Mimblewimble. In Mimblewimble, outputs are Pedersen commitments r*G+v*H which combine value and blinding factor into a single curve point. The blinding factor serves both to hide the value and to control ownership. Correspondingly, a single (multi-)signature serves both to prove value balance (non-inflation) and to authorize transfer of ownership. The magic doesn't stop there, as transaction cut-through results in the collapse of the entire transaction history into a single transaction with no inputs and the current UTXO set as outputs [2]. Simplest possible blockchain sync: verify UTXO set. Grin still verifies transaction history by means of a ~100 byte kernel that remains for every transaction, but doesn't need to know anything about spent outputs. Simplest possible (memory hard) Proof of Work Algorithm: Cuckatoo Cycle. Its mathematical specification is only 13 lines [3a] based on the very simple siphash-2-4 hash function. Which translates to just 42 lines of C code [3b]. Like Bitcoin, solutions can be instantly verified, but unlike Bitcoin, a single solution attempt (searching a graph) takes on the order of a second. Simplest possible Difficulty Adjustment Algorithm: wtema. Just one line of code [4] that outperforms many other DAAs [5]. Simplest possible scripting functionality: scriptless scripts. Grin does away with Bitcoin's script and all its complexity, but retains a lot of its functionality, including multi-signatures, and both absolute and relative timelocks. It easily supports atomic swaps, discreet log contracts, and bidirectional payment channels. It lacks hash locks, but finds a superior alternative in adaptor signatures The simplicity is reflected in the relatively small Rust codebase of the reference implementation [6] and the alternative C++ implementation [7]. [1a] https://john-tromp.medium.com/a-case-for-using-soft-total-supply-1169a188d153[1b] https://medium.com/@CryptoProfG/grin-money-explained-4-exploring-grins-monetary-model-e48b1761653[2] https://phyro.github.io/what-is-grin/mimblewimble.html[3a] https://github.com/tromp/cuckoo/blob/master/doc/mathspec[3b] https://github.com/tromp/cuckoo/blob/master/doc/spec[4] https://github.com/mimblewimble/grin/blob/master/core/src/consensus.rs#L371-L372[5] https://read.cash/@jtoomim/bch-upgrade-proposal-use-asert-as-the-new-daa-1d875696[6] https://github.com/mimblewimble/grin[7] https://github.com/GrinPlusPlus/GrinPlusPlus
|
|
|
3
|
Bitcoin / Development & Technical Discussion / Re: Adjustable Blocksize Cap: Why not?
|
on: January 16, 2021, 02:43:18 PM
|
The user is talking about preventing miners from filling the blocks with cheap fee transactions. You cannot prevent that by anything that is not consensus rules such as a simple configuration that already exists called minrelaytxfee.
You can prevent it by creating a backlog of high-fee paying transaction, which Bitcoin has achieved by constraining the block size.
|
|
|
5
|
Bitcoin / Development & Technical Discussion / Re: Adjustable Blocksize Cap: Why not?
|
on: January 16, 2021, 08:26:46 AM
|
Your solution simply added mandated hard forks each time there is a big price rise to reduce the minimum fee.
Not necessarily. You can have a minimum fee scaling factor in a configuration file. After all, this is not a consensus parameter. So after the price has gone up by an order of magnitude for a long enough period, you could agree to have as many nodes as possible to update this scaling factor to be 10 times smaller. Over time, more and more nodes will adopt this new value, and allow the mempool acceptance and relay of transactions with 10x smaller fees.
|
|
|
7
|
Bitcoin / Development & Technical Discussion / Re: On bitcoin's very long term future without miner rewards
|
on: January 11, 2021, 11:24:34 AM
|
Only capped supply valuable is time.24 Hour 60 minutes. Thats it.
Yes, an emission modeled after time, at 1 per second forever (600 block reward) would have been very interesting. Then the inflation rate would currently be at around 8%, and would take decades more to fall under 2%. That requires a lot of patience. But it could have made Bitcoin more attractive to later generations.
|
|
|
8
|
Bitcoin / Development & Technical Discussion / Re: On bitcoin's very long term future without miner rewards
|
on: January 11, 2021, 07:39:37 AM
|
Instead, by incremental reduction in availability of money, the economy gradually shifts to other devices
You failed to provide any convincing arguments for this though. Precision will be added simply as a result of a satoshi becoming too valuable to be a smallest unit, not because too much bitcoin has been lost (which we'll never know except by vague guesses). I understand the sentiment of your post, that you think a tail emission makes much more sense than a capped supply (I am in that camp myself). But Bitcoin, being the dominant player that it its, may be one of the very few PoW coins that can make a hard cap work in the long run. It just needs to maintain that backlog of high fee paying transactions.
|
|
|
9
|
Bitcoin / Development & Technical Discussion / Re: On bitcoin's very long term future without miner rewards
|
on: January 10, 2021, 08:21:11 PM
|
all the coins we have in circulation today will be lost sometime, somehow by someone. Right?
Assuming a yearly 1% loss rate, it will take approximately 1375 years for supply to dwindle down from 21M BTC to 21 BTC. If by that time, each satoshi has subdivided further into 10^6 subunits, then the system can keep functioning mostly as is. Adding on average one decimal every 229 years should suffice.
|
|
|
12
|
Bitcoin / Development & Technical Discussion / Re: Transaction cut-through
|
on: January 06, 2021, 03:33:17 PM
|
Bitcoin's communications cost is proportional to N_txn*x while the Mimblewimble zero sum property is proportional to N_txn*y + N_utxo*z, and x is somewhat larger than y, and z is MUCH larger than x.
Actually, Bitcoin could use a variant of Mimblewimble that foregoes the privacy benefits. A UTXO could be a triple <v, PK, sig> of an amount v, public key PK, and a signature sig with PK on v to replace the range proof in MW. A transaction tx is then a set I of inputs, a set O of outputs, and a signature with public key tx.PK = sum_{o in O} o.PK - sum_{i in I} i.PK which the transacting parties can interactively construct just as in MW. This preserves MW's ability to trivially aggregate transactions, and also allows for an additional "kernel offset" to obfuscate original transaction boundaries (adjusting the above equation by offset*G). This reduces z to about 100 bytes, and the Initial Block Download to 600M * 100B + 68M * 100B ~ 67 GB.
|
|
|
13
|
Bitcoin / Development & Technical Discussion / Re: On bitcoin's very long term future without miner rewards
|
on: January 05, 2021, 09:20:58 AM
|
21 million coins won't be the final limit. Majority will eventually agree to keep btc block rewards at a sustainable level.
No; we'll just see 2 camps of people. The supply-cappers and the tail-emitters. Both agree that mining rewards should always be very significant, in order to achieve long term security and stability. These two conflicting visions also see different outcomes of inevitable coin loss, which I believe is very unlikely to drop below 0.1% and may be closer to 1% on a yearly basis. Capped Supply A supply cap requires a block reward dwindling to insignificance (long before it reaches 0). So the significant mining reward must come from large fees. Mining stability requires a steady backlog of fee paying transactions, which in turn requires a highly constrained block size. Coin loss will erode the circulating supply over time and will eventually necessitate subdividing the smallest unit. Tail Emission With an eventual (or even from launch) constant block reward, fees are only needed to deter spam, and block size is less constrained. It could be more dynamic to deal with surges in transaction demand, or slowly grow over time. Coin loss will put a softcap on circulating supply. People who stop believing in the 21M bitcoin cap could of course try to fork away, but such a fork would very much go against Bitcoin's main principle of immutability. and would likely fare no better than altcoins that embraced the tail emission from the start, which is probably what those people would instead gravitate to. Bitcoin cash is interesting for being in the Capped Supply camp, while being unwilling to highly constrain the block size. Which looks like a recipe for long term insecurity and/or instability.
|
|
|
14
|
Bitcoin / Development & Technical Discussion / Re: Will Bitcoin ever be as fungible as Monero?
|
on: January 05, 2021, 08:36:16 AM
|
>It has always been offering a good level of privacy to users while the users sometimes decide to void that privacy by willingly linking their identity to their bitcoins.
I think the default level of privacy is poor. The reason is that people think of Bitcoin transactions as being non-interactive. The sender just sends some money to a receiver.
To avoid address reuse, one must go to the trouble of making transactions interactive. Namely, first have the receiver present a fresh address to the sender. In many cases this interaction is not even feasible. E.g. when asking for donations in Bitcoin.
So many payments end up reusing addresses, resulting in poor privacy. What you describe as willingness to link their identity to their bitcoins, is more often just unwillingness (laziness) or inability to unlink their identity from their bitcoins
|
|
|
17
|
Bitcoin / Development & Technical Discussion / Re: Transaction cut-through
|
on: January 02, 2021, 12:36:04 PM
|
Bitcoin's communications cost is proportional to N_txn*x while the Mimblewimble zero sum property is proportional to N_txn*y + N_utxo*z, and x is somewhat larger than y, and z is MUCH larger than x.
It looks like you're discussing Initial Block Download communication costs. Assuming 2-input, 2-output txs, I get Bitcoin tx size x ~ 400 bytes (or is it closer to 500?) MW kernel size y ~ 100 bytes MW output + rangeproof size z ~ 700 bytes (600 with BP+) Are you saying that 400 is somewhat larger than 100, and 700 is MUCH larger than 400 ? Plugging in N_txn=600M and N_utxo=68M, we get IBD sizes of 240 GB for Bitcoin and 60 GB + 48 GB = 108 GB for MW.
|
|
|
|