Avatar
Big Barry Bitcoin
0d97beae567fcec9c6574f1c6ef6126ea969d4992c3198e51c0fac52c5274a14
Big Barry Bitcoin - Bitcoiner, pleb, developer, enthusiast, 👎💩coins Check out my nostr blog! https://big-barry-bitcoin.npub.pro/

Honestly, I think it is still fungible.

If I came into your store with a face mask and the bank across the street is raising its alarm and I pull out some cash to buy a bunch of stuff from a duffel bag, you might wonder if you want that cash, but really, how much are you thinking: hmm, that $100 bill is really worth $10 because of its history.

Now let's say I come in normal clothes, a week after a robbery, and my money looks new, but nothing else is fishy... Do you reject the money? You'd probably only do that if you strongly suspected me... And even then, do you have prejudice against the money or against me?

So now bitcoin. Here's the deal. I create a bitcoin address, you send bitcoin, how often am I going to look at its history to see if it was from a coin join or on some blacklist?

Exchanges do it for sure, but if some people look at it and treat it differently to others, then why would we only look at one type of buyer (exchange/institutions) and base our definition based on their behaviour vs on the money itself?

Them monkeys also live in a world backed by theft. What is their inflationary currency and how do we fix that using Bitcoin?

😇

Replying to Avatar ODELL

Is this legitimately real or did you splice together the posts?

It reads like a private telegram group of degens.

Replying to Avatar Nathan Day

Yup, saw a big green candle and just rolled my eyes 😅

Replying to Avatar Final

In April 2024, Pixels shipped a partial implementation of our January 2024 proposal for firmware-based reset attack protection. Fastboot mode now zeroes RAM before enabling USB. This successfully wiped out the After First Unlock state exploit capabilities of two commercial exploit tools for the stock OS.

Several other improvements were made based on our January 2024 vulnerability reports and proposals including an implementation of wiping data before rebooting when a wipe is triggered. We shipped an improved version of this for our duress PIN/password feature before the feature shipped for Android.

We made massive improvements in #GrapheneOS to defend against these attacks since January 2024.

For ARMv9 devices, we greatly improved our hardware memory tagging implementation in hardened_malloc, deployed it for the Linux kernel allocators and greatly expanded the use of PAC and BTI across the OS.

We replaced our decade old feature for blocking new USB peripherals while locked with a greatly expanded and far more secure feature. The new approach blocks USB-C connections and USB-C data at a hardware level with expanded software-based blocking as a fallback.

We started deploying RANDSTRUCT for the kernel, which will eventually be used to have multiple possible struct memory layouts for each device model chosen randomly at boot. Our work on reducing kernel attack surface also continued. We plan to focus more on Linux kernel security going forward.

Our locked device auto-reboot feature from 2021 was replaced with a more secure approach preventing bypasses via crashes. It also avoids chain reboots without introducing a security weakness which makes low timer values such as the minimum 10 minutes far more usable.

We shipped our 2-factor fingerprint unlock feature planned since 2015. It allows people to avoid reliance on secure element security with a strong passphrase while keeping convenience. Fingerprint + scrambled PIN also defends well against being recorded while unlocking.

Several more major improvements specifically against the physical data extraction attack vector are planned. Our next release adds an implementation of zeroing RAM at boot in the kernel to match what fastboot mode does. We also plan to add a toggle for essentially toggling off Device Encrypted data.

Where can I read more about each of those features and what their limitations and tradeoffs are? ❤️‍🔥❤️‍🔥❤️‍🔥

Well all disagreements are two party events, but if one person makes the first move, then the other disagrees I guess.

Each time money flows from one side of the channel to the other, there is a possibility of a disagreement. That said, until both parties agree and have signed transactions backing that agreement, nothing has officially happened.

So let's say, you want to update the channel, 500 sats from me to you. I get your request, I disagree. My node is handling everything in an automated fashion and really it disagreed because something about your request was not following the expected rules of engagement.

Instead of "negotiating", it just decides to break the connection ASAP and broadcasts the latest transaction it knows that your node also agreed with. Since the nodes never agreed on this new balance change, what is broadcast to the network IS the last agreed balance.

Also, if this dispute was part of a chain for someone to else's payment, that person's payment aborts and their wallet tries again finding a different route.

I mean, this implies "only when there is a disagreement", implying that when someone force closes a channel which naturally will have the amount that each of you agreed you were entitled to.

If you do a consentual close, then you technically get to pay less in fees, so you get back more than you would otherwise, and TECHNICALLY, you can agree to split it 10 ways just to confuse Blockchain observers, you and the partner are just making a standard multisig withdrawal.

Also, you can easily identify a forced channel close, but a mutual close will hide the fact that your channel was ever a lightning channel.

Until you close a lightning channel, the balance between you and your channel partner is private information.

When you close the channel, the funds need to be split between two addresses. So at that point it is known on the public Blockchain what the split was... 50/50, 20/80, 90/10 etc.