Comments on: Draft gbw-node frontend, part 2

By: Smartening up gbw-node « Fixpoint

Smartening up gbw-node « Fixpoint — Wed, 05 Apr 2023 01:38:14 +0000

[...] a dramatic reduction in scan time overhead per block, and finally a path toward full removal of the sorest point, the notorious dumpblock [...]

By: Gales Bitcoin Wallet (re)release « Fixpoint

Gales Bitcoin Wallet (re)release « Fixpoint — Fri, 03 Dec 2021 08:59:53 +0000

[...] presentation of Python code for the node extension: 1, 2, 3, 4, 5, [...]

By: Alert: dumpblock flaw in bitcoind can cause gbw-node to incorrectly report transactions « Fixpoint

Sun, 20 Jun 2021 05:21:47 +0000

[...] gbw-node as a small component, trusting the data it receives from a local Bitcoin daemon, and I used dumpblock for lack of alternatives, it can thus import bad transaction data into its SQLite database and incorporate it in the derived [...]

By: GBW-NODE : Gales Bitcoin Wallet Node verified acquisition, build, install and run in 21ish short, simple steps. « Dorion Mode

Sat, 18 Jul 2020 14:56:22 +0000

[...] F. Welsh (WoT : jfw) which he documented on Fixpoint through his work with JWRD Computing in a 1 2 3 4 5 6, count'em, 6 article [...]

By: Draft gbw-node frontend, part 5 « Fixpoint

Draft gbw-node frontend, part 5 « Fixpoint — Sun, 19 Jan 2020 19:03:23 +0000

[...] 1, 2, 3, 4 [...]

By: Draft gbw-node frontend, part 4 « Fixpoint

Draft gbw-node frontend, part 4 « Fixpoint — Sun, 19 Jan 2020 16:38:10 +0000

[...] 1, 2, 3 [...]

By: Jacob Welsh

Jacob Welsh — Fri, 17 Jan 2020 17:49:57 +0000

Alright, thanks.

By: Stanislav Datskovskiy

Stanislav Datskovskiy — Fri, 17 Jan 2020 17:31:32 +0000

...do you see this use of named pipes as an abuse of the spirit...

Can't see why it would be "an abuse".

...Any particular reason you used the filesystem there rather than sending through the JSON-RPC response...

Wanted to avoid either shitting binariola to stdout (no other TRB knob does this, and it is generally unwanted behaviour) or, alternatively, the need for 7bit-clean encodings (e.g. base64) (avoided, to keep the patch small and eliminate req for post-processing.)

The "dumpblock" knob was orig. made for fast export of raw blocks, for archival, quick analysis, and (later) fast-sync of newly-built boxen. For this, the "dump to fs" mechanism sufficed. For your application it would IMHO make sense to patch TRB to cleanly get at the items you want.

By: Jacob Welsh

Jacob Welsh — Fri, 17 Jan 2020 00:16:52 +0000

@Stanislav Datskovskiy: indeed, and I had observed this behaviorally. I'm curious though: do you see this use of named pipes as an abuse of the spirit of "dumpblock"? Any particular reason you used the filesystem there rather than sending through the JSON-RPC response ala PRB "getblock"?

By: Stanislav Datskovskiy

Stanislav Datskovskiy — Thu, 16 Jan 2020 19:11:23 +0000

do we know for sure that only validated blocks get written to these files?

FTR, blocks that got "orphaned" in reorg in fact remain permanently in blk* files. TRB has no provision for their removal. This is why very rarely two installations have bitwise-identical blk* data.