Slimcoin | First Proof of Burn currency | Decentralized Web

[muf18]

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?

[d5000]

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.

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

[muf18]

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.

[yeyz20171031]

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.

[muf18]

Hi.

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

Also P. Dvorak has responded:

Hi and apologies for the delay in answering. [...]

But May 16 or 17 would work well for me as well, depending on the time.

What time slot works best for you?

Best, Phred, WSJ

Anybody up to it? I can arrange all details.

[gjhiggins]

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.

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

[gjhiggins]

Also P. Dvorak has responded:

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

[gjhiggins]

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

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

Graham

[d5000]

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

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

Graham

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

[muf18]

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.

[gjhiggins]

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.

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.

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

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

[d5000]

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.

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

Code:

tx_output = ds.read_bytes(2)[::-1].hex()

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

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.

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

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

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

[gjhiggins]

In passing ...

I also made use of the undocumented command-line option -printblocktree to, well, print the block tree, including the orphan blocks.

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. <height_of_last_block_minted> - <no_of_confirmations>) 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://bitcointalk.org/index.php?topic=613213.msg9344217#msg9344217 which remains extant.

Cheers

Graham

[abazakolala]

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.

[gjhiggins]

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.

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

Cheers

Graham

[muf18]

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.

[gjhiggins]

gjhiggins - good .

Perhaps I should have made my point clearer. Answering requests for real-life id from pseudonymously-operated computer programs is a waste of time for any human with a llimited lifespan.

I will not be pestered by machines but the people behind bitcointalk would appear to be either incompetent or uncaring, either way the outcome is entirely predictable and already becoming apparent.

Cheers

Graham

[muf18]

I have already made comment there awaiting moderation, but for some people to see if they want to

https://www.coinopsy.com/dead-coins/slimcoin/

[gjhiggins]

Anybody up to it? I can arrange all details.

FWIW, my assessment is: there's plenty of English-language material commonly and freely available that describes Slimcoin quite adequately for journalistic purposes, this thread and its predecessor being a prime example.

The manner of the approach and its baggage-laden, unquestioned-but-mistaken assumptions clearly communicates the WSJ's limited understanding of the field. And, no this is not an opportunity to "set the record straight", it's an opportunity to be quoted out of context and made to look a fool by a poorly-informed professional with an existing hostile agenda:

https://www.wsj.com/articles/buyer-beware-hundreds-of-bitcoin-wannabes-show-hallmarks-of-fraud-1526573115

It's behind a paywall ofc, so you can't actually read it nor can you make your own assessment of the standard of reporting.

Centralised orgs such as the WSJ are constitutionally unable to interact with a network, they will want an official statement from an official source because that's the way their system works, it admits of no alternative.

I'm considering printing out several dozen "Official Slimcoin spokesperson" badges, so we can all have some fun...

"No, Slimcoin is minted by monkee-magic, the dev said so."

"Oh, yes, Slimcoin will still cold-mint from a USB stick entombed in a solid block of concrete sat at the bottom of a frozen river. You may quote me on that."

Cheers

Graham

[bobitza202]

Reporting with some Novaexchange statements:

-"Finally we have tremendous news to share with you. On the 28th of May we will open the market for deposits in the following currencies:
- Bitcoin
- Litecoin
- Dogecoin

Later on you will be welcome to make deposits in other currencies"

"1. We are setting up proper KYC (Know Your Customer) and AML (Anti-Money Laundering) routines on Nova Exchange. For the unidentified account holder there will be a limit for withdrawal of 500 US dollars per day and customer.
If you need to withdraw more than 500 dollars at once this is perfectly possible, all you need to do is to provide us with some information and identify yourself with YOTI (download app here). You will find these settings under “Account” and “Contact & Verification level settings”.

We realise that this is an inconvenience, of course we do, but this is a necessary step to keep Nova in business, and growing!

2. Dice & Scratch functions are discontinued and shut down. We're sorry but us the new owners would need a gambling license to keep those features going. We might be forced to shut down completely if we did. We’re very sorry about this.

3. We will no longer be able to accept customers with citizenship and/or residence in the United States."