Page 2 of 2

Re: CAcoin

PostPosted: February 27th, 2018, 12:06 pm
by dvgrn
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.

Re: CAcoin

PostPosted: February 27th, 2018, 12:20 pm
by Majestas32
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...

Re: CAcoin

PostPosted: June 17th, 2018, 5:22 pm
by calcyman
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!

Re: CAcoin

PostPosted: September 3rd, 2018, 12:23 pm
by dvgrn
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.]

Re: CAcoin

PostPosted: September 3rd, 2018, 12:38 pm
by KittyTac
Don't use Aidan Mode in sigs.

Re: CAcoin

PostPosted: September 9th, 2018, 8:23 pm
by cordership3
@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.

Re: CAcoin

PostPosted: September 10th, 2018, 7:29 am
by calcyman
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.

Re: CAcoin

PostPosted: October 22nd, 2018, 9:43 am
by calcyman
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.

Re: CAcoin

PostPosted: October 22nd, 2018, 5:25 pm
by 77topaz
Yeah, copying earlier posts in a thread to appear legitimate is a common tactic of those sig-line-advertising bots.

Re: CAcoin

PostPosted: February 27th, 2019, 6:27 pm
by testitemqlstudop
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:
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"!

Re: CAcoin

PostPosted: February 27th, 2019, 7:28 pm
by calcyman
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/questions/915/why-dont-the-timestamps-in-the-block-chain-always-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.

Re: CAcoin

PostPosted: February 27th, 2019, 8:30 pm
by testitemqlstudop
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.

Re: CAcoin

PostPosted: February 27th, 2019, 8:59 pm
by calcyman
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.

Re: CAcoin

PostPosted: February 27th, 2019, 9:04 pm
by testitemqlstudop
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?

Re: CAcoin

PostPosted: February 28th, 2019, 5:55 am
by calcyman
testitemqlstudop wrote: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.


No it doesn't; Bitcoin simply follows the chain with the most blocks.

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/commit/0cadb0e31d10954cda98a6cd09081dccc58c450b

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).

Re: CAcoin

PostPosted: June 14th, 2019, 5:15 am
by simsim314
I just wonder what exactly stops us from publishing this crypto coin? I mean is it ideological or technical?

Re: CAcoin

PostPosted: June 14th, 2019, 5:30 am
by calcyman
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.

Re: CAcoin

PostPosted: June 14th, 2019, 6:30 am
by testitemqlstudop
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)

Re: CAcoin

PostPosted: June 20th, 2019, 8:41 am
by Hunting
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?