Aiden 🏴

@L0RINC @start9labs @pastorcoin @BTCJSON1 @sonMHGJC That said, resource usage is still higher than I'd like to see. Disk throughput (offloaded my RAM usage) is the biggest problem, but might be fundamental. Disk usage is the other big one though, would like to see more focus on viability of pruned nodes

@L0RINC @start9labs @pastorcoin @BTCJSON1 @sonMHGJC Not at all. Just reporting my diagnosis of why it hits a wall with slow disk and only 8G RAM

My full node sync just hit the spam wall. Now I gotta wait 5 days to sync. SMH. BIP 110 can't come fast enough.

@L0RINC @start9labs @pastorcoin @BTCJSON1 @sonMHGJC ...where dbcache doesn't. The raspi disk operations are slow as hell, especially on the 4, so once the sync starts bottlenecking on them, it slows to a crawl

@L0RINC @start9labs @pastorcoin @BTCJSON1 @sonMHGJC None of this refutes our diagnosis of the issue. When you are syncing from genesis in one shot, the entire utxo set gets loaded into memory until you run out of space for it. This is true regardless of the dbcache parameter, because linux kernel disk caching kicks in...

This strongly echoes my sentiments about the situation. I've historically been an AI skeptic, but I can no longer afford to be. With 4.5, it became worth using, with 4.6 it's now foolish not to

@cr1ssupr02 @start9labs What hardware are you running it on?

Minecraft server on startOS, quite laggy but doable

@BTCMcBoatface @start9labs StartOS will see it as an update for the same service, it won't duplicate the instance

@start9labs Thanks! Is Start9 smart enough to see this as a replacement for Core or does it act as a second instance of Bitcoin? (As in, does this also absorb the ‘same ID’ when side-loading?)

⚠ BITCOIN CORE v30.0, PLEASE READ ⚠ HOW TO INSTALL? 1. Stop Bitcoin. 3. Download "bitcoind.s9pk" from the bitcoin-core-startos Github release page. github.com/Start9Labs/bit… 4. In StartOS, navigate to System -> Sideload a Service 5. Upload bitcoind.s9pk WHY DOWNLOAD INSTEAD OF MARKETPLACE? Knots and Core share the same ID. This allows dependent services, such as lightning, to use either one. It also allows people to switch between them without needing to resync the blockchain. Due to a bug in StartOS 0.3.5.1, if either service goes up in version, it will show as an "update" for the other service. This sucks and has caused people to think StartOS is trying to trick them into switching. To minimize confusion and mistakes, we release new versions of Knots and Core in parallel and require explicit action for switching. Not ideal, but a decent stop gap until StartOS 0.4.0. Because there is no Knots v30.0, listing Core 30.0 on the marketplace would result in Knots users forever seeing Core v30.0 as a "update". As such, we are making Core v30.0 available as a download/sideload instead of listing it on the marketplace.

I'm here for @PortlandHODL's redemption arc. I've heard enough of his spaces to give him the benefit of the doubt, unlike most of the people egging him on in that infamous clip. I think PH's apology was genuine, so I forgave him a long time ago. Now that he's proposing a spam solution, I think it would be a disservice to ad hominem attack the BIP he proposed. I'm not technically proficient in Bitcoin internal stuff, so I'll let the mailing list determine his proposal's merits. From a glance, it is closely aligned with my personal belief that individual transaction size should be capped since we haven't found a legitimate monetary reason for uncapped tx size. Bitcoin should gradually lock down the base layer consensus rules now that Bitcoin has stable L2 protocols that developers can build L3 apps on top of. The internet has lasted a very long time with very few base layer protocols. The application layer is the wild west where innovation and use cases should be developed. In protocol development, you should always keep the scope of lower layer protocols pure and stable so that upper layers may flourish. Good luck with the BIP!

I think @cguida6 worked on it a bit too, when he got involved. We called it "Probabilistic Partial Pruning"

Back in the early days of Start9, @ProofOfKeags and I were trying to figure out a proposal to make randomized pruning work. We never actually figured out something quite so elegant, and moved on to other things, so really glad to see this

@_dr_bonez Good filters, and to send Core a message.

To all people running knots, why are you doing it? Because you think the filters/configurability are good? Or because Luke told you to?

If you only want to work on what you think is best, and you aren't willing to listen to what your users want, then have at it. Just don't call it a community project

Some people seem to think I'm anti-core. I actually very much want to see it succeed and I hate to see it losing so much market share. Sometimes that means giving users what they want

@CryptoCryingBo1 @GrassFedBitcoin I think that qualifies under "good filters"

@_dr_bonez @GrassFedBitcoin Option d): I don't want 100kB op_returns in my hard drive

@adam3us That's not the argument here. Users want more configurability than is currently available. I'm not suggesting core set the defaults to anything other than they think is best, but currently they are losing tons of users to knots due to lacking configurability. I think that's bad.

@_dr_bonez having sensible censorship resistant, decentralization steering defaults, is an unequivocal good. you can change the default. and they have a PR to undo the "future deletion" warning.

The most disappointing thing to me about the mailing list discussion is the sheer disrespect for user competency and autonomy. The overwhelming sentiment seems to be that users can't be trusted with setting their own policies because they'll fall in line with authorities...

We're bitcoiners, we won't do what you told us

If you answered "filters good", are you using the defaults that knots shipped with? Or are you customizing your configuration?

@ismyhc @SuperhwySurfer Ideally, updating filter definitions should require user action

@ismyhc @SuperhwySurfer This has similar issues to @SuperhwySurfer's suggestion. Either you have one process managing every filter, or you have the overhead of a separate process per filter. Also sandboxing is worse and could encourage filter programs that reach out to the internet

I am choosing not to engage with gmax because he doesn't appear to be approaching my proposal in good faith, but I'm happy to engage with anyone who wants to talk about the merits of the bip itself