2023-10-25 08:05:26.364 [INF] SYNC: Processed 9 blocks in the last 17.17s (29870 transactions, height 798533, 2023-07-13 12:21:29 -0100 -01)

2023-10-25 08:05:38.744 [INF] SYNC: Processed 3 blocks in the last 12.37s (11243 transactions, height 798536, 2023-07-13 12:34:47 -0100 -01)

2023-10-25 08:05:40.443 [INF] SYNC: New valid peer 103.99.170.210:8333 (outbound) (/Satoshi:0.21.2(@wiz)/)

2023-10-25 08:05:40.646 [INF] SYNC: New valid peer 198.244.167.179:8333 (outbound) (/Satoshi:24.0.1/)

2023-10-25 08:05:40.688 [INF] SYNC: Lost peer 198.244.167.179:8333 (outbound)

2023-10-25 08:05:50.350 [INF] SYNC: Processed 6 blocks in the last 11.6s (17808 transactions, height 798542, 2023-07-13 13:44:22 -0100 -01)

2023-10-25 08:06:00.434 [INF] SYNC: Processed 6 blocks in the last 10.08s (18691 transactions, height 798548, 2023-07-13 16:02:05 -0100 -01)

2023-10-25 08:06:11.642 [INF] SYNC: Processed 6 blocks in the last 11.2s (18807 transactions, height 798554, 2023-07-13 16:45:27 -0100 -01)

2023-10-25 08:06:18.577 [INF] SYNC: Lost peer 54.253.15.33:8333 (outbound)

2023-10-25 08:06:22.013 [INF] SYNC: Processed 7 blocks in the last 10.37s (19734 transactions, height 798561, 2023-07-13 18:17:21 -0100 -01)

2023-10-25 08:06:32.756 [INF] SYNC: Processed 6 blocks in the last 10.74s (16995 transactions, height 798567, 2023-07-13 19:13:40 -0100 -01)

2023-10-25 08:06:37.157 [INF] SYNC: New valid peer 70.161.65.159:8333 (outbound) (/Satoshi:22.0.0(FutureBit-Apollo-Node)/)

2023-10-25 08:06:44.691 [INF] SYNC: Processed 6 blocks in the last 11.93s (15897 transactions, height 798573, 2023-07-13 20:09:51 -0100 -01)

2023-10-25 08:06:55.634 [INF] SYNC: Processed 8 blocks in the last 10.94s (24698 transactions, height 798581, 2023-07-13 22:59:08 -0100 -01)

2023-10-25 08:07:05.744 [INF] SYNC: Processed 7 blocks in the last 10.1s (17245 transactions, height 798588, 2023-07-14 00:04:34 -0100 -01)

2023-10-25 08:07:11.855 [INF] SYNC: New valid peer 168.119.68.43:8333 (outbound) (/Satoshi:0.16.3/)

2023-10-25 08:07:11.855 [INF] SYNC: Lost peer 168.119.68.43:8333 (outbound)

2023-10-25 08:07:16.082 [INF] SYNC: Processed 6 blocks in the last 10.33s (13299 transactions, height 798594, 2023-07-14 01:21:14 -0100 -01)

2023-10-25 08:07:26.566 [INF] SYNC: Processed 6 blocks in the last 10.48s (15132 transactions, height 798600, 2023-07-14 02:26:26 -0100 -01)

2023-10-25 08:07:37.472 [INF] SYNC: Processed 8 blocks in the last 10.9s (22857 transactions, height 798608, 2023-07-14 04:01:09 -0100 -01)

2023-10-25 08:07:48.002 [INF] SYNC: Processed 8 blocks in the last 10.53s (28166 transactions, height 798616, 2023-07-14 05:19:14 -0100 -01)

2023-10-25 08:07:51.567 [INF] SYNC: New valid peer 20.29.44.86:8333 (outbound) (/Satoshi:25.0.0/)

2023-10-25 08:07:58.681 [INF] SYNC: Processed 5 blocks in the last 10.67s (15913 transactions, height 798621, 2023-07-14 06:10:17 -0100 -01)

2023-10-25 08:08:09.307 [INF] SYNC: Processed 5 blocks in the last 10.62s (20392 transactions, height 798626, 2023-07-14 06:54:57 -0100 -01)

2023-10-25 08:08:20.591 [INF] SYNC: Processed 7 blocks in the last 11.28s (28490 transactions, height 798633, 2023-07-14 07:45:01 -0100 -01)

still going pretty fast but perhaps it takes time for it to cache up all the chain DB that would mean it will get closer to its peak the longer it runs.

haha. oops, forgot to actually enable these things in the configuration, didn't notice the comment in front.

immediately the CPU usage went up to almost double normal just starting up,

well, it sure looks like it's working harder but yeah, 2000tx/s...

not sure i've really gained much over the 24 threads/300% GC heap allocation but i'll leave it that way anyway, since i'm not gonna run it full time, it's a dev node, which i've not got a direct use for at the moment.

out of curiosity i increased the threads, because as i understand it, the number of threads can increase the parallel execution of searches of chain history for transactions during validation.

i set the threads to 256 this time, and now it is running between 25-30ktx/s

probably worth bumping the memory use too since i have 20gb memory.

Yesterday I modded btcd to use a SIMD SHA256 hash function and greatly increased its parallel threads to 3 per physical thread and set to run with 300% normal garbage collector heap allocation.

so, in short terms, it preallocates a lot more memory and it runs triple the normal number of threads (which is set to the number of CPU threads, which is half the number of cores, so that's 4 cores on my lenovo ideapad3 with ryzen 5, meaning 8 threads and 24 parallel goroutines).

the first of these is especially good but the three of them show the performance boost in initial block download and validating the transactions and putting them into the database is way faster:

2023-10-25 07:48:38.126 [INF] SYNC: Processed 11 blocks in the last 10.66s (47083 transactions, height 797983, 2023-07-09 15:53:47 -0100 -01)

2023-10-25 07:48:49.143 [INF] SYNC: Processed 7 blocks in the last 11.01s (20232 transactions, height 797990, 2023-07-09 17:01:00 -0100 -01)

2023-10-25 07:48:59.190 [INF] SYNC: Processed 8 blocks in the last 10.04s (27234 transactions, height 797998, 2023-07-09 18:01:45 -0100 -01)

47k transactions in 10 seconds means it's doing 4700 tx/s, which is nearly 2.5% the vanilla configuration with threads set to limit at standard and GC set to 100.

clearly also the use of the SIMD SHA256 is helping as well.

some more, coming through now:

2023-10-25 07:54:15.237 [INF] SYNC: Processed 10 blocks in the last 10.04s (39948 transactions, height 798219, 2023-07-11 04:35:03 -0100 -01)

2023-10-25 07:54:26.682 [INF] SYNC: Processed 9 blocks in the last 11.44s (37835 transactions, height 798228, 2023-07-11 05:38:01 -0100 -01)

2023-10-25 07:54:36.739 [INF] SYNC: Processed 6 blocks in the last 10.05s (21489 transactions, height 798234, 2023-07-11 06:21:06 -0100 -01)

2023-10-25 07:54:46.868 [INF] SYNC: Processed 7 blocks in the last 10.12s (20932 transactions, height 798241, 2023-07-11 07:22:57 -0100 -01)

as you can see, it's keeping well above 2000tx/s throughput, hitting 4000tx/s often.

this is nearly a doubling of performance. 100% worth it and only took about 60 lines of code to change it this way.

i also had proposed to have part of this (not the SIMD SHA256 library) added to btcd over a year ago.

nobody cares, apparently.

from: https://avatars.githubusercontent.com/u/10235229 - the avatar of the 'btcsuite' github org.

what's the first thing that springs to mind when you look at this image?

https://bitcoinops.org/en/preparing-for-taproot/#is-taproot-even-worth-it-for-single-sig

tl;dr:

yes, it's substantially smaller on-chain, 211vBytes vs 245vBytes.

and better:

> For P2TR, the exact size of the signature is

known in advance, allowing the wallet to reliably choose a precise

feerate.

https://dev.to/eunovo/more-on-taproot-41g8

this gives an explanation of how to turn a private key into a taproot address in a way that i can actually understand.

why did the taproot devs have to call it 'tweaking'

tweaking is a) being high on meth and b) making a small adjustment

what 'tweaking' actually does is make it possible for the owner of the private key who also knows the tweak factor to either spend or script spend sats.

it's much more recognisable to my mind as being like a master key, in that it can open multiple locks that also have their own specific keys.

cos i'm pretty sure you can argue the point that allowing a script spend is like generating an array of slave subkeys that the master can open.

ah yeah, the woke brainwashing has been trying to wash people's minds of the idea of having masters.

that's so they can be masters without us having a word for it.

a lot of things are being thrown in the memory hole. all kinds of tech things are getting really hard to locate too.

it feels like the burning of the library of alexandria.

i lament that i can't cache more data but it's all in my memory if i read it already.

they are intent on igniting the whole ME and north africa.

'defending israel' is just code for 'advancing the colonization of the oil country'.

the studies seem to say that it doesn't affect T levels directly but i feel like a wild billy goat on it.

i have to be really careful, gotta learn to listen instead of attacking the obvious flaw in the premise of what i'm hearing, so i can circle back round and nail that thing after they have their fun.

oof, holy shit, don't underestimate maca....

i am not used to having this much drive, at all. it's making me argue with people for no reason.

haha, l0k1 is me... changing the handle with the move to madeira and all the new things...

i'm just finishing off a last piece of signr, the tooling/CLI that does the signatures to support taproot, i think this will finally mean i can move to another part of the work next - specifically it will be a minimal to start with, with commits, tags, staging, stashing, etc, configuration, but the main point of the exercise is that to include schnorr signatures into git as it stands is not very easy. the reason is that the way they included ssh signing, was by gpg supporting ssh. so either way, you have needing to dig into the official git, or the official gnupg, both of these are very rigid, old, C language code, whereas go-git has got all but the more esoteric features of the official git, so it is simple to insert the nostr/taproot signatures and we can also simplify the UX a little and make it easier in the more common use cases.

just wanna point out also, gitea is much much faster than github, it has issues and wiki, and it would be easy to layer in the nostr social layer to add forums and discussions and it would be simple to turn issues into nostr threads and so on.

nostr:nevent1qqsgk3eeyl6h3vvl5y0hvhgudzu9gc0pfglkdyyflapx960jqhhyqnsppemhxue69uhkummn9ekx7mp0qythwumn8ghj7un9d3shjtnwdaehgu3wvfskuep0qyg8wumn8ghj7cfwdehhxtnvdakz7qghwaehxw309ash2tnjv4kxz7tpvfkx2tn0wfnj7qgkwaehxw309a3x2an09ehx7um5wgcjucm0d5hsz9mhwden5te0vf5hgcm0d9hx2u3wwdhkx6tpdshszythwden5te0dehhxarj9emkjmn99uq3vamnwvaz7t6zv4mx7tnwdaehgu339e3k7mf0qyvhwumn8ghj7ct99ec82unsd3jhyetvv9ujucm0d5hszxnhwden5te0dehhxarj9ecxcetzvd5xz6tw9ehhyee0a96405

(just re-bumping to get this looking better in preview)

it's quite technical, i'm working on a tiny part of the cryptography for

this project, but this is a technology that will enable fully

decentralised git hosting, with the metadata broadcast over nostr and

available to any nostr relay running HORNET storage, watches the

blockchain and can automatically detect updates for the files knowing

what to ask for by the signed merkle root from peers, get the tree of

parts and inventory each part one by one.

as well as enabling

decentralised, distributed git hosting, it will also be applicable to

nostr profiles as well, where you will be able to periodically snapshot

updates to your profile and then all subscribers can quickly learn about

a new batch of updates and get every single one of them.

this is the most exciting thing in my opinion, because it means that

user data can be easily gathered for followers, and stuff like being

able to enable paid relays to fully sync their users' subscriptions

proactively.

it's quite technical, i'm working on a tiny part of the cryptography for this project, but this is a technology that will enable fully decentralised git hosting, with the metadata broadcast over nostr and available to any nostr relay running HORNET storage, watches the blockchain and can automatically detect updates for the files knowing what to ask for by the signed merkle root from peers, get the tree of parts and inventory each part one by one.

as well as enabling decentralised, distributed git hosting, it will also be applicable to nostr profiles as well, where you will be able to periodically snapshot updates to your profile and then all subscribers can quickly learn about a new batch of updates and get every single one of them.

this is the most exciting thing in my opinion, because it means that user data can be easily gathered for followers, and stuff like being able to enable paid relays to fully sync their users' subscriptions proactively.

nostr:nevent1qqsgk3eeyl6h3vvl5y0hvhgudzu9gc0pfglkdyyflapx960jqhhyqnsppemhxue69uhkummn9ekx7mp0qythwumn8ghj7un9d3shjtnwdaehgu3wvfskuep0qyg8wumn8ghj7cfwdehhxtnvdakz7qghwaehxw309ash2tnjv4kxz7tpvfkx2tn0wfnj7qgkwaehxw309a3x2an09ehx7um5wgcjucm0d5hsz9mhwden5te0vf5hgcm0d9hx2u3wwdhkx6tpdshszythwden5te0dehhxarj9emkjmn99uq3vamnwvaz7t6zv4mx7tnwdaehgu339e3k7mf0qyvhwumn8ghj7ct99ec82unsd3jhyetvv9ujucm0d5hszxnhwden5te0dehhxarj9ecxcetzvd5xz6tw9ehhyee0a96405

i can recommend glutamine powder also.

also just want to point out i wrote СССР just not in cyrillic as i did this time.

soyuz na sovyet sotsialistichni republiki.

chinese level of tyranny was teams of hazmat suited children walking through the town parroting propaganda and reporting their neighbours.

chinese level of tyranny is drones with loudspeakers and remote cameras shouting at people.

chinese level of tyranny is people being kidnapped by teams of "doctors" in hazmat suits and who the fuck knows where they end up because they never came home.

standard of living is neither going up nor down but the appearance of wealth is being increased, by culling the herd and giving their resources to favourites.

it's still tyrannical. it's 1984 in china, while usa is brave new world.

after just two days, and measly amounts of sugar, maybe a teaspoon or two a day, i'm getting cravings for more.

or more exactly, i am feeling cranky, and cold, a little bit like a junky coming off heroin.

i really hate this, not sure what to do about it but it sure motivates me to bad behaviour, and that is really disturbing me.

when this bag of maca/cacao/coconut sugar powder is gone no way no how no sugar in my diet. the maca is doing good things, i think, but the sugar is way way bad.

it's not for nothing there is a connection between poverty, violence and carbohydrates... and they want everyone to be on high carb, low fat diets. doesn't take a genius to figure out they are actively promoting bad behaviour.

i haven't got a lot of actual task done today...

there is now a standard base58check private key encoder done, and i'm reading code on how segwit v2 (native segwit) and taproot addresses are encoded, probably will get this done.

but i'm having an experience with myself that i haven't really had before - that of being doggedly determined but calm enough to keep slogging until i figure out wtf is going on, and make some progress.

i seem to very often have much bigger and more rigid images of what i should try to achieve than what actually needs to be done.