pull down to refresh
102 sats \ 0 replies \ @Filiprogrammer 8 Nov \ parent \ on: New BIP-444: Reduce Data Temporary Soft Fork Proposal bitcoin
A mempool filter can be sidestepped by going directly to a miner, unlike consensus.
They don't monitor the entire network, they only count the peers that are currently connected to their nodes.
Notes: Data updated every 2 hours. Data based on actual reported peers to our Bitcoin nodes.
I did it with this Python library: https://github.com/lnbits/lnurl
import lnurl
lnurl.decode('lnurl1dp68g...')
There is also https://knotsgoup.vercel.app/ which uses the Bitnodes API.
More likely one of those:
the sender doesn't have anymore enough funds for that redeem
the LNURL was already redeemed
How stable is Fulcrum really? I read people complaining about database corruption.
edit: Just answered my own question by looking at the Fulcrum 2.0 release notes:
Fulcrum 2.x series will no longer suffer from this problem and the process can be killed at any time (including abrupt powerloss), without any database corruption. At worst the last few blocks worth of data is rolled-back and Fulcrum will re-synch from the rollback point.
Generally agreed, but look at the progress of quantum computers:
In 2001 the number 15 was factored with Shor's algorithm on a quantum computer.
In 2012 Shor's algorithm was applied on a quantum computer to factor 21.
And now it is the year 2025 and we are still on 21.
In practical cryptography we use numbers that are about quattuorvigintillion times larger.
Exactly. This would only impact spammers (NFTs, BRC-20 tokens...). It would not stop Runes (Shitcoins encoded in small OP_RETURNs) btw.
Sphincs+Size optimized, security level 1: 7.8kb (schnorr 64 bytes)Since standardization, some optimizations have happened:Sphincs+C (extra 700-1000 hashes to grind during signing, but verification is better): 6.3kb signature sizes
Shows you how huge Quantum resistant signatures are. For the same security level, signatures would have to be around 100x larger than today with ECDSA. This would be a big waste of precious block space.
Also quantum computers are far from being practical anyway. They can just about break 21 into its prime factors: 21=3*7. Easily solvable in my head.
If a transaction doesn’t use OP_RETURN or any nonstandard script types, it should still be considered valid under both the old and new consensus rules. That means such “normal” transactions could exist in both mempools (of nodes that follow BIP444 and those that don’t) and wouldn’t cause reorg-related issues even in a mixed network. Am I thinking about this correctly in that standard transactions are effectively immune to any BIP444-induced reorgs because they sit in the intersection of both rule sets with high enough fees?
Yes, regular monetary transactions are unaffected by BIP444.
The soft fork would only limit the ways to put big chunks of data into transactions. (OP_RETURN, Inscriptions...)
so it moves into the "temporary soft fork" territory, that while possible and legit in itself is clearly suboptimal in terms of communication and education: many users don't understand it
A temporary soft fork is not new. It has already happened in 2013:
https://en.bitcoin.it/wiki/BIP_0050#Immediately
Done: Release a version 0.8.1, forked directly from 0.8.0, that, for the next two months has the following new rules:
- Reject blocks that would probably cause more than 10,000 locks to be taken.
- Limit the maximum block-size created to 500,000 bytes
- Release a patch for older versions that implements the same rules, but also increases the maximum number of locks to 537,000
- Create a web page on bitcoin.org that will urge users to upgrade to 0.8.1, but will tell them how to set DB_CONFIG to 537,000 locks if they absolutely cannot.
- Over the next 2 months, send a series of alerts to users of older versions, pointing to the web page.
what do you guys think, does it give you any cause for concern?
No, because quantum computing is not practical. As far as I am aware the largest number a quantum computer has ever factored using Shor's algorithm was 21.
Is the project more or less dead, and totally overshadowed by Lightning?
It was never really alive in the first place.
In particular, I would be curious to know what are its relative merits/demerits against lightning, in terms of transaction convenience, fungibility of Sats, anonymity, privacy and trust model?
| Liquid | Lightning |
|---|---|
| You have to trust the federation members to not rug you. | Trustless |
| Fees scale with transaction size in bytes (better for larger payments) | Fees scale with payment amount (great for tiny payments) |
| Payment amounts are private but addresses still traceable | No public ledger, receiver does not know who the sender is |
Some on-chain software wallets matching these requirements:
- Sparrow wallet
- Electrum
- Blockstream Green (technically contains JavaScript but does not use Node.js/npm)
Only a little ETH it seems:
https://etherscan.io/address/0xfc4a4858bafef54d1b1d7697bfb5c52f4c166976