pull down to refresh
@optimism
242,835 sats stacked
stacking since: #879734longest cowboy streak: 55npub13wvyk...hhes6rk47y
21 sats \ 0 replies \ @optimism 55m \ on: At 20 years old, Reddit is defending its data and fighting AI with AI AI
I don't use it either, unless it's returned as best match in search.
Fighting AI with more AI sounds reasonable though: it means your defense can scale symmetrically to the attacks.
I chose "something else" because it's mostly tooling for me, not so much "assistant", more "assistance". Examples:
- Search relevance / ordering
- Text summarization
- Transposition (i.e. image/video to text, or since I did the research a bit this week, I also like it for audio transpose)
Oh I'm sorry! I didn't mean to baselessly accuse!
I didn't understand that these were pre-sold. This is because I am dumb, but let me explain why I didn't get it:
Here are the mentions of
pre in your explanation:- RFQ s
preads - capture a s
pread - To capture this s
pread - Ap
preciate you giving us a chance
And here are your mentions of
sold:- and "
soldout" status - 1,000 nodes have been "
soldout"
You see, unintelligent people like me are incapable of making the connection that this means they were pre-sold. Again, my sincere apologies.
However, since all the purchases are trackable on-chain, and these are pre-sold, that means all the coin is still on chain? That's cool. Could you please share some txs?
First, its true that 1,000 nodes have been "sold out" at $1,000 each to our community.
Alright, so you claim to run 1/16th of the entire LN network in terms of infra, and if you didn't skim off, 1/64th of the liquidity.
Can you show me some node ids that you sold? Or some funding txs? These must be public if they are to generate routing fees.
Those purchase data all trackable and verifable aon chain
Okay, I'd like some txids.
I was going to test the perps before I saw that. Without more detailed information and in-depth explanations why this is not a scam, this sits at -1 on the ethics curve.
"Invest" USDT 1000 for "gainz on mining LN" makes it too scammy to fuck with.
The thing that sprung out to me is that aside from all the taro shitcoins they seem to have perps BTC/USDT... but then, the "high yield LN mining" really sounds like a scam - also it's "sold out"
he has been reinstated
Now the daunting task of leeching every video for archiving prior to them getting removed again awaits.
My first flex reaction to this was that this is going to put great advantage to centralized AI-as-a-service, as many people will be querying it so it will have a much broader corpus of
experience or wisdom than what a sovereign AI would be exposed to, but then I remembered garbage in, garbage out.If there is a separate, digital, dimension of
experience, this can be exchanged. For example: if you have llama4[carter] and I have llama4[opti], then we can trade our disparate experience weights and meld them, like I would fork a llama4[opti(0.8)+carter(0.2)] which would - I hope for both our sakes - outperform chatgpt4[big_booty_cougar(1e9)] (didn't make that up, #1013688, lol)There are all kinds of crazy ideas downstream of that.
I'm not sure if I understand the hypotheticals fully - it doesn't all make sense from how coding, bugs and release management works from where I'm sitting, - but I'll try:
Now if a block with this tx gets mined, all the nodes running 26 will get stuck at the previous tip.
You mean a bug was introduced in 26 and fixed in 27 but no security patch was released for 26? I don't think that this ever happened on an actively maintained version of Bitcoin Core. This hypothetical would be the gravest of errors on whomever manages the release process but at the same time easily fixable: release the damn security patch.
Or if you mean that you didn't install the security update and/or refuse to install it, then this is 100% on you and you should really rethink if Bitcoin is for you, because you're a sovereign operator. Being your own bank isn't rocket science, but it's not something you can just fire and forget.
But what if this happened when 26 was the most recent version ...
If a consensus bug on a new version materializes then the new version should be pulled, read BIP-50 that I mentioned earlier, because that's a post-mortem of when this exact scenario happened.
... Which chain is BTC?
The above is iirc the one and only time this happened... per that precedent it would be 25.
Another example might be if the bug exists, but no transaction gets proposed that triggers it. During the timeframe where 26 is running buggy rules and 25 is running non-buggy consensus rules, what are the consensus rules?
If a consensus bug gets introduced (like with
0.14) and caught before it gets exploited, then it's an unmaterialized hard fork that gets patched- like was done in 0.14.1.When I say "bug". I don't mean someone screwing around with consensus code - even though that has happened and this has put everyone on high alert for issues like this, because it was found post-release only.
It's more like: if you want to validate the chain and have consensus with the network, you have to implement - among other quirky things - the vulnerable merkle tree implementation that Bitcoin Core has used since v0.1. You cannot implement a safe version of this, because you will not be able to sync up with the rest of the network.
- Where is this defined? In Bitcoin Core.
- Why? Because it is has been reference client since 2009.
- Is there any bad faith there? Not at all.
- Can it be fixed? Matt Corallo wanted to fix many of the quirky things in consensus up since 2019 1. But even that won't fix all the things, because there isn't a clean soft-forkable solution for everything.
Footnotes
-
See The Great Consensus Cleanup draft BIP for the original, which got recently proposed to be revived by Antoine Poinsot ↩
I guess I'm nervous of a Bitcoin culture that says "consensus is the most important thing"
If you mean the
consensus protocol (i.e. what constitutes a valid block) then it absolutely is the most important thing. Without it, there is no chain. That's just the technical constraint of Bitcoin.If you mean developer (pre-)consensus:
- If this is purely about
consensus protocolcode (=softforks), then that's probably not going to happen, but having rough consensus between stakeholders 1 is important when doing core protocol changes. Super-short lazy version: all issues must be addressed, but not all issues must necessarily be accommodated, and at the same time, rough consensus isn't a democracy: votes are meaningless, feedback is priceless. Also: 2 - If your point also includes what I mentioned above as
peripheral functionality. i.e. everything that influences your node and/or your peers, but not the overall consensus protocol (and preferably not the p2p messaging protocol itself) then of course there is no consensus needed other than between maintainers of the repo in question, though it would still be good to listen to and address concerns, especially if said repo serves a large part of the network.
-- not that I think you hold this position -- but "matching Core bug for bug" does venture down the path, I think.
Something has to be the truth. If two implementations do not agree on what is valid (
consensus, lol) then it has to be fixed or they will be permanently hardforked away from each other. This is only limited to consensus protocol and p2p messaging protocol, imho.Seeing how things are going with ETFs and treasury companies and custodians, it seems like a real possibility that development will continue to be funded by these large stakeholders and their priorities might not be censorship resistance.
What do you mean continue to be funded? Wasn't the complaint that Saylor isn't funding anything at all? Neither is Blackrock or Conbase, afaik?
Do you worry that keeping all work on consensus in one repository makes it more vulnerable to strong nudges from such stakeholders?
I don't think that this is true, but if it were, it would be worrying, yes. This is why I gave some pushback to Murch the other day re: banning people, and why making
bitcoin/bitcoin a private repo in all but visibility is imho the worst possible outcome, and yes, this is also worrying without bankers and scammers funding maintainers!Having multiple viable, well-maintained implementations, each with their own means of reaching consensus with the rest of the nodes following the BTC blockchain, seems like a stronger position to withstand such pressures.
That's what the 3 clients I mentioned above thought, and later with BCH where this was policy, Bitcoin ABC just hardforked off to create yet another shitcoin in which they then milked the entire market cap into developer salary. Collaboration is important. It can be decentralized, but imagine that every proposal in https://en.bitcoin.it/wiki/Covenants_support would have been a separate client that all needs to be updated while the years of non-activation pass. I count 6 implementations at least. That's 6x the maintenance work. For things that probably never even get lock-in, let alone 95% activation.
Footnotes
-
See as an example the mails in this thread because it shows you how some of the maintainers think about softforks, developer consensus and listening to the community. ↩
Technically wouldn't both choices be "plant"?
Exactly! But how do we create awareness for that?!? All this popular chatbot usage (best buddies, waifus, constructs of worship) is like using a chainsaw as a pillow and then proudly showing off how it cut a large chunk out of your cheek and now your teeth show through... it's a very bad use-case.
Or are we saying your brain works fine its just you can't control your speech?
I'd say no, technically a plant in both cases.
This is going downhill, isn't it?
Yes. This is not the way. Whatever you do, Sam's forward text prediction engine is not your buddy. It's his tool that you pay to use.
I was writing "garbage in, garbage out". But you beat me to it.
Thought experiment:
Neuralink gets real and you can now indicate what you want in case of total cognitive failure:
- be a plant
- be able to express everything every human ever expressed, with the caveat that you cannot control what comes out
What's it gonna be?
Fair questions! Assumed you knew, apologies.
I'm curious what evidence you have to support it?
Cases of past forks, because we've been here:
- BIP-50 which was bitcoin/bitcoin with itself, a perfect demonstration of how fragile consensus is, and why I think that "even the bugs of the ref client are leading".
- Bitcoin XT, Bitcoin Classic and Bitcoin Unlimited, each as an alt client that ran its own softforks (and later turned into BCH)
Why haven't we seen more forks from miners running old versions of Core?
This is exactly because of very well defined, agreed upon and executed soft fork implementations allowing for full forward compatibility for old clients. (Though arguably the introduction of OP_NOP itself was a hard fork.)
Don't underestimate the engineering that this has required, especially for segwit. It is because of developer consensus, and an open repository and mailing list, and not settling for inferior solutions, that Bitcoin is as reliable as it is.
But this is also why I said " if you're willing to support that chaos", because I'm just advising against it. Mostly due to historical precedent of what happens when polarisation is driven to the point of people building forking clients out of frustration. And because I think that if you're burned out, you shouldn't make decisions.