Avatar
Super Testnet
2183e94758481d0f124fbd93c56ccaa45e7e545ceeb8d52848f98253f497b975
Open source dev w/ bitcoin focus | supertestnet.org bc1qefhunyf8rsq77f38k07hn2e5njp0acxhlheksn

It's a virtual computer that can run programs created as boolean logic circuits

What's cool about it is, these programs can be embedded into bitcoin addresses, so that anyone who sends money to a bitvm address can only spend it if they correctly run the program embedded into the address

And the program can theoretically be anything -- it could be Photoshop, or Doom, or a copy of the ethereum virtual machine, or anything. If a computer can run it, you can in theory convert it to work in bitvm, and then basically pay someone to run that program, or get them to put up some money as a pledge that they *will* run the program correctly, then take their money if they don't

Yes it works for me but it takes like 5 minutes

It's a very big program and I can't believe my VM implementation can even handle it

(I don't think it would be able to handle a proper dispute)

There are still some gaps to fill. Robin wants to use this to create a federation which cannot steal your money as long as one of them is honest. Here is a design I think is close to working: the federation members would all act as verifiers who agree to challenge a prover (who holds all sidechain deposits) if he doesn't process withdrawal requests correctly.

As long as one of them does so honestly, that honest party could take the prover's money and distribute it to withdrawer's honestly if the prover does not do so.

If this design worked it would improve the trust assumptions of federated sidechains, which currently rely on an honest majority, so that instead they only rely on a single honest party -- which could be you. You could just be one of the verifiers, and then you only need to trust yourself (and bitcoin's standard trust assumptions, e.g. 51% of miners are not censoring your transactions)

Unclear. Need a workable design first πŸ˜…

Replying to Avatar Super Testnet

I don't mean to alarm anyone but someone just wrote a sha256 function for bitvm:

https://techmix.github.io/tapleaf-circuits/

I think this means we can validate merkle proofs now...which means we can also do 2WP sidechains now

😱😱😱😱

this increases the size of the largest program written for bitvm from ~300 logic gates to ~165,000 logic gates

btw I am still hoping someone will implement a gameboy for bitvm

a gameboy's processor only has ~3000 logic gates

and doom runs on gameboy

I don't mean to alarm anyone but someone just wrote a sha256 function for bitvm:

https://techmix.github.io/tapleaf-circuits/

I think this means we can validate merkle proofs now...which means we can also do 2WP sidechains now

😱😱😱😱

Replying to Avatar OpenSecret

We have recently disabled the ability to zap nostr:npub1xnf02f60r9v0e5kty33a404dm79zr7z2eepyrk5gsq3m7pwvsz2sazlpr5 wallet users from Mutiny. You may still pay their invoices or LN addresses normally but a big problem we were seeing was force closed channels due to stuck payments to Zeus due to their work arounds with locked payments. Which harm both the user experience and other lightning nodes on the network.

Since nostr users are mostly unaware if they're zapping Zeus users or not, we are taking this step proactively to protect users from having a 10 sat zap costing them serious on chain channel closing (and reopening) fees.

The approach we are working on for solving lightning addresses on mobile wallets is a fedimint hybrid approach where the sats end up at a federation if you are offline but get swept to your self custodial channel when you come online. Payments will settle instantly with the federation and it won't lock up unnecessary HTLCs on the network.

Ideally we get the ability to do offline receives normally on LN but that future is looking really grim with LND's continued priorities on shitcoins instead of features, and offline receives depends on a network wide upgrade.

We petition Zeus to move to a more responsible node implementation like LDK unless their plan is to add shitcoins or break LN further.

As the guy who made the spec that Zeus Pay is using to enable async payments, I support Mutiny's decision. I think disabling payments to destinations that are known to use hodl invoices is the right move for mobile nodes until some method for mobile nodes to safely pay them is discovered.

Right now a mobile node cannot safely pay a hodl invoice without risking an expensive force closure. But this also exposes a griefing vulnerability that mobile nodes are susceptible to. Nodes simply cannot tell the difference between a hodl invoice and a normal invoice. But if they do pay a hodl invoice, and then go offline for more than a day, they are likely to get force closed, which costs them money.

Since these "dangerous payments" are indistinguishable from safe ones, it is easy to grief someone if you suspect they are running a mobile node and are`on a regular zapper: get them to zap you, hodl their payment for about 10 hours or so, and then settle it. There's a good chance you'll put them in a force closure state at no cost to you. Which means *all* mobile nodes are dangerous to use for zapping right now. You can easily get burned.

I am grateful that Zeus exposed this problem and I look forward to thinking of more/better mitigations than trying to block all hodl invoices whack-a-mole style. That might work fine in a non-hostile environment, but I suspect we're heading into dangerous waters on lightning. Here there be trolls. Watch yourself.

nostr:nevent1qqsthlsymdheuj8tdcxwzxdz5y5y7aqhdedw7jzkw7rh6m3s5x05mtsppemhxue69uhkummn9ekx7mp0qyghwumn8ghj7mn0wd68ytnhd9hx2tcpr9mhxue69uhhyetvv9ujuumwdae8gtnnda3kjctv9uq32amnwvaz7tmjv4kxz7fwv3sk6atn9e5k7tcprpmhxue69uhkummnw3ezuendwsh8w6t69e3xj730qywhwumn8ghj7mn0wd68ytndw46xjmnewaskcmr9wshxxmmd9uq3samnwvaz7tmjv4kxz7fwvd6hyun9de6zuenedyhszymhwden5te0danxvcmgv95kutnsw43z7qgkwaehxw309ajkgetw9ehx7um5wghxcctwvshsz8nhwden5te0dehhxarj94c82c3wwajkcmr0wfjx2u3wdejhgtcwne7ch

> bitcoin is digital real estate

So...fake estate?

I've never developed anything for them

I think cashu is theoretically cooler than liquid... Well, no, that's a lie, but it could be if only if it gets federated

Sure but if they just rely on the central bank to print cash to buy that debt it will make their inflation even worse. They seem to be far along the path to Weimar if they do that. Much farther than the US is even.

Japan might *want* to continue selling bonds at low rates but who will buy them? You can get an American bond that pays out a lot higher rate in a money that's not tanking as hard. I don't think it's a very sustainable path for them.

Why the US Dollar is Surging Against the Japanese Yen

Japan raises money by taking out loans. It does this in the form of bonds: you give us 90 yen now, we give you 100 yen later.

Japan's bonds have a low interest rate. This frustrates Japanese bond holders. They want the 5% rates America is paying. So they are selling their bonds. And when you sell a bond, you get the currency of the country that issued it: yen. Now those people, who were bond holders, are now yen holders. But they don't want yen, they want American bonds. So they exchange the yen i.e. sell it for USA bonds.

And when you sell something, its price falls. Bitcoiners know how that works: when there's lots of sell pressure, bitcoin's price falls. Same with the yen.

So the yen's price is collapsing relative to the US dollar as people keep selling it.

Super Testnet talked to a BSV dev on a BSV podcast... And they got along???

(Spoiler alert: Super thinks BSV is garbage money but it has some cool scripts, so they geek out about those and how bitvm lets him do similar things on bitcoin)

https://www.youtube.com/watch?v=oZR-r01YaUU

With regard to ecash, it's certainly a cool product, but I think it's a pale imitation of an asynchronous payment. Let's say Alice wants to send money to Bob. If Alice uses Carol's service to create an ecash token for Bob, it might seem asynchronous because Alice may go offline. But Alice isn't really the sender anymore. She gave her money to Carol and got her to promise *she* will send it to Bob. (Or rather, whoever comes first to claim it with something that is essentially a promissory note.) When that happens, the real sender is not Alice, it's Carol, and in order for it work Carol (the sender) must be online when Bob wants the money.

I don't have anything against that, I think it's cool. But I don't think it's *as* cool as a true asynchronous payment. With zaplocker, Carol never has your money. Carol is essentially a routing node between Alice and Bob, and routing nodes don't have custody of funds that use them as part of a path. I think that's cooler than a custodial model like ecash. Instead of depositing *money* with Carol, Alice routes a payment *through* Carol in such a way that Carol can only cancel it or forward it, not keep it. But after that it's largely the same: Alice may go offline, and Bob may come collect his money at his leisure. With ecash, Bob doesn't have a time limit, which is cool, but I think that's an acceptable tradeoff since the gain is self custody.