Topic: Slimcoin | First Proof of Burn currency | Decentralized Web - page 51. (Read 137085 times)

gjhiggins - good .

Besides you can easily search a few people from here, at least gj is quite easy.

We could add to the main topic coinpaprika research platform - one of the project, I'm now working on, as administrator of it.

https://coinpaprika.com/coin/slm-slimcoin/

It will be active (Slimcoin) in near future. But it is in database, and we have even small team details there.

I'll show you mine if you show me yours.

Cheers

Graham

Interesting project but we would like to know more about the team who are behind this because no profile links are available to get more details.

In passing ...

Because of my reprehensible habit of working from a copy of datadir rather than syncing from the network, the orphans remain in the data, e.g.:

http://tessier.bel-epa.com:5064/main/blk/00000017eab29ea512fd2e0d40bc0ddbbadb6bf299fa46e32d676720dd1cf916

http://tessier.bel-epa.com:5064/main/blk/4b5a1cf5fb2f7b5aa05eabfd8cdc012d5ff06dbc1ec78fb54e86492a598ad78c

Both claim to be block 983917 but only the second one listed has a value for nextblockhash and so is a valid block in the chain.

The first is an orphaned block, not part of the blockchain proper, merely a now-ignored chunk of binary data left over from before. The nextblockhash of the previous block (983916), is definitive about which block is next in the chain as far as it is concerned. This latter is an important qualifier: block 983916 or one of its predecessors might also be itself an orphan - the output of -printblocktree that shows groups of orphaned blocks.

afaict the only way to be certain is by assiduously following the nextblockhash links until the last consensus-agreed last-known good block, (i.e. - ) hence the informational utility of -printblocktree.

Reading the blocks one by one out of blk0001.dat and being able to identify which ones are orphans (and skip over them) is one step along the way towards being able reliably to create a linearised bootstrap.dat file which the Slimcoin client has a reasonable chance of reading.

[Edit:] Oh, and it's also a step along the way to possibly resolving the issue raised in https://bitcointalksearch.org/topic/m.9344217 which remains extant.

Cheers

Graham

Thanks. I looked into my wiki article draft again and I found some errors which I corrected (in particular, I incorrectly assigned 8-byte-lengths for items that are only 4 bytes "wide"; this is due to that when processing the raw hex transaction in Python obviously every byte requires two hexadecimal characters   - the good part about that error is that in the Inscriber tool I did everything correctly). I added your additions about coinbase transactions now and the format now matches the one of the "Anatomy" article.

Edit: I spotted one difference still: The tx_output item ...

should be only 1 byte wide (I re-checked it with some recent transactions, if it's 2 bytes wide, the value (BTC_num) in hex doesn't match the value of the decoded json).

Aha, thanks for the explanation. I did briefly look at fusioncoin but not so much in detail to understand their "advertising" feature. I don't remember the reason why you added it, can you help me remember? (I googled the thread but didn't find it, we really need something like a text mining tool - or an AI, to use a current buzzword - recompiling old Slimcoin Bitcointalk posts and tagging them with metadata ...)

Obviously it would be ideal that the inscription dialog could use the raw transaction format allowing control over the used addresses, like my Inscriber tool does, but I think we need a couple of rounds of testing to ensure everything is working right.

Maybe it could also be possible to change the createrawtransaction command so it allows a "data" field like newer Bitcoin versions do. Would this be a difficult change?

---

By the way, interesting discussion in the Peercoin community: https://talk.peercoin.net/t/modifying-the-economics-of-peercoin-in-anticipation-of-increased-blockchain-usage/

They plan to modify the fixed transaction fee structure a bit, keeping the 0.01 PPC/kB fee but not "rounding" it up anymore - so a ~200 byte transaction would only cost 0.002 PPC instead of 0.01 PPC. I think that would be a nice change in the future that wouldn't change the incentive model too much. If we decided to follow that path, I would also propose to remove the 0.01 minimum transaction output value - this would only become relevant if Slimcoin ever should cost more than 1$, but I think it's an unnecessary restriction as Slimcoin's granularity is already lower than Bitcoin's afaik (1 "Slimtoshi" = 10 BTC Satoshis).

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

If some people are into watching some series, I have watched last time 2 episodes of "Silicon Valley"
It was Season 5 Ep 7 and 8.

Have a lot of connections to crypto - but mainly ICOs... There are a lot of inconsistencies, and ridicolous things ("patching" network to be sustainable of 51% attack - I mean lol, you can't do that really, unless you centralize it again - which at the end it shows it's centralized to one pool/validator?)

But apart from that it was a good fun, at least for me.

Thanks, great work!

As far as I understand the changes in your article, my wiki article about the transaction format only "covers" standard transactions and still needs to include the parameters of coinbase transactions. I'll take a look at it later or tomorrow.

BTW: I'm working on a simple GUI for the Inscriber tool, to make it more amenable for non-nerds. A very ugly-looking (Tkinter-based) prototype is ready, but I understand that people want a little bit of beauty so I'm improving it a bit.

A question that came up while working on that: I think the prefix system used by the "smalldata" format is extensible, isn't it? It would be nice to have more data types. For example, a short format for torrent hashes or magnet links could save a couple of bytes and allow some more data to be included into the 72 available bytes. Also, we could establish a format for Graham's proposed Trusty URIs and kdsme's "updateable torrent" format (@ksdme, are you still here?).

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

Two blocks are special in respect of connectivity, the genesis block has no and the has no . All other blocks have both a and a . 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 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 matches the allegedly-previous block's . 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

Hi.

So quick update - I'm making inquries to my felow friends developers, if they can help us.

Also P. Dvorak has responded:


Anybody up to it? I can arrange all details.

Administrators in the Slimcoin community work very well. They have been communicating well in the community. Joining Slimcoin today, you will see that Slimcoin has grown a lot.

New discord invitation: https://discord.gg/crMHFRJ

I think this channel of communications is better, even if it's designed for gamers, because it has quite logic and good interface, tab view, and ability to make new channels.

Telegram is also good for general discussion, but it isn't suitable to create new channels.

I cleaned it up, and add new channels.

I forgot to post that I had noticed, when I tried to understand the transaction format for the "inscriber" tool I mentioned earlier, that the transaction format that worked in my case was different from the one you described in your "Anatomy". In particular, the "sequence" number (which every time I tried it was FFFFFFFF) came directly behind the first script. I however don't know if this is a particularity of the genesis block transaction which may be formatted differently (sorry for my noobishness ).

Good that @barry is now with us. Sorry for my post, but you were unavailable and inactive for a fairly long.

So maybe pool will be set up after all?

Hello cryptossi,


Yes, I would tend to say that slimcoin is a good coin to start with because it is relatively easy to set up and can use almost any hardware. It happens to be basically the first coin that I mined too. In terms of hardware, I would say that you could potentially mine on any CPU from about the last 3-5 years, but as with any mining your profits will probably mostly depend on your power prices. On older hardware, I would say give it a go, but don't expect to make a profit (you still might though). Even some small ARM based single board computers are good for mining Slimcoin as they are very efficient.

One other thing I would say is use the external miner (https://github.com/JonnyLatte/slimminer) rather than the one in the wallet as the external miner produces much higher hash rates. The external miner will also allow you to mine to the same wallet from multiple machines if you wish to do so.

If you are stuck setting anything up, don't be afraid to ask for help, however the documentation in the github repositories for both the wallet and the miner should help you.

Regards

Good news ! Hope you have a great success

Hey guys I'm new to mining, would you say slimcoin is a good coin to start off with and what hardware would you recommend?

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