Avatar
techfeudalist
98a386c766ac9250f4ce1b500662fd08e4d464a1915743eedc83bd50521decac
Blessed by tech; working to bring the benefits to everyone. Freedom, incorruptible money, privacy.

Here’s a super simple example:

To AI:

Imagine a function that takes two integers and adds them returns true if the sum is less than 100, else false, propose three tests

——-

AI might respond…

Sure, here are three test cases for such a function:

1. **Test Case 1: Two small numbers**

- Input: 5, 10

- Expected Output: True (because 5 + 10 = 15, which is less than 100)

2. **Test Case 2: Numbers summing up to exactly 100**

- Input: 60, 40

- Expected Output: False (because 60 + 40 = 100, which is not less than 100)

3. **Test Case 3: Large numbers exceeding 100**

- Input: 75, 50

- Expected Output: False (because 75 + 50 = 125, which is more than 100)

You'd want a range of test cases to ensure that the function behaves correctly for different kinds of inputs.

———

Now write the JS function and tests using Jest

—————

Certainly! Here's how you would write the first test for the function using Jest:

First, let's define the function (I'll name it `isSumLessThan100`):

```javascript

function isSumLessThan100(a, b) {

return a + b < 100;

}

```

Now, let's write a Jest test for it:

```javascript

const isSumLessThan100 = require('./path-to-your-function-file'); // Import the function

describe('isSumLessThan100', () => {

test('should return true for numbers summing to less than 100', () => {

const result = isSumLessThan100(5, 10);

expect(result).toBe(true);

});

});

```

More details on drivechains… nostr:note1k4x4nu3h4z38mp0d8ktm5rjkerz3sswl6gh343qu23jarxygvyuswhwgzq

From my personal experience, it’s waaay faster than coding it yourself. Likely 10x. It’s not just the coding, but the bug fixing. Using AIs to write the tests and then write the code generates far higher quality code really quickly.

And they negotiated for no liability. Learned their lesson.

Lying criminals — paid the largest criminal fine in 2009. But they’re telling the truth now, right? 🤔

Thank you. This was helpful.

Need to think about it more, but my initial impression is that the proposal is complicated and inelegant.

Seems to require a lot of trust in miners to do the right thing. Not clear that the proposal will work as intended and won’t have unintended consequences.

Replying to nobody

https://www.truthcoin.info/blog/drivechain/

Just read this. Written 8 years ago. Wow. Why not bring sidechains into L1 and let them run on it essentially. Deep stuff.

🤯

I must be missing something. I don’t understand why people are getting upset. I’ve heard this proposal referred to as an attack on bitcoin.

It seems to be a group of private actors using the blockchain to pass messages to each other.

I don’t see any change to network incentives, or risk of transactions being censored, increase in data storage, or any other harm to the base chain.

🤷‍♂️

Replying to Avatar Lyn Alden

For reference, here are my main thoughts on the current Bitcoin softfork ideas/dramas to those who care.

For context with regards to wherever it might matter, I have a 12-year background as an engineer initially and eventually an engineering manager, including overseeing electrical/mechanical/software for an aviation simulation facility, but although I have written code here and there in my early days, I am certainly *NOT* a software engineer. My career work is on electrical engineering and multi-discipline engineering management, and my master's degree is in engineering management, with an emphasis on systems engineering and engineering economics. Any viewpoint I have is from an engineering/systems management perspective or an economics perspective, not a programmer perspective.

I follow multiple software Bitcoin experts on various topics, many of which disagree with each other, similarly to how I followed my various lead engineers when I was working in engineering management.

The U.S. Constitution is well-written but of course not perfect. It's a good document, especially after the amendments it has had. The most recent amendment was over 30 years ago, and it is minor enough that most people don't know what it is. The second most recent one was over 50 years ago, and that one is also pretty minor, imo, and most people don't know that one either. The Constitution, the Bill of Rights, and a then a handful of key amendments after that to fix key issues with race and gender voting and so forth, have been the foundational aspects of this whole Constitutional project.

In order to change the U.S. Constitution, you need both a supermajority in Congress and a supermajority among States. Good luck getting that. And that near-immutability is exactly why the Constitution is valuable. Even if it was better written and included all sorts of things I liked, if it were easier to change, I would consider it to be a *worse* foundation than it is now. The near-immutability is the critical part. A nearly-immutable good document, is a great document, if it serves as the foundation of something important.

When it comes to Bitcoin, the aspect that I view as being the most valuable is its near-immutability. We have a global open-source ledger foundation that gives us savings and payment/settlement technology. It makes hard trade-offs in order to remain reasonably decentralized. And yet, Bitcoin can settle more transactions per year than Fedwire does, which is the U.S. base settlement layer, which handles (not a typo) 1 quadrillion dollars worth of gross settlement volumes per year. Bitcoin does that function but is global, open-source, and has its own scarce units. Various layers can expand that scalability, (Lightning, sidechains, fedimints, custodial environments, etc). Certain softforks to the base layer may also add some new scalability options (covenants, drivechains, zero-knowledge proofs, etc). But those softforks present risks to the whole project, unless they have a supermajority of support and are considered to be of low technical+incentive risk.

When I was an engineering manager for my aviation facility, if I were to approve a major new change and help fund it, it would be because the supermajority of my senior technical leads supported it, and because they could convince me of it. Objective truth tends to be easy to share between rational people that listen to each other. In contrast, subjective things that are more contested of course tend to be harder. If I liked a new change but it didn't have a supermajority, I respected these divergent opinions and wanted to know why they saw it differently. Unless it was in an area where I was *specifically* the facility expert in (in my case, the electrical/control aspects within our organization's aviation simulators), I would never go with a minority opinion among my technical leads and override the majority of my technical leads.

One of the most common problems I encountered in my career was over-engineering. Not a single person knows every detail about how an aviation simulator works (which was my field of work). There are software experts, graphical design experts, mechanical experts, electronics experts, pilot experts, and then business experts that have to figure out what is valuable to clients and how to get the required stuff and how to make the whole thing economical and thus well-incentivized. Systems engineering, practically by definition, is the science of managing a project that is more complex than any one human mind can possibly understand. Any major project engineer/manager has to deal with this dilemma.

As it pertains to over-engineering, many people often have pet projects that they care about, or want to make really cool complex things, that are not economical or not robust. Endless changes can create endless complexity, which are hard to maintain, are less reliable, and so forth. The most beautiful engineering designs are often the most simple at the foundation. Complexity can exist in layers or silos built on or around that foundation, which reduces contagion risk to the simple-but-robust foundation.

In short, if you you can't convince a supermajority, then maybe your idea isn't right or needs more work. Maybe the problem is on your end. Especially if the supermajority that you need to convince are intelligent relevant people (in Bitcoin's case: software developers, node-runners, miners, capital allocators, etc).

And of course, foundations like the U.S. Constitution or the Bitcoin base layer are far more important than the engineering frameworks of some random aviation simulation facility, so the standards are higher.

So, how do I assess proposed softforks as someone who hasn't written code in a decade but tries to follow the designs and economics of various proposals where possible? I look towards technical leads, and look for a supermajority of serious stakeholders, and need the proposal to clearly make sense to me technically and economically.

I view Bitcoin as being valuable due to its near-immutability. That is the source of its monetary premium. And so as follows, from a project management perspective regarding what is among the most serious of all possible projects:

-The first rule of Bitcoin is you do not break Bitcoin.

-The second rule of Bitcoin is you do not break Bitcoin.

-The third rule of Bitcoin is you do not break Bitcoin.

-The fourth rule of Bitcoin is that, around the margins, you try to find conservative ways to improve Bitcoin that are clear enough to get a supermajority.

Therefore, my view on softforks is that I defer to the supermajority of experts I trust, while also needing it to make sense to me personally. I'm agnostic towards many softforks, since I don't have the detailed software expertise to be relevant between similar proposals. As proposed softworks gain momentum, I check to see if they make sense to me, and then look for a supermajority.

Bitcoin is valuable due to its near-immutability. If it can be changed by minority factions, then the relevance of the project over the long arc of time is limited. To the extent that it's going to be any sort of important base layer, that near-immutability, much like the U.S. Constitution, is critical. To that extent, any proposed change to Bitcoin is not just a software thing; it's an economics thing as well.

Therefore, if proponents of a given softfork try to find a way to push itself on the network without a supermajority of technical experts and economic actors, then whether or not I like it, I will oppose it. That's a way to turn me from neutral to opposed. Because that near-immutability is what I would fight for. I only support highly agreed-upon changes. Whatever small piece that my node, my voice, and my money can do, I err towards the near-immutability.

Appreciate your thoughtfulness, Lyn.

I understand and agree with your perspective that the base chain should be extremely resistant to change.

What I’m still struggling with is that, unless I’m missing something, from the perspective of old node software, nothing appears to be changing.

Old nodes would see meaningless data inserted but it wouldn’t affect existing users. A group of private actors would be using the blockchain to pass messages to each other.

Again, I must be missing something, but I don’t see any change to network incentives, or risk of transactions being censored, increase in data storage, or any other harm to the base chain.

Thanks again. 🙏

I still don’t fully grok the attack. I can imagine you’re sick of the discussion (I saw you credited on the BIP website). Just hoping you’ll help me with more details.

I’ve read the BIP writeup. To me, it sounds like a side protocol like ordinals / inscriptions. Old node software versions would see it as meaningless data that only means something to the participating users.

Like I’m watching a baseball game and I see hand signs but don’t realize what they mean.

Is it really an attack though? Does it improperly change network incentives? Censor transactions? Some other harm to the base chain?

I get Lyn Alden’s point that we want the base chain to be resistant to change, but, unless I’m missing something, nothing appears to be changing from the perspective of old node software.

It’s like a private group of people coordinating to use the blockchain to pass messages to each other.

Again, appreciate any insight you can provide. 🙏

Could you please break that down a bit more for me?

I assume you’re referring to the “silent”, miner coordinated soft fork.

You refer to an attack. Is there a way that this can hurt the base chain? For example, if I ignore that this exists, could it hurt the incentives or my BTC in some way?

Please help me understand the BIP 300 risks better. All I’m hearing at the moment is that people don’t want sidechains to use BTC as a native currency.

Pros:

+ gives miners more revenue

+ allows people to experiment with other functionality using their bitcoin

Cons:

… unclear

How does this negatively impact the base chain?

I agree with that, but from what I’ve read, that wouldn’t happen. What happens in the drive chains stays in the drivechains?

This was the problem with inscriptions. That they could add data to the base chain. My understanding is that this isn’t a problem with drivechains. If you have a link to how that’s not true, I would love to read it.