73 sats \ 2 replies \ @supertestnet OP 3h \ parent \ on: FBI warns all Americans to stop using KYC-free bitcoin services bitcoin
I think they would go after any node that relays your transactions and charge them with transmitting money sans KYC
Well, I don't think they would do that, but I wonder if they want node operators to worry about a dragnet operation -- "if I keep running this node they're coming after me!"
For a while I had the impression that you are only a money transmitting service if you accept currency from person A and give it to person B. But that seems to be changing. In their prosecution of Samourai, they indict Samourai as an unlicensed money transmitter for (among other things) running the Ricochet service, which is just an inbox where people send signed "raw" bitcoin transactions that Samourai broadcasts at random future times (they do this to disrupt timing analysis and to confuse chain analysis software). If merely "sending someone else's signed bitcoin transaction to the network" (!) counts as transmitting money, then every bitcoin node that relays blocks or mempool transactions also counts as a money transmitter. So if you've ever used a wallet that doesn't do KYC on you and does somehow manage to get your bitcoin transactions into bitcoin, it looks like the FBI is warning you to stop.
Chrome OS is quite capable and so far I think Google has done a great job making it normie friendly
Except for one thing: spying on users is not user friendly, it's user hostile, and Chrome OS loves to spy on its users
Chromebooks run a linux distro called Chrome OS
Other than Android, Chrome OS is the most popular linux operating system available in stores
- most contracts do not have an escrow component, that is, what you owe in the future is uncertain and even when it’s certain, the thing owed doens’t exist yet and may never exist. So there is now way to automate how to handle uncertain future conditions
I think it is possible to automate uncertain future events. I've tried to present one way to do this in my loan shark tool. When you use that tool, you create a contract to borrow money first and, if someone accepts and loans you money, you pay off your loan later. But you don't know, at creation time, what utxo you will use to pay it off. To handle this uncertainty, I make it so that you sign a transaction with sighash_anyone_can_pay. This allows you to add a new utxo to the transaction in the future without invalidating your counterparty's signature.As a result, you can contractually agree to give your counterparty a utxo that does not yet exist, and face a penalty if you do not. So there actually is a way to (partially) automate some future uncertain conditions.
2. most contracts involve real world assets, not digital ones, so can’t be fully automated
Agreed. You can create a physical contract (or a digital one, for that matter) that says something like "I agree that this house shall become Jerry's if X bitcoins end up in address Y before date Z." If that happens, you've got public proof on the blockchain, and if it doesn't happen you can prove that to. So you can bring that data to court if necessary, and that is a form of partial automation, but it's not full automation. Someone still has to go to court if there's a breach of contract (e.g. the seller refuses to leave the house).
- most contracts are very complicated and require verbal language (words) to express the terms (and can’t be done with simple symbolic logic; if anything contractual verbiage gets more nuanced and complicated over time, not simpler) and arbitrators/judges/courts to decide when there is a dispute
It seems to me that most "complex" contracts emerge from taking a simpler version and adding more text to it. Those simpler versions were, however, perfectly valid on their own, and many of them can be at least partially automated via bitcoin. His point seems to be that "most" contracts have evolved beyond simple versions, but I don't think that's a positive development. Return to simple contracts, and then automate them as much as possible (well...as much as is desirable anyway).In BitVM pegs, users do not have a unilateral withdrawal mechanism
In the unisob model of bitvm pegs, they do
For a while I used intermediary services that will accept my sats and pay my fiat bills.
That's what my imaginary merchant wants to do. He isn't trying to think about it in fiat terms at all. He doesn't look at his expenses and say "The materials will cost me $90," he looks at his expenses and says "The materials will cost me 120,000 sats." <-- which was true when he earned the bitcoin. But when he actually goes to make the purchase, the intermediary service shows him a different price: the shirts now cost 150,000 sats.
Which he doesn't have, he can't afford it, not due to any fault of his own, but because bitcoin fell in price. What should this imaginary merchant have done? Was he thinking too much in fiat terms, even though he never thought of fiat? How would you have acted differently, with the right mentality? His competitor Jimmy converted to stablecoins and can still afford to stay in business. What did the imaginary merchant do wrong? And is he wrong or a victim of slave mentality if he thinks, "Next time I'll convert to stablecoins too"?
That means they can easily keep those sats as savings without affecting their regular cash flow.
This is a point I'd like to discuss further. Imagine an online store selling homemade clothes. A poor person can start such a company and needs to accept payments somehow. I've built software for doing this with bitcoin.
Such businesses have expenses, namely: shipping costs, cost of purchasing materials, and perhaps the cost of splitting the proceeds with an employee or friend who is helping make the clothes. I imagine a poor person starting such a company with next to nothing. They have negligible savings, let's suppose zero savings. But they've made shirts before, and have pictures of them, so they can upload those to the internet, accept payment online for new orders, then order the materials, make the shirts, and take the shirts to the post office to ship them.
Now let's suppose they accept bitcoin but not stablecoins. They started their business a few days ago, when bitcoin was $75k. They got $100 in sales, enough to pay for $90 in expenses with $10 left which they hope to split with their friend to eat and sleep somewhere. Today they go to buy the materials and lo and behold, bitcoin dropped to $60k, so their $100 earnings are now only worth $80. They can't afford to buy the materials nor do they have anything left over to eat or pay rent. They are bankrupt and now instead of making money, they are in debt: they owe their customers some shirts but they cannot afford to make them.
Instead of this catastrophe, let's suppose they either accept stablecoins directly or convert their bitcoins to stablecoins. In this case, their $100 is still worth $100. True, next year it will only be worth $95, and there's a rugpull risk since Tether might steal it. But these risks, including the slow depreciation, seems like a small price to pay if it means the person is still in business and can actually begin to accrue savings.
What is wrong with this imagined scenario? Is anything in that description fantastic or unlikely? Is the merchant wrong to think stablecoins are a good way to increase his chances of success? Is he a slave if he decides the risk of rugs and inflation is worth it? Accepting stablecoins or converting his bitcoins to them may save him from going bankrupt if bitcoin rapidly falls in value. As a tradeoff, he has to trust Tether corp, and if he holds these stablecoins for a year they will be worth about 5% less. I sympathize with this imaginary merchant and I'm beginning to think it is wise to make "convert to stablecoins" an option for him in his store interface.
Darth, I seek your wisdom. Someone almost persuaded me that stablecoins are good because they save innocent companies and individuals from going bankrupt when bitcoin's volatility swings the wrong way. Why is this argument wrong? https://twitter.com/super_testnet/status/1780309170115272874
Apparently the law says you can't build a data center unless you tell a government committee what you plan to do there. Then they approve or deny your plan. I'm a little surprised this isn't already a thing. I didn't think you can start a business in the USA without a business license, which sounds similar to what Norway is doing.
I happen to be in Dallas Texas at the moment so I checked the local laws. Everyone who wants to start a business here has to visit the secretary of state to get a "certificate of formation" of their business, and there is a list of 300 business types that have to go through an additional approval process.
Data centers and server farms don't seem to be on that additional list, at least not from what I could see by skimming it, so in a sense I guess Norway's new law is just adding data centers to their equivalent list of "businesses that need extra scrutiny." That sucks. More red tape, and an opportunity to "just say no" to bitcoin.
If Alice and Bob are in state X, where Alice sent Bob some money, Alice can do a unilateral exit by initiating a channel closure in state X-1, i.e. the state before she made that payment. This triggers the 2016 block countdown, during which Bob must broadcast the latest state, unless he is okay with losing his most recent payment from Alice. So neither party is ever "stuck" -- they can exit whenever they want.
If you're specifically asking about the very first state, where there is no prior state for Alice to broadcast, she simply doesn't put her money in the multisig until Bob cosigns her exit transactions. I didn't show this is the video but it's part of my work-in-progress wallet implementation (the code is not released yet).
2312 sats \ 1 reply \ @supertestnet 14 Apr \ parent \ on: The testnet mempool is full. Ordinals_Inscriptions_Runes
The mempool will likely contain more transactions because runes will likely have an initial novelty/popularity
Blockspace will likely be scarcer due to the greater number of transactions trying to get into the blockchain (hopefully their initial popularity will wear off)
The utxo set is unlikely to increase significantly because runes are encoded as op_returns, which have no impact on the utxo set
To create a rune you must spend at least one utxo, but you need not create any. Most users will probably create a new one to replace their old one with change, so they will consume utxo A, create utxo B, and create an op_return, which is not a utxo -- so, overall, no material impact on the utxo set (hopefully)
I have some software called Hoard which lets a user or a third party of their choice cancel a transaction by sending it into something called a vault. It requires no soft forks and works today. https://github.com/supertestnet/hoard
I don't think anyone has implemented a way to do this without taking custody of user funds for the duration of the trade
When a definition contains a list such as this, the terms within the list must be within the same class.
Who says? Suppose I define the term "mammal" like so:
The term mammal means any animal with warm blood, vertebrae, milk glands (in females), in utero gestation (in females), and fur
If someone said "fur must mean something else because everything else in the list is in the class 'things inside the body'" <-- I would think that's a silly statement
In any list of things, you can always find some principle of distinction by which one of its items isn't in the same class as the others. Therefore not every item in a list has to be in all of the same classes as the others. If this was a requirement, definitions could never contain lists while remaining true.
I appreciate that you are one of the very few people who actually put together a bridge implementation
I have not yet implemented unisob, it's only a proposal. I've been working on hedgehog instead, which is unrelated to bitvm
In the article, we said "burned" for a couple reasons. First, it just helped simplify it for the reader.
I'm glad this is not the "only" reason. Robin's model, at least bitvm 1, does not seem to propose any scenario where user funds get burned. I haven't investigated bitvm 2 yet so I can't comment on that. Be wary of "simplifying" something by changing it into something totally different, which is what I think you've done here by mistake.
I'm not accusing you of what I'm about to say, and I suspect I have misread you, but right now it looks to me (probably unfairly) as if this happened: you read Robin's proposals (bitvm 1 and 2), found that it is possible that the final verifier ends up with all user funds in a 1-of-1, decided that is too dangerous, and therefore modified the proposal to create two variants: instead of sending all user funds to the final verifier in the event that all prior verifiers were dishonest, you can instead design a protocol that burns all user funds, or sends them to an anyone-can-spend address.
Then (again, I don't think this is reality, only a fantasy I've concocted due to misunderstanding you) you evaluated these variant proposals of your own making and discovered that they are dangerous. And you wrote a paper as if the least dangerous version (in your view, or rather the fantasy version of your view that I've invented due to lack of understanding) is the one where user funds get burned, and decided to warn everyone that this might happen.
I hope the above fantasy is not accurate and I do not think it is accurate. Please clarify where I went wrong. Because if it is accurate, I hope readers find it distressing that you did not examine Robin's proposal as it stands, but modified it to the point where all user funds might get burned, and then warned people that your modified proposal is dangerous, while continuing to call it Robin's proposal -- even though that doesn't happen in Robin's proposal.
I think the options for places the funds go if the final operator cannot pay out effectively reduce to three options
The reason this paragraph is wrong is because the "final operator" -- if all other operators failed -- always has complete control over every satoshi that was on the sidechain. It does not "reduce to three options." In Robin's proposal the final operator holds these satoshis in a 1 of 1. (At least under bitvm 1, I cannot assert anything safely about bitvm 2 without examining it.) Therefore, necessarily, he can pay the money out to every user. No one can stop him from doing so. Also, no one can stop him from running away with the money.
If all prior operators were dishonest, user funds end up with the final operator, and if he disperses them to users, the bitvm protocol is done -- the trust assumption was "at least one is honest," and it was him (or her), because he (or she) kept his (or her) promise to pay out to all withdrawers where no other operator did. If he (or she) does not do this payout, whatever he (or she) does after that is a violation of the bitvm protocol. He (or she) might keep the funds, send them to his (or her) friends, burn them, or send them to an anyone_can_spend address. These last two seem like particularly insensible options for the final operator to do.
we were frustrated with the narrative that BitVM bridges fix the issues we have wrt trusting bridges
Robin's model only claims to improve the trust assumptions from m-of-n to 1-of-N (where m is greater than 1). He has occasionally seemed to me as if he wants to claim it does more than that, but I think I sufficiently badgered him about it and, at least in my presence, he has maintained humility about what his protocols accomplish, and has been careful not to claim bitvm "fixes" the trust assumptions of liquid-like blockchains -- it only "reduces" those trust assumptions, not to 0, but to 1-of-N.
It's very easy for me to imagine a scenario where an L2 bridge decides a 10% collateralization is acceptable, grows large in terms of TVL, and all users funds get burnt/lost following a mass withdrawal. This is terrible for our space, and something I strongly prefer we avoid.
I agree except I think somewhere along the line you made a mistake and became convinced that burning user funds "counts" as part of Robin's bitvm proposal, when in fact it's not, he proposes (in version 1, not sure about v2) giving them to the last verifier and relying on that person to be honest if no one else was.
A bridge of your design is 100% safe, but it also doesn't scale economically
I don't think users would like my bridge design because (1) it has the same "inbound liquidity" requirements as lightning (2) additionally, it requires users to "roll over" their funds into new bitvm contracts on a regular basis (3) proving fraud, if necessary, would probably be expensive for many users.
I agree that these outstanding issues make my model economically unscalable. I prefer making something that is safe first and then work on making it scale second. I suspect there are ways to fix the above issues, but until then, my model can probably only work for a small number of people, and I think that's fine for now. At least it doesn't introduce new trust assumptions. Every user trusts themselves. I'm proud of that.
This criticism of Robin's bridge model seems to incorrectly state that verifiers can burn user funds in step 8. That is not my understanding of Robin's model, I believe that if the prover does not process a withdrawal, the verifiers can burn some funds that the prover himself put up as a kind of stake to dissuade dishonest behavior, but user funds do not get burned, they simply move to a new m-of-m multisig controlled by the remaining verifiers.
One of them becomes the new prover and must process the withdrawals now otherwise they lose their own stake and the cycle repeats until one of two things happens: either some verifier processed the withdrawals properly when it was their turn, or all user funds become the sole property of the last verifier, locked to a 1-of-1 where he or she is the only remaining keyholder.
At that point, this final verifier can simply send the users their money without hindrance. But if he or she is dishonest, users are out of luck, the last verifier can run off with all user funds if no previous verifier could or would perform the withdrawals honestly. (This is largely why you must always trust at least one verifier to be honest, in Robin's model.)
Also worth pointing point: my unisob bridge model is unaffected by this criticism. The prover sources the funds to perform a withdrawal when the user first deposits money to the bridge, and every depositor gets to withdraw up to the amount in their own individual contract with the prover. If the prover is unable to source sufficient funds, the would-be depositor simply aborts and never makes their deposit.
20 sats \ 0 replies \ @supertestnet OP 2 Apr \ parent \ on: Subscribe to youtube feeds on nostr nostr
dead. But you can deploy your own copy of the source code here: https://github.com/piraces/rsslay
Looks like there is also an alternative instance here: https://atomstr.data.haus/