Avatar
nomadshiba⚡
45835c36f41d979bc8129830f2f5d92562f5343d6feddd6f30aa79480730f26e
- knotzi ₿ - #ArchiveCore - 300KB blocks i make stuff (rabbit hole for other links) https://github.com/DeepDoge get your npub name https://npub.name in case you wanna send more bitcoin, i also accept silent payments: sp1qqwdknqgz7v2ph8hxjc9t2nz3frqazjkhu7c5ar5w03tn0amw3ugrsq5zmaznxjuce70l6p47t5vm25qngxnwqgk025csgr735uds0y9wsgjkuhfc

GN, sometime my gramer go weird

why am i not using ecs for my bitcoin implementation?

bitcoin is not that heavy. running bitcoin is easier than simulating some games.

would it be better?

probably.

but bitcoin is not that complex that it needs ecs to organize it.

we know what can be in parallel and what cant be. many things are simple enough and are short tasks that can just run on the main thread. we will already jump in memory to check scriptPubKey and many other indexes. it would be overkill. bitcoin is not complex, reimplimenting quirks, and changes core did over the years is complex.

more important thing is keep the codebase as simple as codebase of a simple web app.

if you are into game dev stuff and also into ECS, i highly recommend this ECS framework: https://friflo.gitbook.io/friflo.engine.ecs

its really amazing.

also, if you dont know what is ECS or mix ECS with EC-Frameworks, you should read this:

https://github.com/SanderMertens/ecs-faq

we will see if my storage optimizations on my own bitcoin implementation actually optimizes for storage without making things too slow before end of October hopefully. if something doesnt come up.

if i can actually manage it, i will go all the way in the following years to make a bitcoin implementation that is user friendly and has better ux. and it will also be a dev friendly and less intimidating codebase that is easy to fork understand and change without too much dev experience.

as long as it can sync under 3-4 days with a good internet connection its worth it.

it will be a long journey. i have a lot to learn, discover and fix. there will be lots of bugs, issues, and chain splits.

I don't think Knots or Luke are perfect, but they are the best option at this time.

Knots still lacks stuff Core also lacks and nobody is filling that hole.

I believe we will have more node implementations.

We should.

The MOST important thing for Bitcoin:

- is not scaling

- is not use cases

- is not privacy

- is not speed

The MOST important thing is its staying decentralized.

Core never worked to make their client more user friendly, they never tried to make running a full node easier. They never really tried to make more people use their client. All they did was modifying Bitcoin, being Bitcoin Devs, instead of Client Devs.

They are obsessed with being a Bitcoin Dev, changing things instead of creating better clients with more abilities for more people. Like some game devs, they kept adding bloat as the time passed. Made running a node harder instead of making it easier, making the UX better.

Core wants to be the CEO of Bitcoin. Not a humble Bitcoin Client that serves to users.

in case yt decides to nuke my comment on this video:

https://www.youtube.com/watch?v=smSCQ0RyFZg

im gonna copy paste my comment here:

core side doesnt make any technically good arguments, they are just brain gymnastics to validate what they are doing. nothing they say is advanced. they are just excuses that doesnt make any sense. only makes sense if you know nothing. they throw the word "technical" like what they are saying makes any technical sense.

policy rules effective when mining is not centralized.

policy rules are not consensus because they are suppose to be dynamic against exploits. otherwise we will do forks every time we wanted to change them.

just because sometimes policy rules can be broken doesnt mean they dont work.

most of the OP_RETURNS are under 80 bytes because that what the network policy says.

policy is as powerful as consensus when the mining and the network is decentralized.

inscriptions was always technically possible before taproot as well.

only reason inscriptions didnt exists back then was witness script for segwit v0 has a size limit in the policy.

yes another policy that worked. BUT core removed this limit for taproot tapscripts.

taproot itself didnt enable inscriptions. the removal of script size limit POLICY did.

so inscriptions are possible because core removed another filter before.

not to mention inscriptions are easy to filter as well, if they didnt have a pattern that we can recognize them with they wouldnt have an explorer.

before utxo size exploded luke actually create a PR to filter the inscriptions exploit.

but core didnt merge it.

and now they are telling you only way to stop inscriptions is by raising OP_RETURN.

they are giving you a "solution" to a problem they created and refused to fix.

you dont need consensus changes to stop arbitrary data we were able to stop them before core removed policies.

9:44 that's not encryption.

OP_RETURN debate is what made this debate popular. but before OP_RETURN the debate was why core isnt filtering the inscriptions.

Citria is a shipcoiner. are you really going to bend what bitcoin is to allow more use cases for a company like Citria? Bitcoin is a company or a law of nature? Core is acting like the CEO of bitcoin.

you can stop both OP_RETURN and inscriptions at the same time.

like we did before.

you never need full data on the blockchain you can just put the hash of it on the chain.

and if you only allow small data on the chain like we did before core removed the script size limit with taproot update. they would have had to use the hash instead.

UTXO set exploded because core itself removed the script size limit policy.

then refused to filter inscriptions and other similar stuff. they created the problem.

one can ask the question "did they create the problem to give you the 'solution'".

the thing that prevents that kind of imagery in the bitcoin atm is because they have to go through slipstream which itself filters the txs based on content.

yes we stop data storage but then core changes stuff again which makes it possible.

spammers lose money spamming the chain because we make it difficult. if we dont make it difficult they will not be spending more money.

empty blocks are not something bad. empty blocks means blockchain is growing less, which is good for the decentralization of the network. it means more people can run full nodes longer.

miners almost all of the time dont include OP_RETURN data passing 80 bytes because policy works.

also if miners add bunch of txs nobody on the network propagated to each-other and dont know about then propagation of that block slows down on the network. which creates a risk for the miner, because then if somebody else finds a block at the same time without those txs that doesnt fit the policy it will propagate on the network faster and make the block of spam miner stale. this is partly why slipstream costs more money, because miners risk losing the block. policy costs them money. not to mention we can delay those blocks on purpose in the future.

fake addresses are expensive. and even more obfuscated.

doesnt matter how many methods there are. you can detect popular ones, and filter them. stop it from becoming big.

its easy to detect inscriptions in any format.

if filters are keep updating to stop the spammers they cant meaningfully grow a community.

they have a community rn because core allowed it for years now.

if we stop them like we did before. they get frustrated and go create other things like "ethereum".

thats why there is discussion on knots that also wanna add scriptable filters.

also filters dont need to update fast. there are only so many ways to store data on bitcoin that is economically feasible. you can stop them easily. when you filter them as they get popular.

again core thinking consensus is the only way to fight spam.

but its the opposite, consensus is not an option.

and filters are the only way, because they are policy and dynamic.

mining centralization with DATUM is the way, but many people at core dont ever wanna say the name DATUM.

if miners dont follow the policy they lose money in the long run because of stale blocks.

they accept out-of-band txs at a premium, which makes spam more expensive.

and they also filter those out-of-band txs themselves as well.

22:00 omg not this again, blaming the one warning you instead of the threat itself.

core is too sinister with these. everything to this point everything they did.

they are creating a "technical point" soup and mix everything so you cant see the reality get lost in "technical points" that makes no sense in reality.

bitcoin is decentralized its suppose to have divisions and fights.

20:45 yet you are just repeating everything an email told you in a video.

24:20 Core opened the flood gates already, they are just opening more as "solution"

one of core's point is: "out-of-band txs cause mining centralization". first it costs more for miners to include those txs. but most importantly, your solution to mining centralization is allowing more arbitrary data on the blockchain? what about DATUM? core never mentions DATUM. just run DATUM and filter spam. policy as powerful as consensus when mining is decentralized. and unlike consensus, policy allows flexibility in the network.

24:50 we need to divide, and one community needs to die of. people mix decentralization with democracy all the time. decentralization allows multiple outcomes, multiple options to exists in parallel like in the free market. but in democracy only allows one outcome. in democracy bad decisions of the collective entity cause the thing to die. in decentralization both outcome can live together at the same time in parallel and tested by the real world, and one stays live longer.

25:10 that's the issue, once you kill bitcoin as a money none of the things you said matters. most important thing for bitcoin is not scaling, is not use cases, is not privacy, is not speed, the most important thing is its staying decentralized. core never worked to make their client more user friendly, they never tried to make running a full node easier. they never really tried to make more people use their client. all they did was modifying bitcoin, being bitcoin devs, instead of client devs. they are obsessed with being a bitcoin dev. changing things. instead of creating better clients with more abilities for more people. like some game devs, they kept adding more features as the time passed, made running a node harder instead of making it easier, instead of making the ux better. core is wants to be the ceo of bitcoin. not a bitcoin client.

posted it for the memes but i think its called "tank trouble beta"

"every tx is valid bro"

"its all just 1s and 0s bro"

"its just all just data bro"

"its a database"

"thats censoring" nostr:nevent1qqswk5w6f36jqvuv8tpkpwezve9fqfu327pyszmx5709mppw5jnfj4cvvycn4

"every tx is valid bro"

"its all just 1s and 0s bro"

"its just a all data bro"

"its a database"

"thats censoring"

numbers are correct, but they add a big customs fee. and only way im profitable in btc is if i borrow usd against my bitcoin. gonna buy one first to test what happens in the customs. then gonna buy 3 more maybe.

my guess is someone was running a bunch of core nodes to bump the counts up, because it was hardly going down, staying flat.

so before turning them off, they also ran bunch of knots nodes as well. so they can pull them out at the same time as the core. nodes.

so its not like bunch of core nodes disappearing at the same time, but bunch of core and knots node disappearing at the same time.

but in reality, knots went up to 20%,

core went down from 20k nodes to 16k nodes

no version of core patched against inscriptions

Why knot just limit the Tabscript size like it was with SegWit v0?

Oh wait Luke already opened a PR for it and core rejected it.

There was NOTHING stopping inscriptions from existing pre-Taproot at SegWit v0 except the script size limit policy (filter).

The only reason inscriptions use Tapscript is because there is no size limit filter. nostr:nevent1qqsq4m8es9z2ylyy4et9ys2qysv79zumsjy9maqhcv9wyqvrkjkltsgtsgxcf

the whole idea block propagation speed being slow makes mining more centralized makes no sense. its based on the idea that there is already a centralization... so dumb.

just mine with DATUM, solved

blossom is great for blob data, if you not using it on nostr you should, many clients support it. actually you are probably using it without knowing.

https://github.com/hzrd149/blossom

filters them as well.

shows only the ones that are not spam and only consolidations.

the repo:

https://github.com/Retropex/mempool

sleeping now, promise nostr:note1kaa5gmgjda2pwt38cpz22hufxylzuzxjaqyv5qal0j97376yqyushsq49x

i have never think of this before.

so Ocean is more profitable for the miners, both because the way they distribute the rewards, but also because these miners protecting bitcoin from parasites. so on the long run they are basically protecting their and all of humankind's future (aka bitcoin).

so these miners use DATUM which is recommended to be used with Knots.

so as Ocean gets more miners. Knots node count will also go up as well.

nostr:nprofile1qqs8fl79rnpsz5x00xmvkvtd8g2u7ve2k2dr3lkfadyy4v24r4k3s4sh8dmel When will Ocean open source the DATUM Prime. do we have to reverse engineer it? or there is something like a documentation on how it communicates with the DATUM Gateway? nostr:nevent1qqs9mjqcdsuy9xcul2gtn3dsdtj0p3a8qdz5usn9mz7yvk58mwachecmnvjsk

you dont like bitcoin. you like the thing in your mind that you named "bitcoin".

bitcoin doesnt make it possible, current changes of core does.

i explained things in my long post you probably read and still replied with this. so i dont think you are answering based on anything i said atm. and im not gonna repeat myself.

for other plebs here: nostr:nevent1qqspkljq077pacvj5h2pq9yq8rzq247edcu6ctgfy4urkhjmz8n25rc9lqpru

oh didn't realize you were a bitcoin hater

the wording is hilarious. "censorship" of parasite protocols, abusing the bitcoin monetary network instead of having their own network.

is that your definition of censorship? things weren't even possible if core didn't changed the constant script size policy for the tapscript.

Replying to Avatar nomadshiba⚡

just to add some details: tapscript size being unlimited caused the inscriptions, which is in the witness data. before taproot, with segwit v0 there was a P2WSH script size limit, which limits the size of witness while spending a P2WSH output.

https://github.com/bitcoin/bitcoin/blob/fc06881f13495154c888a64a38c7d538baf00435/src%2Fpolicy%2Fpolicy.h#L47

this whole file is about policy settings, aka filters. these settings are policy so we don't have to fork the chain each time we wanna change these.

if you are asking what does this have to do with P2WSH, witness data is in the input side of the tx. so meaning of witness data is decided by scriptPubKey of the output we are spending.

of course inscriptions were possible before taproot, but only really small images. or you had to split it into multiple inputs. which increases the total size and fee you have to pay.

tapscript(which is basically witness space in taproot) being unlimited made it attractive as blob data storage.

we can limit the tapscript size, or we can detect inscriptions specifically and other similar methods and filter them specifically, because they are using the script space as data storage, which is unintended use. parasite.

knots does similar stuff.

i mean bitcoin as data blob storage is unintended in general