177 sats \ 0 replies \ @supertestnet 2 May \ parent \ on: clArk: An implementation of the Ark second-layer payment protocol for Bitcoin. bitdevs
It calls itself "the Ark second-layer payment protocol"
That is different from calling itself "the payment layer," as if there is no other
There is no other second layer payment protocol called Ark so it is perfectly reasonable to use a definite article ("the") in order to distinguish this layer two from other second layer payments protocols called other things (e.g. lightning)
You sound upset, why? What is wrong with more second layers? Devs are just devving my friend, it's what we do
I'd have to hear his input on how easy he might think it would be to do that protocol with pen and paper
not easy
for hedgehog to work you have to create a preimage & hash in every transaction, as well as two bitcoin signatures. A guy in this video shows how to create a preimage & hash with pen and paper. It looks like it would take about 8 hours of full time work and you'd probably make a mistake somewhere, so you'd likely need a team of three people to check your work. It is my understanding that creating a signature manually is about twice as difficult as creating a hash manually, and you need two of those per transaction so it's about four times as much work to make the signatures. So you're looking at five days of 8 hours of work for a team of four people -- per transaction.
But why do this with pen and paper? In this hypothetical scenario, did the USA also confiscate and ban all graphing calculators? It only takes a graphing calculator about a second to calculate a hash or a signature, so you'd simply have to program it for that -- and I'm sure such programs would be released as shareware. (There's one for gameboy already, so start with that and modify it for a ti-86, which should be easy because they are both 8bit processors with Assembly support. Or literally use a gameboy.)
I have had no problems leaving it closed most of the time and only opening it up when I need to make a payment. But since I live on bitcoin and use it in several of my day to day purchases, I generally open it up multiple times per day. Electrum also has a watchtower option so you can find someone who's running one and ask them if you can plug their watchtower info into your electrum wallet.
Watchtowers do not have custody of your funds but they do have some presigned transactions they can broadcast to close your channels, and you're trusting them to do that if you don't think you can get online in time to punish your counterparty if they try to cheat. There are instructions for running a watchtower here, consider running one for your friends and having them run one for you. It is my understanding that if you don't use a watchtower, you are safe as long as you open up your lightning node at least once during every two week period.
Electrum is the best
- easy to install
- built in graphical interface
- mobile and desktop support
- recommends good routing nodes by default
- option to manually connect to any other node
- option to control via command line
- option to automate on servers via json rpc
- excellent documentation, just run
electrum help
I don't know why it gets so little attention. IMO it's far more normie friendly than something like LND, CLN, or Eclair, because it's designed to be used visually with its integrated, excellent gui. The others have UIs but you have to pick one, and they are made by other devs with varying degrees of confusingness mixed in. Electrum strikes the right balance IMO: normies can use a standardized interface that looks nice and matches what they'd expect from a desktop or mobile app, and power users can access advanced features from the menus, or, if that's not enough, there are the command line and RPC options.
Try bitpac.org -- it's super easy to set up a multisig there, all you need is a nostr profile from each party
I used joinmarket to coinjoin my coins, and the best part was, I never paid a cent
I just ran it in "market maker" mode and people paid me to coinjoin with them
I also wrote a little tool here that alerts you via Telegram whenever someone pays you to coinjoin with them, and tells you how much money you made
I doubt it still works but maybe I should check and make sure
This is clearly an attempt to scare people, but it's not working. You can't lump everything together. And if I compile my own wallet, do I have to do KYC on myself? Ahahahah
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)