All I'm really doing is taking a very roundabout route to coding up a Python block/tx reader based on the full specification, (making allowances for the fact that it describes the structure of a  contemporary Bitcoin block, not a vintage one from back in the days of v.0.7) the task is mostly matching up the size of C/C++ structures with reading in the required number of bytes in Python. As far as I can tell, the script is working now. I also made use of the undocumented command-line option -printblocktree to, well, print the block tree, including the orphan blocks. Quite instructive and useful in that it poinpoints each block's location in the blk0001.dat file.


It's an irrelevant remnant of the advertising feature which I took from fusioncoin, with main part of their advertisement stuff removed (https://github.com/fusioncoin/fusioncoin/blob/master/src/smalldata.cpp#L75). I think the convention they use in the fusionoin code is that OP_RETURN data is assumed to be rich text by default (to support the advertising) or set PLAINTEXT to use plaintext and the BROADCAST flag indicates whether the OP_RETURN_DATA content appears in the advertisement listing on the fusioncoin overview page. (I need to re-do the inscription dialog, it's an absolute mess on hi-res, so might copy their advertisement dialog box). The length of the OP_RETURN data field is a variable: MAX_OP_RETURN_RELAY. It's a single point of change, currently bound to 80 (https://github.com/slimcoin-project/Slimcoin/blob/master/src/script.h#L27).

Cheers

Graham

Hm. To avoid any possible confusion, I'll delete the repositories containing the speculative datacoin port of the 0.16 primecoin-ng work.

Cheers

Graham

Ta-da: http://slimco.in/anatomy-genesis-block/ (https://github.com/slimcoin-project/slimcoin-project.github.io/commit/141c88c94395a97daf0d00975891cb505e61340d)

Graham

There's plenty of time for Phred to read through the distilled documentation.

I guess the next question is how much of the text in https://github.com/gjhiggins/throwaway should be retained and transferred to slimcoin.github.io and how do you want to integrate it into the web site's structure? The announcements are optional, I just split them out to get shot of them when editing. The Q&A was a quick'n'dirty dump and needs editing before publishing (the same questions get asked repeatedly) but if it's not actually going to appear in the documentation, I shan't bother.

Cheers

Graham

barrysty1e  helped me adjust my model. The Anatomy of the Slimcoin Genesis Block is now complete (but not yet written up) and the Python script now successfully reads and interprets the genesis block data. It also, importantly, positions the "read head" at the start of the sequence of "magic bytes" that marks the start of the next block (block 1).

Block 1 isn't the same as block 0 (the genesis block) but it isn't all that different, so I have been able to extend the anatomical model to include block 1 and any subsequent block that contains just one transaction. This condition holds up until block 522 which contains >1 transactions and which I'm working on atm ...

===================== Details of Block 521: ======================
magic: 6e8b92a5 (6e, 8b, 92, a5)
block_size: 356
version: 16777216
prevhash: 0000002ed6d345cb4b9b48667e73227b97bb5d93b8b348db957aafa09fc8f6db
merkle_root: 59b794adc98b4375b89fe123dfa13601f8a12158fabfebb703eb508393318e2d
timestamp: 1401357104 (2014-05-29T10:51:44)
nBits: 1d313deb
nonce: 671088975
fproofofburn: True
hashburnblock: 0000000000000000000000000000000000000000000000000000000000000000
burnhash: 0000000000000000000000000000000000000000000000000000000000000000
burnblockheight: -1
burnctx: -1
burnctxout: -1
neffectiveburncoins: 0
nburnbits: 0
number_of_transactions: 1
 
------------- Details of Transaction 0: -----------------
tx_version: 00000001
tx_ntime: 1401357087 (5387031f) 2014-05-29T10:51:27
tx_input_num: 1
tx_prev_output_hash: 0000000000000000000000000000000000000000000000000000000000000000
tx_prev_output_sequence: ffffffff
coinbase_tx_length: 15
coinbase_tx: 043003875302ff46062f503253482f
sequence: ffffffff
tx_output_num: 01
BTC_num: 16550000
pk_script_len: 35
pk_script: 2103fbfa443d3891689d7a58e2fb99a8ec142f1d228eac42f520bb17719bc63c4b11ac
lock_time: 1401357104 (00000000) 1970-01-01T01:00:00
coinbase_sig_length: 71
coinbase_tx: 30450221009e228ced771d9eac8b0ec8e0fb3ae297137582aed75e97c1dcd70918750ad31e02200 1da8e2b11da59d43a58d5414dcc7e8fc6838226dc78e5b57783d4ab816a3778


===================== Details of Block 522: ======================
magic: 6e8b92a5 (6e, 8b, 92, a5)
block_size: 1668
version: 16777216
prevhash: 000000094bf8a3d3ea0d9865e75a36fb41c48e2b20c3b0bdbb21c252f509448b
merkle_root: 754706aa21a2a1d4670e576a7fadff4de9281c059b363431f90da9fc78f607d4
timestamp: 1401357253 (2014-05-29T10:54:13)
nBits: 1d2da57c
nonce: 3221226870
fproofofburn: True
hashburnblock: 0000000000000000000000000000000000000000000000000000000000000000
burnhash: 0000000000000000000000000000000000000000000000000000000000000000
burnblockheight: -1
burnctx: -1
burnctxout: -1
neffectiveburncoins: 5796779233262960640
nburnbits: 0
number_of_transactions: 7
 
------------- Details of Transaction 0: -----------------
tx_version: 00000001
tx_ntime: 1401357231 (538703af) 2014-05-29T10:53:51
tx_input_num: 1
tx_prev_output_hash: 0000000000000000000000000000000000000000000000000000000000000000
tx_prev_output_sequence: ffffffff
coinbase_tx_length: 15
coinbase_tx: 04c5038753025f01062f503253482f
sequence: ffffffff
tx_output_num: 01
BTC_num: 16240000
pk_script_len: 35
pk_script: 2102afc065fa163072680264129f9cc27de71c95eefc1a2432a12d058c459d1d5cd5ac
lock_time: 1401357253 (00000000) 1970-01-01T01:00:00
coinbase_sig_length: 1
coinbase_tx: 00

------------- Details of Transaction 1: -----------------
tx_version: 031d0000
tx_ntime: 2332119943 (8b015387) 2043-11-26T03:05:43
tx_input_num: 124
tx_prev_output_hash: 00009f18572d7c68a866a487d93669856a060d64a08f689bf032fa66bcba442f
tx_prev_output_sequence: 48490000
coinbase_tx_length: 48
coinbase_tx: 4502200efdd68eb56c89d8d57edc3f79f5ad2e244308fa5204ca9d4919df9447b51d0e022100acb 58485ccd8d8a5d076
sequence: 5ed73fc3
tx_output_num: a7
BTC_num: 9814135143075891166
pk_script_len: 92
pk_script: a9248cbe695263d401ffffffff0270117202000000001976a914895d46e34a4b4df5d90b7af0e6f 2c03d14addff288ac40420f00000000001976a914c705b76b8164c13596716b8fd1159f8343d541 e688ac00000000010000006e03
lock_time: 1627476871 (61015387) 2021-07-28T13:54:31
coinbase_sig_length: 39
coinbase_tx: 53b107260969ebdfad8afa3f2d69d528e189fbc474a27769d5552bf26ee3000000004a49304602

------------- Details of Transaction 2: -----------------
tx_version: 33e40021
tx_ntime: 2691749403 (a070d61b) 2055-04-19T13:10:03
tx_input_num: 55
...

I truncated the output because at this point it's obviously run off the rails in terms of making sense of the input. I'm still working on it but I wanted to pass on what I'd found thus far.

I haven't yet been able to build a detailed model of the contents of the burn-related fields and the roles they play nor do I yet understand the roles played by the sequences. One thing does occur to me though: the file blk0001.dat is the result of one node transcribing to disk what it is retrieves from the network and, I am given to understand, it is only during the relatively short period immediately after syncing from the network that the file blk0001.dat is free of orphans - up to the last confirmed block. Because, all accepted blocks get written to blk0001.dat, even if they subsequently become orphans as the result of a later re-org.

The <lastmintedblock> (current block height) can only have a null value for <nexthash> because it is the hash of <next block to be found> which doesn't exist - yet. When a new block is found and accepted as the new <lastmintedblock>, the client must connect this new block to the end of the chain, i.e. write this latest block's hash into the empty <nexthash> of the previous block (the one that used to be <lastmintedblock> with a null <nexthash>).

Two blocks are special in respect of connectivity, the genesis block has no <prevhash> and the <lastblockminted> has no <nexthash>. All other blocks have both a <prevhash> and a <nexthash>. However, just because it has both, doesn't mean it's actually part of the blockchain, it may be an orphan.

A re-org is "simply" a matter of changing the content of the last-known-to-be-good block's <nexthash> from the hash of this (now-rejected block) to the hash of that (now-known-to-be-good) block - which then becomes the new next link in the chain. In this way, blk0001.dat fills up with orphaned blocks and the only way to detect whether they are orphans is to see if the block's <prevhash> matches the allegedly-previous block's <nexthash>. If they don't match, the block is an orphan.

Which is why the file blk0001.dat is only orphan-less up until the last confirmed block of a just-synced-from-the-net blockchain. As soon as those conditions no longer pertain, expect blk0001.dat to contain orphaned blocks.

Fun and games.

Cheers

Graham

Feeble attempt. A more developed implementation can be found behind Minki's "Hodlerscope": https://minkiz.co/hodlerscope - ask Minki about Spreadcoin hodlers.
(doesn't include coins launched in the last couple of years)

Cheers

Graham

The codebase might be more amenable these days. Instead of crashing, it reports "Block decode failed (code -22)" when fed with the example given, at least providing an opportunity to run the Slimcoin client in a debugger (QtCreator's debug/breakpoint UI is quite usable). Settings in the QtCreator suite intriguingly suggest a "profiling" capability, something which I have on the stack, possibly for a rainy week in July.

I would also like to finish off what I started with my Anatomy of the Slimcoin genesis block: the tx parsing (the last section) doesn't work as expected (as the output indicates), which is where I ran out of understanding - in that my modelling of the anticipated output doesn't match the reality. I've been as persuasive as I can be but reality has proved quite obdurate and declines to change the output to match my model, so I'll just have to adjust my model to match the reality, sigh.

Also, there's a raft of interrelated stuff about mining and getblock and gettemplate (ono) that I haven't managed to integrate into my understanding as yet. Here's one such example which seems pertinent to Slimcoin and seems to be reasonably straightforward codewise (Hans Robeers is good) ... https://talk.peercoin.net/t/rfc-0004-remove-transaction-timestamp/4867 but which will have ramifications for mining s/w, block explorers, etc - in fact any code which handles Slimcoin blocks/headers.

Cheers

Graham

barrysty1e's gone dark. I was in a convo with him, he shared some commercially-sensitive material with me. I was hoping to collaborate, he seemed up for it. Then he suddenly went dark. He's a Kiwi I think, apropos of nothing in particular. I just hope he's okay.

Cheers

Graham

That's the intended destination, I'm just being idle and letting github do the rendering in temporary repos, I really can't be arsed to set up even a minimalist rendering environment. The next and most taxing step is to reduce the content to the bare essentials and simplify the writing. But anyway, now we know - the main idea behind Slimcoin was the ability to use cheap low-powered kit to contribute network-protecting hashpower instead of expensive ASICs. No ASICs for Slimcoin are in sight as yet, so P4Titan's hypothesis has not been disproven thus far.


minkiz might just need a force-refresh in the browser, letsencrypt refreshed the https certs. http://tessier.bel-epa.com:5064 is serving again.

Cheers

Graham

Edit: intemperate and ill-founded rant deleted

I got this far: https://github.com/gjhiggins/throwaway

Cheers

Graham

The inclusion of the contextually irrelevant "deeponion" testifies to the above being the result of feeding sentiment analysis into a modern equivanent of a Markov chain generator. Another step along the road towards the Butlerian jihad.

Cheers

Graham

Looks like the letsencrypt script has broken the Apache config, sigh. That's all I did, I ran letsencrypt - can't be anything else. (I used to run self-signed, because of the obvious garbage that was contaminating the official cert chain but over time my options have been gradually crowded out by an increasing number of nowhere-near-as-good-as-they-obviously-think-they-are, half-assed security “improvements” ... lemme restart the daemons ... okay I can see Minkiz now, I presume others can too. (Yes, I do have plans to upgrade the h/w, later this year).

Edit:
Qualsys results, if anyone cares: https://www.ssllabs.com/ssltest/analyze.html?d=minkiz.co

Cheers

Graham

Another reason I'm unimpressed with the degree of journalistic insight displayed by the WSJ is that Slimcoin users won't be able to read what, if anything, the WSJ writes about Slimcoin and PoB because the WSJ web site is behind a paywall.

I'm slightly puzzled why this WSJ journalist thinks an open source project would be a topic of interest for WSJ's nakedly acquisitive subscribers or why it's blithely assumed that volunteer technical contributors will be happy to devote time to personally answering elementary questions from the WSJ, the answers to which are already out there in front of them, in black and white, if they could be arsed to look. In this respect, Phred is no different to any other putative Slimcoin user - except that as a WSJ journo, she expects to be able to take directly with “the deveopment team”. The mismatch speaks very strongly of profound misconceptions.

Cheers

Graham

I may be wrong but I don't believe that any of the current subscribers to this thread are able to claim first-hand knowledge, the current understanding has all been constructed from publicly-available posts in the old OP bitcointalk thread and in the Slimcoin documentation.

Okay, so Phred hasn't read the thread - that means there's a high likelihood that her misperceptions will overwhelm both the context and the communication.

Point her at the documentation, it's in her native language and is the primary source she is seeking (and her article will probably be all the better for it).

Good instincts ... Teal model best practice is: any person can make any decision after seeking advice from: i) everyone who will be meaningfully affected, and ii) people with expertise in the matter.

I don't see any reason why we shouldn't collectively have a go at coming up with something, if not for Phred then for the next time someone asks or even for our own use in explaining to acquaintances. I've just d/led all the original Slimcoin bitcointalk posts and am in the process of filtering them for relevant content and then I'll re-work the P4Titan on Slimcoin section of the Slimcoin README into a more comprehensive document, confident in the knowledge that all the available relevant technical info has been harvested.

If you're up for it, I'd like to explore something ... create a description of the basic principles of the coin (which will cover the typical journo's needs) but take pains to ensure it is written in a very simple and straightforward style which, if my educated guess is correct, should result in broadly accurate machine translation. The acid test will be for subscribers to this thread to paste the english source text into something like google translate and check whether the machine translation into their native language preserves the broad sense of Slimcoin's features and principles according to their understanding of the way that Slimcoin works.

Once we have something reasonably robust, I'd like to add the text to the "About Slimcoin" tab in the wallet, localised with the (largely approved) mechanical translations. Of course, if anyone actually wants to work on a translation or improve it, the files are all here: https://github.com/slimcoin-project/Slimcoin/tree/slimcoin/src/qt/locale

I should be able to come up with something later this evening ...

Cheers

Graham

Nice work.

Cheers

Graham

HTH

Cheers

Graham

What's fascinating? The fact that reality doesn't match the predictions produced by your analysis? That is a shame, I agree but atm I'm a bit busy and not in a position to adjust reality to fit your model predictions, please accept my apologies on this matter. I know it'll be a bitter blow but you just might need to face the inconvenient prospect of having to deepen your model in order for it to produce less unreliable projections.

Cheers

Graham

Gaining exclusive control over widely-distributed published open source software is a practical problem. I take it you have looked at BARR and Nexus as well as the other ill-conceived approaches that assume a purely monetary underpinning of what is actually a social phenomenon.

Cheers

Graham

You're not publishing your figures so its impossible to be specific. The idea's been tried several times, it falls at the first fence. Altcoin code is open source, is typically widely distributed and as designed, is highly resistant to being subject to the kind of centralised control that you seek to impose.

Cheers

Graham
 

Code for the Datacoin "intermediary" client is available in the "intermediary" branch of my github Datacoin repos: https://github.com/gjhiggins/datacoin/tree/intermediary It is an ongoing investigation so hasn't been merged with any of the other well-known Datacoin repos yet.

Cheers

Graham