Bitcoin Forum
January 18, 2021, 12:01:52 AM *
News: Latest Bitcoin Core release: 0.21.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: [1] 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 »
1  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN] Grin | PoW Mining | Electronic transactions for all. Community driven. on: January 17, 2021, 07:47:07 AM
Meanwhile, I'm awaiting delivery of a Cuckatoo32 ASIC to be used for testnet mining.
What the timeframe for the ROI?

Given the difficulty of selling testnet Grin, ROI is negative:-(
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.
4  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN] Grin | PoW Mining | Electronic transactions for all. Community driven. on: January 16, 2021, 08:35:31 AM
Congratulations on a smooth upgrade to version 5!
(technically it was not a hard fork as the old code would simply refuse to accept any block at height 1048320)

Goodbye, members of the CuckARoo family. You successfully kept out ASICs over the past 2 years.

Meanwhile, I'm awaiting delivery of a Cuckatoo32 ASIC to be used for testnet mining.
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.
6  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN] Grin | PoW Mining | Electronic transactions for all. Community driven. on: January 12, 2021, 08:01:39 AM
https://grinnews.substack.com/p/129-the-final-scheduled-fork-

Hard Fork Incoming!

Node changes:
Improve transaction fee calculation, as outlined in https://github.com/mimblewimble/grin-rfcs/blob/master/text/0017-fix-fees.md
Improve difficulty adjustment algorithm, as outlined in https://github.com/mimblewimble/grin-rfcs/blob/master/text/0018-fix-daa.md
(Partial) Parallel IBD: Preparation for support of an improved process for initial sync and download of blockchain data, as outlined in https://github.com/mimblewimble/grin-rfcs/blob/master/text/0020-pibd-messages.md

Wallet changes:
Late locking of outputs: Removing the need for outputs to be locked during transaction building before the final stage.
Remove http listener for external addresses: As per the deprecation announcement with v4.0.0, remove support for unsecured http listeners in favour of the slatepack 43 standard.

Countdowns:
https://www.nicehash.com/countdown/GRIN-forking-2021-01-17-12:00
https://grinnode.live/
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.
10  Bitcoin / Development & Technical Discussion / Re: On bitcoin's very long term future without miner rewards on: January 08, 2021, 12:18:22 PM
Merged mining is currently in use, with Elastos (main chain and PoW sidechains), Namecoin, Syscoin and a bunch of other coins.

It looks like those coins combined account for less than 0.1% of Bitcoin's daily issuance, and thus have negligible contribution to Bitcoin security.
11  Bitcoin / Development & Technical Discussion / Re: On bitcoin's very long term future without miner rewards on: January 07, 2021, 11:44:55 AM
Actually the more important question is not about any of that, it is all about the price of bitcoin.

Not as much as you might think.
Both the cost of a 51% attack and the possible double spending gains scale linearly with Bitcoin price.
Security is about the mining reward being a sufficiently high fraction of circulating supply.
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

15  Bitcoin / Development & Technical Discussion / Re: Will Bitcoin ever be as fungible as Monero? on: January 04, 2021, 07:28:48 AM
Is bitcoin not being private just a "temporary" thing or will it never be as private as Monero?

Will Monero ever be as scalable as Bitcoin (with txs being an order of magnitude larger, and full nodes unable to forget everything about spent outputs) ?

Or ever have a fully auditable supply?
16  Alternate cryptocurrencies / Altcoin Discussion / Re: Any trusted exchange for grin coin? on: January 02, 2021, 03:50:34 PM
Kucoin was not so fine for this user:

https://forum.grin.mw/t/kucoin-account-hacked
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.
18  Bitcoin / Development & Technical Discussion / Re: Transaction cut-through on: December 31, 2020, 03:17:24 PM
This cut-through mechanism is the modus operandi of the Mimblewimble protocol [1], where it doesn't need interaction with any of the tx signers and can be applied across the entire blockchain history to slim down the Initial Block Download.

[1] https://github.com/mimblewimble/grin/blob/master/doc/intro.md
19  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN] Grin | PoW Mining | Electronic transactions for all. Community driven. on: December 30, 2020, 11:47:16 AM
I still don't understand why those calculator saying hashrate in h/s instead of GPS.

I guess they want to pretend every PoW is a hashcash, or are too lazy to properly account for different PoW.

Quote
Incase if that miner is running at 1.4gps well the speed is much lower than gtx 1080ti. I mean gtx 1080ti is way more faster than this miner.

No; a 1080Ti does only 0.46 gps on Cuckatoo32, according to https://whattomine.com/
20  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN] Grin | PoW Mining | Electronic transactions for all. Community driven. on: December 30, 2020, 08:11:06 AM
I'm looking to buy grin by the 1000s @ 1k sats each.

I'll buy a day of Grin at that price....

(funny that a whole day of Grin now costs less than 1 BTC...)
Pages: [1] 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!