ConwayLife.com

Majestas32 wrote:I mean for rules with >100million or 10 billion objects we can easily algorithmically produce a rare patterns list

Yes, but maintaining a distributed rare patterns list for a large set of rules would quickly start to be a problem. The list would have to be copied and agreed on by all the nodes in the distributed network, and it would presumably have to be adjusted every time a new rare object was discovered.

Basically, people can talk about a multi-rule CACoin if they must, but until they go ahead and solve all the very detailed problems involved with supporting large numbers of rules, a LifeCoin restricted to plain B3/S23 searches seems much much more likely to actually get implemented.

Yeah. I was thinking of having it automatically processed based on previous lifecoin/catagolue searches at every block but Hey calcyman is literally God so...

Majestas32 wrote:Yeah. I was thinking of having it automatically processed based on previous lifecoin/catagolue searches at every block but Hey calcyman is literally God so...

The approach I've settled upon is:

1. Initialise difficulties according to the output of Catagolue. This gives a good estimate for medium-rare objects (say, difficulty < 50000 or so), but is too noisy in the tails.
2. When the difficulty target of the cryptocurrency first exceeds the difficulty (exactly 38347, as calculated in step 1) of xp15_4r4y14r4z4r4y14r4, update the difficulty estimates (in a precise way) of anything rarer than xp15_4r4y14r4z4r4y14r4.
3. When the difficulty target of the cryptocurrency first exceeds the difficulty (calculated in step 2) of xq16_gcbgzvgg826frc, update the difficulty estimates (in the same manner) of anything rarer than xq16_gcbgzvgg826frc.
4. When the difficulty target of the cryptocurrency first exceeds the difficulty (calculated in step 3) of xq7_3nw17862z6952, update the difficulty estimates (in the same manner) of anything rarer than xq7_3nw17862z6952.

If Step 2 ever happens, it would take about 15 times as much computational power as Catagolue's last peak (of roughly 10^12 objects per day). By this point, the initial segment of blockchain will have a more accurate estimate of difficulty than Catagolue ever did, having amassed an entire Catagolue-volume every 2 weeks.

As for Step 3, that would only happen when the total hashrate is about 10^15 objects per day, amassing a Catagolue-volume every 6 hours (!). I'm making the implicit assumption that several loafers will have emerged by this point, and that I can therefore use that as the standard for Step 4. Not that we're ever likely to need to invoke Step 4, as that would only occur when we're producing loafers-or-beyond every 10 minutes!

testitemqlstudop wrote:How about search for a pattern that stabilizes in at least D generations where D is the difficulty?

[Deleted another post to get rid of the toxic sig line.]

Don't use Aidan Mode in sigs.

@calcyman: What is the current progress on the CACoin implementation? I know a lot of progress has been made since you last posted about the proof-of-work system, but the lifecoin branch is already available for use and there seems to be nothing different about it.

cordership3 wrote:@calcyman: What is the current progress on the CACoin implementation? I know a lot of progress has been made since you last posted about the proof-of-work system, but the lifecoin branch is already available for use and there seems to be nothing different about it.

To summarise:

Digital signatures/addresses: implemented
Proof-of-work system: implemented
Blockchain headers: implemented
Difficulty calculations: implemented
Networking: not yet implemented
Transactions: not yet implemented

Once the networking is implemented, we'll have a usable decentralised blockchain (and online mining will become possible), but it won't be a currency until there's support for transactions.

I tested offline mining (and mined the first 100 blocks in a day, saving them to disk) a while ago and tested the output against an independent Python 3 script to ensure the cryptographic primitives have been correctly implemented. I haven't mined any more blocks since that day, because I don't want too much of a headstart.

honglei (now banned for Sri Lanka travel-visa spam in sig line) wrote:Well considering that long time search is actually translated into a value of a coin, I think most search time in GOL went into spaceships search. So having some new p7 and higher period spaceships could be considered as a cryptocoin.

That may have been the case when simsim314 originally wrote the paragraph you've just shamelessly plagiarised, but now it's been far surpassed by the (estimated) 3 million CPU-hours that have gone into Catagolue.

Yeah, copying earlier posts in a thread to appear legitimate is a common tactic of those sig-line-advertising bots.

calcyman wrote: The approach I've settled upon is:

<snip>

The first thing that came to mind when I saw the difficulties file is that the difficulty of objects were not linearly distributed - in fact, there were only three or four objects for each ORDER OF MAGNITUDE. This creates great problems:

difficulties.inc wrote:

Code: Select all

difficulties[                               "xp14_j9d0d9j"] =         903.6111;
difficulties[                           "xp8_wgovnz234z33"] =        3345.3205;

This quite literally implies that there will be NO DIFFERENCE AT ALL between a difficulty of 904, 907, 1907, or 3345. In cryptocurrencies, the targets move in correspondence to (total hashspace size/difficulty). In SHA256, where the total hashspace size is 0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff. If the difficulty was 1M hashes, the target would be 0x000010c6f7a0b5ed8d36b4c7f34938583621fafc8b0079a2834d26fa3fcc9ea9, if the difficulty was 2M hashes, the target would be 0x000008637bd05af6c69b5a63f9a49c2c1b10fd7e45803cd141a6937d1fe64f54. On the other hand, in Lifecoin, if the difficulty was 1000 CPU-minutes, the target would be "rarer than xp8_wgovnz234z3", and if the difficulty was 2000 CPU-minutes, the target would still be "rarer than xp8_wgovnz234z3"!

What you say is correct, but I'm unconvinced by your claim that:

This creates great problems

The only 'problem' that imposes is that there will be (for instance) a discontinuity between blocks lasting 5 minutes and blocks lasting 20 minutes. This discrete jump between block difficulties isn't problematic; in any case (including Bitcoin), block times are exponentially distributed, so you can't rely on differences between block timestamps being uniform. Indeed, Bitcoin timestamps aren't even required to be monotonic (!!!)*, so much worse things are allowed than a mere fourfold jump in block difficulty.

* reference: https://bitcoin.stackexchange.com/quest ... s-increase

So I'd agree that this creates irregularities, but these irregularities in no way actually weaken the blockchain, so they're not problems per se.

Also, this fourfold jump is quite an isolated occurrence; beyond it, the jumps appear to be much smaller.

calcyman wrote:The only 'problem' that imposes is that there will be (for instance) a discontinuity between blocks lasting 5 minutes and blocks lasting 20 minutes.

Well, what I thought was instead of blocks lasting 5 minutes blocks last 1 or 2 minutes -

testitemqlstudop wrote:if the difficulty was 1000 CPU-minutes, the target would be "rarer than xp8_wgovnz234z3", and if the difficulty was 2000 CPU-minutes, the target would still be "rarer than xp8_wgovnz234z3"!

I was thinking that this problem could be partially alleviated by including difficulty for more objects, e.g. including SLs >= 30 bits or having a higher cutoff for "***_rare" objects.

Networking: not yet implemented

I REALLY think an HTTP server for each node is enough.

testitemqlstudop wrote:

Networking: not yet implemented

I REALLY think an HTTP server for each node is enough.

I agree -- but there's still a huge amount of work to implement all of the endpoints necessary: for starters, there needs to be some interaction between nodes to determine the most recent common block where their chains agree, so that everything beyond that can be transmitted to the other node. And it's also necessary to ensure that this is robust against a malicious agent controlling one end of the communication channel and trying to DDoS you. So whilst this will all be built upon a stock HTTP server (e.g. libmicrohttpd, which I've used in other projects), that's only a vanishingly small fraction of the total effort involved in establishing a communication mechanism between nodes.

There comes the problem again.

Bitcoin has the advantage of "follow the chain with the most work" - the sum of 1/(sha256 hash) for each block. However, Lifecoin treats blocks with the same rarest object equally. Shouldn't there be some kind of "tiebreaker" function so that two xp8_wgovnz234z33 (say) blocks won't be weighted equally if one attacker mined a malicious block and tried to fork the chain?

And I bring up another problem: There is no function for block verification.

Am I the only person who wants to bring back the v1 soup scoring system?

And I bring up another problem: There is no function for block verification.

Good point. I've added a function now:

https://gitlab.com/apgoucher/apgmera/co ... ccc58c450b

Run ./lifecoin verify [sequence of block files]. This will check that:

• The hash* of each block is correctly included in the next block;
• The difficulty is adjusted correctly according to the timestamps;
• The soup from a block produces a rare object surpassing the difficulty target;

* SHA256 concatenated with SHA3-256, just in case one of these (two very different) algorithms has a vulnerability.

The return code is equal to the number of errors (blocks which fail).

I just wonder what exactly stops us from publishing this crypto coin? I mean is it ideological or technical?

simsim314 wrote:I just wonder what exactly stops us from publishing this crypto coin? I mean is it ideological or technical?

Technical: it's merely that it takes a lot of time to add transaction support and networking, and I've been busy with other things.

Can anyone else look into how difficult it would be to modify the Bitcoin/Cryptonote codebase so as for the POW/blockchain specifics are modified? (anyone other than calcyman)

Related request: Make an unofficial symmetry of apgsearch, which generates a string which starts with a fixed prefix, and SHA-256 it, and census its QR code. That would be easy for you guys, I think.

How much time will it take to find a pentadecathlon?

Literally less than a second

An instruction set to setup bitcoin with cgol pow:

In this function bitcoin validates PoW is done correctly. We will use CGOL soup validation instead. Notice bitcoin uses only nBits we will need to use a specific frequency of SL.

In this function the difficulty is recalculated. We will need to use SL list and frequency to set up the difficulty. More than that we will need to allow people to post new SLs with lower frequency than what is expected, in order to encourage new SLs. We will also give more coins to people who found something which is not present in census yet.

Inside the CreateNewBlock function we will need to replace this line to use SL statistics instead of the nbits parameter.

To make sure it's working properly we should make sure this function is returning what we want it to return.

Other than that: I'm not sure how the external miner is attached to the code.

EDIT Looks like you can get all the information about the last block from the developers guide and to commit a new block they use this call.

Hopefully changing the CreateNewBlock function to use CGOL algorithm will automatically use the new validation so only the miner needs to commit a different hash through the rpc i.e. we don't need to change anything only run an rpc and call a submitblock command with the correct hash that solves the CGOL problem with correct difficulty.

simsim314 wrote:An instruction set to setup bitcoin with cgol pow:

In this function bitcoin validates PoW is done correctly. We will use CGOL soup validation instead. Notice bitcoin uses only nBits we will need to use a specific frequency of SL.

In this function the difficulty is recalculated. We will need to use SL list and frequency to set up the difficulty. More than that we will need to allow people to post new SLs with lower frequency than what is expected, in order to encourage new SLs. We will also give more coins to people who found something which is not present in census yet.

Inside the CreateNewBlock function we will need to replace this line to use SL statistics instead of the nbits parameter.

To make sure it's working properly we should make sure this function is returning what we want it to return.

Other than that: I'm not sure how the external miner is attached to the code.

EDIT Looks like you can get all the information about the last block from the developers guide and to commit a new block they use this call.

Hopefully changing the CreateNewBlock function to use CGOL algorithm will automatically use the new validation so only the miner needs to commit a different hash through the rpc i.e. we don't need to change anything only run an rpc and call a submitblock command with the correct hash that solves the CGOL problem with correct difficulty.

Awesome.

so where do I get my CAcoin ?

and does it have Quantum Encryption ?

Any proof of work scheme will need to have variable difficulty. Searching for novel patterns would only increase in difficulty. Also, the proof of work would need to integrate a block hash with the pending transactions. So the only way I can think of to make something like this work would be to make soup of block hash plus a nonce and the difficulty will be based on the number of generations the resulting Methuselah lives before becoming stable. Oscillators, scattering gliders, and occasional infinitely repeating patterns will make verification difficult.