pull down to refresh
296 sats \ 2 replies \ @shibe 20 Apr \ parent \ on: Miners be like "What Halving?" Ordinals_Inscriptions_Runes
Help, these people are paying me millions of dollars. I'm being spam attacked!!
withdrawals seem to be broken now? Just says "could not decode invoice" on stacker.news regardless of what invoice I put in
What was promised: The first decentralized StratumV2 mining pool
What was delivered: Luke-jr's homemade blocks with censorship
So in other words OCEAN promised to be a censorship-free pool that's trying to decentralize Bitcoin using stratum v2.
So all the people who believed in this instead got a classic stratum pool running Luke-jr's bitcoin fork that rejects ordinals. So much for censorship-resistant and decentralized
Hmm interesting, but couldn't you potentially produce a lot of such "proofs". And how would you effectively blacklist a certain utxo/proof? Would all the utxos involved in that proof be tainted?
You'd probably need more than 51% to attack Liquid.
Pegging in BTC to Liquid requires 102 confirmations. Even if an attacker had 51% of the hashrate it'd probably be insanely difficult to cause a 102 block reorg.
You'd probably need way more than that, but I'm not sure how much. Also Liquid could just increase the amount of confirmations required more and more if a potential 51% attack is underway
30 sats \ 1 reply \ @shibe 28 Aug 2023 \ parent \ on: Zeus is adding Simple Taproot Channels bitcoin
The cost for opening Taproot channels will likely be the exact same as regular channels, as both P2WSH and P2TR outputs are the same size, so what would matter more is the inputs you use to create the channel.
Closing should be much cheaper and more private as with MuSig2 (black magic that lets you make multisigs that look just like singlesigs) it should be as cheap as just a regular Taproot spend.
Not sure if the gossip specifications for Taproot have been updated but it should reduce the size of gossip messages as well (instead of providing 2 signatures to prove you own a channel you can provide 1)
As they say in FOSS, Free as in Freedom != Free as in free beer.
Being FOSS doesn't mean you can't charge to use it.
Also yeah, I don't think everybody can setup their own server and they probably shouldn't unless they understand how to secure it properly. I feel anxious even having a public ssh instance running even though you can only login to it with an ssh key + password
This is so bad that it's hard to think that this wasn't intentional:
TLDR; not only did libbitcoin explorer use an insecure Random Number Generator (one whose state can be predicted by sampling a few hundred outputs), but it was seeded with only 32 bits of entropy from system time.
For reference you need at least 128 bits of entropy for a "secure" wallet.
32 bits of entropy on the other hand is only around 4 billion different possible seed phrases. It'd take your average computer just about a day or two to go through all the possible phrases generated by this library.
I thought people who were rolling dice or flipping coins 256 times was overkill but now I'm not so sure if this is the state of some of the seed phrase generators out there
Interesting article, it seems to use the fact that BTC payments are often done using exact dollar amounts (for example $5.00 converted to its equivalent amount in sats) and uses that to calculate the price.
But I wonder whether this could start breaking down in the following ways:
-
First off, I think this is just a privacy risk and merchants should stop accepting exact USD amounts. It's common advice to not use round payment amounts in BTC (send 0.00010004 BTC instead of 0.0001 BTC) because that makes it easier to figure out which is the change address and which is the payment. I hadn't considered that this was also an issue if you're converting round payment amounts from another currency to BTC, but it should be avoided. Thus merchants should perhaps charge something like $5.001 or $4.999 instead of $5.
-
Second, wouldn't this start breaking down if BTC becomes a more common medium of exchange and goods are priced directly in BTC? You could argue by that point there'd be no reason to need a USD oracle at all (it'd be obsolete!) but it's something worth considering
The biggest reason I see for accepting this is that OP_RETURN outputs are unspendable and can be pruned.
Stampchains are a much nastier way of storing data since they use bare multisig outputs which as far as I know can't be pruned and thus also pollute the UTXO set. OP_RETURN would be the lesser evil of the two.
Proof of Work was initially proposed as an anti-spam mechanism for email. The idea is that to send an email you do a small amount of work, and the cost for this would be negligible for an average user, but for someone sending out tens of thousands of emails, it'd increase their costs. I would imagine this would be an easier solution than requiring users to setup a Lightning wallet, but I don't know what exactly the computational cost would be for sending a message. Ideally it wouldn't be too difficult for a mobile to compute without consuming battery
21 sats \ 0 replies \ @shibe 3 Aug 2023 \ parent \ on: [bitcoin-dev] BIP352: Silent Payments bitcoin
Imagine you want to pay someone privately. The most common way to do this would be for them to generate a new address and send it over some encrypted channel. But what if this isn't possible/available?
Or put another way, what if I share my address here, in a public setting (bc1p57qdmjghng5xjugna0pjdy7ee9umce9x4jmwl0wn97804et489rq2j3f6t). Is it possible for you to pay me without anyone being able to find out that you paid me? With Silent Payments, this is infact possible!
Silent Payments are a new form of stealth payments (there have been proposals before, but some of them were not as efficient because they required OP_RETURN outputs to share a shared secret), or required a full node to be running. This new proposal is much simpler, and can look indistinguishable from normal transactions, and relies on fairly simple math. I've actually tried simplifying the math in a previous comment: #191656, hopefully it makes sense
Didn't Coinbase also switch to Bitcoin Cash during the blocksize wars? I don't remember much of 2017 except that I had like $50 of Bitcoin on Coinbase that was converted into "Bitcoin Cash" which I then had to convert back via shapeshift.
Even if they didn't support Core they could have let me keep both BTC and BCH but they didn't if my memory serves me correctly
Nice website, only thing that bothers me is the numbers on the difficulty recalculation/halving are upside down when in the lower half of the circle. The numbers should be oriented to point towards the centre of the circle when in the lower half and away from the centre in the upper half so they're always readable without tilting your head. I'm not familliar with CSS so not sure of the best way to do this, but adding a transform: scale(-1, -1) when the number is in the lower half seems to orient the text properly.
Also, the website refreshes everytime I switch to another tab and switch back, which is a bit annoying. Infact after doing a bit more testing, it seems the website completely reloads if the window resizes as well.
I think splicing can reduce the amount of thought you have to give to your liquidity. But ultimately as Burak describes it, inbound liquidity feels like a bug of the Lightning Network, and splicing IMO is just a work-around that's more efficient than opening channels on the fly but not a perfect solution.
I do think splicing can improve the UX significantly however and it could happen without you knowing. I wouldn't be surprised if LSPs offer incentives for agreeing to resize your channel as well, like maybe offering low (or even negative) fees if you shrink your channel if they want to reallocate the liquidity elsewhere.
Ideally we'd have some sort of "perfect" L2 where managing liquidity something you ever think about but I don't know what that would be. Maybe Lightning with eltoo channel factories or Hierarchical channels, or Ark.