mod6's Blog

2020/02/15

Three TRB Vpatches For Testing

Filed under: Bitcoin, Keccak, V — mod6 @ 01:27

I've been working on regrinding three vpatches that are being considered for integration into the current TRB vtree (keccak).

These three vpatches, along with their signatures, are placed into this article (see below) for testing. They have been signed with my 'mod6-vpatch-testing' key. (For those who do not know, I use a secondary key for signing vpatches that are still considered "not final", "experimental", or "testing".)

Here are the vpatches and their seals (signatures) with my 'mod6-vpatch-testing' key. Most importantly, let it not go unsaid: Any vpatch signed with my 'mod6-vpatch-testing' key is for TESTING ONLY. You should NEVER use a vpatch in 'production' or 'battlefield' mode that has been signed with my vpatch testing key. Also, as always, be sure to read ALL code before you put it into use! Only you, dear reader, can be the guardian of your own safety.

Below are the three vpatches, currently in testing, along with their corresponding seals. I am also linking their historical posts to the btc-dev Mailing List.

A. mod6_phexdigit_fix.vpatch  [sig]

   Historical Link for phexdigit_fix:
   * Original post to the btc-dev mailing list

B. mod6_excise_hash_truncation.vpatch  [sig]

   Historical Links for excise_hash_truncation:
     * Original post to the btc-dev mailing list by ben_vulpes
     * Second post, follow up to the original, by ben_vulpes
     * Third post, first regrind of the original by me.
     * Fourth post, second regrind of the original.
       Includes a manifest file, original vpatches and comments incorporated.

C. mod6_whogaveblox.vpatch  [sig]

   Historical Link for whogaveblox:
     * Original post to the btc-dev ML by asciilifeform
   ** New single line change by me in a conditional statement.
      Here's a small snip of a diff of the vpatches:

@@ -16,7 +35,7 @@
 +    // Whose block we are trying.
 +    string peer_ip;
 +
-+    if (pfrom) {
++    if (pfrom != NULL) {

Building a testing vtree with these new vpatches:
1. You'll need a Keccak vtron, find 'starter_v_2.tar.gz' here, by diana_coman.
2. You'll need a full copy of the current TRB vtree (keccak); vpatches and their corresponding seals.
3. Place these in your patches and .seals directories respectively.
4. You'll need to place the vpatches for testing (phexdigit_fix, excise_hash_truncation, whogaveblox) in your 'patches' directory.
5. You'll need to place the their corresponding seals (signed with my 'mod6-vpatch-testing' key) into your '.seals' directory.
6. You'll need to get my main key and place it in your '.wot' directory.
7. You'll need to get my mod6-vpatch-testing key and place it in your '.wot' directory.
8. Now you should have 'mod6_whogaveblox.vpatch' as a single leaf:

mod6@gentoo ~ $ vk.pl l
Leaf: mod6_whogaveblox.vpatch (mod6-vpatch-testing)

9. You should have a flow that looks like this:

mod6@gentoo ~ $ vk.pl f
genesis.vpatch (mod6)
bitcoin-asciilifeform.1.vpatch (mod6)
rm_rf_upnp.vpatch (mod6)
bitcoin-asciilifeform.3-turdmeister-alert-snip.vpatch (mod6)
bitcoin-asciilifeform.2-https_snipsnip.vpatch (mod6)
bitcoin-asciilifeform.4-goodbye-win32.vpatch (mod6)
asciilifeform_dnsseed_snipsnip.vpatch (mod6)
asciilifeform_zap_hardcoded_seeds.vpatch (mod6)
asciilifeform-kills-integer-retardation.vpatch (mod6)
asciilifeform_zap_showmyip_crud.vpatch (mod6)
asciilifeform_dns_thermonyukyoolar_kleansing.vpatch (mod6)
asciilifeform_and_now_we_have_block_dumper_corrected.vpatch (mod6)
mod6_fix_dumpblock_params.vpatch (mod6)
bitcoin-v0_5_3_1-static_makefile_v002.8.vpatch (mod6)
bitcoin-v0_5_3_1-rev_bump.7.vpatch (mod6)
asciilifeform_ver_now_5_4_and_irc_is_gone_and_now_must_give_ip.vpatch (mod6)
asciilifeform_orphanage_thermonuke.vpatch (mod6)
asciilifeform_and_now_we_have_eatblock.vpatch (mod6)
bitcoin-v0_5_3-db_config.6.vpatch (mod6)
asciilifeform_tx-orphanage_amputation.vpatch (mod6)
asciilifeform_maxint_locks_corrected.vpatch (mod6)
asciilifeform_lets_lose_testnet.vpatch (mod6)
asciilifeform_add_verifyall_option.vpatch (mod6)
programmable-versionstring.vpatch (mod6)
mod6_der_high_low_s.vpatch (mod6)
malleus_mikehearnificarum.vpatch (mod6)
makefiles.vpatch (mod6)
asciilifeform_aggressive_pushgetblocks.vpatch (mod6)
mod6_privkey_tools.vpatch (mod6)
mod6_manifest.vpatch (mod6)
mod6_phexdigit_fix.vpatch (mod6-vpatch-testing)
mod6_excise_hash_truncation.vpatch (mod6-vpatch-testing)
mod6_whogaveblox.vpatch (mod6-vpatch-testing)

10. A press-path that looks like this:

mod6@gentoo ~ $ vk.pl pp mod6_whogaveblox.vpatch
genesis.vpatch (mod6)
bitcoin-asciilifeform.1.vpatch (mod6)
rm_rf_upnp.vpatch (mod6)
bitcoin-asciilifeform.2-https_snipsnip.vpatch (mod6)
bitcoin-asciilifeform.3-turdmeister-alert-snip.vpatch (mod6)
bitcoin-asciilifeform.4-goodbye-win32.vpatch (mod6)
bitcoin-v0_5_3-db_config.6.vpatch (mod6)
bitcoin-v0_5_3_1-rev_bump.7.vpatch (mod6)
bitcoin-v0_5_3_1-static_makefile_v002.8.vpatch (mod6)
asciilifeform-kills-integer-retardation.vpatch (mod6)
asciilifeform_and_now_we_have_block_dumper_corrected.vpatch (mod6)
asciilifeform_dnsseed_snipsnip.vpatch (mod6)
asciilifeform_maxint_locks_corrected.vpatch (mod6)
asciilifeform_orphanage_thermonuke.vpatch (mod6)
asciilifeform_tx-orphanage_amputation.vpatch (mod6)
asciilifeform_zap_hardcoded_seeds.vpatch (mod6)
asciilifeform_zap_showmyip_crud.vpatch (mod6)
mod6_fix_dumpblock_params.vpatch (mod6)
asciilifeform_dns_thermonyukyoolar_kleansing.vpatch (mod6)
asciilifeform_ver_now_5_4_and_irc_is_gone_and_now_must_give_ip.vpatch (mod6)
asciilifeform_and_now_we_have_eatblock.vpatch (mod6)
asciilifeform_lets_lose_testnet.vpatch (mod6)
asciilifeform_add_verifyall_option.vpatch (mod6)
programmable-versionstring.vpatch (mod6)
malleus_mikehearnificarum.vpatch (mod6)
mod6_der_high_low_s.vpatch (mod6)
mod6_privkey_tools.vpatch (mod6)
makefiles.vpatch (mod6)
asciilifeform_aggressive_pushgetblocks.vpatch (mod6)
mod6_manifest.vpatch (mod6)
mod6_phexdigit_fix.vpatch (mod6-vpatch-testing)
mod6_excise_hash_truncation.vpatch (mod6-vpatch-testing)
mod6_whogaveblox.vpatch (mod6-vpatch-testing)

As far as my own testing, I have been able to place these vpatches, along with their seals into V, and press all the way up through the single leaf, 'mod6_whogaveblox.vpatch'. After successful press, I was able to successfully compile TRB. I haven't completed any further testing as of yet. Testing is on-going, currently. I anticipate about 7 to 10 days of further testing before completion.

That's all for now -- upon successful testing, will be issuing final signatures with my main key for these vpatches (see above) in a follow up article.

12 Comments »

  1. [...] this month I reground and began testing on three vpatches as detailed in the article . The testing has been completed and they are working as [...]

    Pingback by Multiple Vpatches Tested And Signed « mod6's Blog — 2020/02/25 @ 21:20

  2. In mod6_manifest.vpatch: I don't get the trb_keccak_regrind "not a vpatch" manifest line; notes about the genesis relative to another universe would belong on the entry for the genesis patch, no?

    In mod6_whogaveblox.vpatch: you know, if(x!=NULL) is semantically identical to if(x), and not inconsistent with style elsewhere in the file, so I don't see why it needed changing.

    Otherwise, looks good and presses, including the antecedent mod6_privkey_tools.vpatch.

    Comment by Jacob Welsh — 2020/04/10 @ 01:14

  3. > In mod6_manifest.vpatch: I don't get the trb_keccak_regrind "not a vpatch" manifest line; notes about the genesis relative to another universe would belong on the entry for the genesis patch, no?

    Indeed, the entire tree is now in a separate Keccak universe from the original SHA512 universe; from genesis.vpatch all the way through mod6_whogaveblox.vpatch (current HEAD).

    The short answer to what this 'mod6_manifest.vpatch' accomplishes are two things: 1. It introduces the 'manifest' file to the project. 2. It ties up all of the leaves in the vtree. As you may, or may not be aware, historical implementations of V were not permitted to press to more than one leaf; you were to pick one and press to it only. To avoid complications for users, when the TRB vtree was in what was considered a "release" or milestone state, the leaves would be simply "tied up" in a similar way to this (see 'makefiles.vpatch'). Thus rendering the TRB vtree with a single leaf in which to press (see TRB DAG).

    Perhaps I could have worded that more clearly in the manifest file.

    > In mod6_whogaveblox.vpatch: you know, if(x!=NULL) is semantically identical to if(x), and not inconsistent with style elsewhere in the file, so I don't see why it needed changing.

    While reviewing asciilifeform's 'whogaveblox' again, I did kick the idea of this around. There was a short discussion in his channel. Decided on it for the sake of clarity.

    > Otherwise, looks good and presses, including the antecedent mod6_privkey_tools.vpatch.

    Alright, thanks for testing.

    Comment by mod6 — 2020/04/13 @ 21:25

  4. Nah, I get the addition of the manifest and bumping of previously unreferenced patch outputs to ensure presses will include them. I was asking about this particular line in the manifest:

    > 614342 trb_keccak_regrind mod6 Not a patch, whole TRB tree keccak regrind; Also removes UTF-8 char from original genesis.vpatch

    Which after subsequent backfilling of the manifest (in mod6_excise_hash_truncation.vpatch) isn't even the first line anymore. As there's no trb_keccak_regrind.vpatch, this doesn't seem to fit with the purpose of the manifest.

    Comment by Jacob Welsh — 2020/04/22 @ 00:24

  5. I believe asciilifeform is mistaken there about NULL, in the same way I once was. It's true that a null pointer might not be stored internally as all-zero bits; that is, int *p = NULL; *(int*)&p == 0 does not necessarily evaluate to true (for example on a machine with tag bits). However, int *p = NULL; p == 0 can be relied on, and thus if (p) likewise. See for example C89 3.2.2.3:

    > An integral constant expression with the value 0, or such an expression cast to type void * , is called a null pointer constant. If a null pointer constant is assigned to or compared for equality to a pointer, the constant is converted to a pointer of that type. Such a pointer, called a null pointer, is guaranteed to compare unequal to a pointer to any object or function.

    Relatedly, a global or locally-static pointer variable can be assumed to start out NULL, per 3.5.7:

    > If an object that has static storage duration is not initialized explicitly, it is initialized implicitly as if every member that has arithmetic type were assigned 0 and every member that has pointer type were assigned a null pointer constant.

    Comment by Jacob Welsh — 2020/04/22 @ 00:40

  6. @Jacob Welsh:

    I'm aware re the C89 statement. But believe it or not, have personally encountered compilers where NULL != 0. E.g. '90s Watcom CPP under DOS4GW (yes.) Could debate whether this is pertinent re current or expected ports of TRB; but the habit stuck. And in general I don't like to rely on the sanity of the compiler re "fine points" of written spec, when such reliance can be easily avoided.

    Comment by Stanislav Datskovskiy — 2020/04/27 @ 17:23

  7. > Nah, I get the addition of the manifest and bumping of previously unreferenced patch outputs to ensure presses will include them. I was asking about this particular line in the manifest:

    I could have left the following line out of the manifest:

    > > 614342 trb_keccak_regrind mod6 Not a patch, whole TRB tree keccak regrind; Also removes UTF-8 char from original genesis.vpatch

    However, I wanted to denote, via block height, when this regrind was published in the main TRB tree as well as the update for the removal of the UTF-8 character. I do realize that the 'trb_keccak_regrind' portion is a bit sticky as it isn't an actual vpatch; made a choice just to follow the common formatting.

    > Which after subsequent backfilling of the manifest (in mod6_excise_hash_truncation.vpatch) isn't even the first line anymore. As there's no trb_keccak_regrind.vpatch, this doesn't seem to fit with the purpose of the manifest.

    I don't understand this comment, exactly. In mod6_excise_hash_truncation.vpatch the last line (which maybe you mean by using 'first line', or 'most recent') of the manifest file reads:
    +617254 mod6_excise_hash_truncation mod6 Regrind of ben_vulpes original; removes truncation of hashes printed to TRB log file

    Comment by mod6 — 2020/04/27 @ 17:29

  8. @Stanislav Datskovskiy: I see, thanks for that history. Whether NULL is true or false seems to me more of a fundamental point than a fine one; I mean, imagine something calling itself a CL where NIL wasn't false... [/me braces for an example of such]

    @mod6: it was a minor part of the point: trb_keccak_regrind was initially the first (topmost) line of a small manifest, then after mod6_excise_hash_truncation expanded the history it found itself in the middle. Which makes sense given the aim of noting the chronology.

    Thinking on it now, it seems the block height in the manifest should reflect publication time of the concrete patch in the tree, rather than trying to capture out-of-universe history of previous editions. Though perhaps at some point a more formal mechanism than the comments will become necessary for that,

    Comment by Jacob Welsh — 2020/04/28 @ 15:37

  9. @Jacob Welsh: further re "does NULL always equal 0?" -- I suspect that they can be expected to be unequal even on certain modern platforms which lack a MMU. (Again, whether anyone will ever port TRB to such, is an open question.)

    Comment by Stanislav Datskovskiy — 2020/04/28 @ 15:47

  10. Then it's the damn compiler's job to convert comparisons of pointers with constant "0"s to the actual magic number involved, that is, to implement the language or else not call itself a CC. /rant

    I wonder now if this goes back to K&R (The C Programming Language); anyone got a digital copy?

    Comment by Jacob Welsh — 2020/04/28 @ 15:59

  11. @Jacob Welsh:

    http://nosuchlabs.com/pub/warez/k_and_r.pdf

    Comment by Stanislav Datskovskiy — 2020/04/28 @ 20:31

  12. @Stanislav Datskovskiy: thanks! also found a scanned first edition at https://archive.org/download/TheCProgrammingLanguageFirstEdition .

    Comment by Jacob Welsh — 2020/04/30 @ 18:34

RSS feed for comments on this post. TrackBack URL

Leave a comment

Powered by WordPress