My stance on this (as a home miner) is that the drama is not about the miners making a lot of money, it's about the blockchain becoming less usable; if we extrapolate to a worst-case scenario, where a potential majority of users might stop using it and selling their BTC due to lowered usability, everyone else (i.e. the people who love inscribing data on the blockchain) suffers, too.
Wouldn't be a potential solution to this drama the implementation of the block space restriction for transactions which use coding to bypass the 'datacarriersize' limit? Such restriction would require a fork (either soft or hard fork), where it's unlikely to happen. AFAIK, in the early days, miners prioritized the "aged" transactions. Why not continue favoring those transactions that do not circumvent the default 'datacarriersize' cap?
Actually in past miners were prioritizing some transaction with "Aged" UTXO. Anyway, miners merely followed default Bitcoin-Qt (now it's called Bitcoin Core) behavior. But after some time, mining become more serious stuff where miner prioritize profit. |
|
|
|
Since there's no mention of further P2TR/Taproot support on the release notes, it looks like problem of lack of contributor/developer still exist. I just download Electrum 4.5.0 and generate new wallet, but it create Native SegWit address. * Plugins:
- new: swapserver plugin (#8489)
Does anyone understand what this plugin does? I briefly checked relevant pull link at 8489, but i only can figure out it's related with LN. |
|
|
|
That project use different GitHub account, so no wonder i didn't know about it. While the UI application seems to be user-friendly, the installation process[1] would filter many Bitcoiner. [1] https://jamdocs.org/software/installation/ |
|
|
|
If not, then is there any reliable non-KYC Virtual Credit Card service that accepts Crypto?
With very strict terms set by VISA and MasterCard, non-KYC virtual credit/debit card almost non-existent. Excluding prepaid card, most of those usually become scam or eventually require their customer to perform some form of identity verification. It's also worth Amazon may reject those card. |
|
|
|
--snip--
Wow, SatoshiVM is doing some cool stuff!! 🤯 using Bitcoin for Layer2 and connecting with Ethereum? that's kind of mind-blowing! Actually SatoshiVM is the one which act as layer 2, not Bitcoin. But we digress, let's talk about technical features of SatoshiVM, the pros/cons, and why/why won't it work.
The technical details is limited, so i can't talk about it with certainty. So i'll just point few things, 1. Average block time for testnet 3s[1], it'll create some stale/orphan block. It worry me, even when they state they currently consider block time between 3s to 60s[2]. 2. Currently there's no detail how "sequencer" (party who create block) is chosen[2]. 3. While we can "move" BTC to SatoshiVM by ourselves[3], i didn't find how to "move" BTC from SatoshiVM to mainnet which is a bit concerning. [1] https://testnet.svmscan.io/[2] https://docs.satoshivm.io/satoshivm/rollup-protocol[3] https://docs.satoshivm.io/user-guide/btc-bridge-testnet |
|
|
|
@ABCbits
It sure depends on Bitcoin price and sats/vbite. But I wonder if this issue, like many Bitcoin related issues will figure itself out over the years. As Bitcoin miners are forced to find incredibly efficient energy sources, driving prices down so low and with it the necessary sats/vbite needed to be profitable. Making Bitcoin almost unnaturally (or some would say naturally) cheap compared to other final settlement solutions without having to compromise on the hashrate/security of the network.
IMO with bigger block size and higher minimum fee rate to be relayed by node (currently it's 1 sat/vB), I've only dabbled with the lightning network as a second layer and I was doubting robustness of it mainly due to things I read about 'The replacement cycling attack' for instance.
As stated by @mocacinno, many software already fix that weakness. In addition, that attack isn't practical one since you need to manipulate victim's mempool. Full node software and some light/SPV wallet already connect to several nodes to prevent various attack. Furthermore I've watched Stephan Livera's podcast with Ken Sedwig about using HSMs to reduce lightning hot wallet risk.
HSM as in Hardware Security module? Many modern CPU already include it on their chip. For example, Intel Software Guard Extension and ARM TrustZone. Although it's hard to know whether certain wallet software use it or not. |
|
|
|
So let’s say in 2032, when 99% of all Bitcoin are mined and Bitcoin miners will rely mainly on transactions fees, what will be the lowest amount of Bitcoin you will want to hold on chain. I think it will be higher then 3m sats (0,03BTC).
It depends on Bitcoin price. Are second layers robust enough now? Which one and why?
Technology-wise, LN and few sidechain (RSK and Liquid) are robust enough. But each has limitation or concern such as, 1. LN useful if you frequently make transaction. LN also limited by how many people use it which affect transaction routing. 2. Both RSK and Liquid are federated, not decentralized. Although RSK is somewhat better due to it's merged-mining feature. And don’t we need hardware wallet like setups for second layers like we do on the base chain? Especially considering in some countries 3m sats might be a year’s worth of salary right now, which you don’t want to hold all in just an app on your phone.
I don't think you can use LN on hardware wallet since you LN channel state may be updated even when you're not using your hardware wallet. Although few hardware wallet already support Bitcoin on sidechain. |
|
|
|
What exactly is needed to run such a service? honestly if both wallets are completely open source, then there is no need to point fingers and have such dramas, one could simply fork the wallet and start a new service, a better one.
At bare minimum, a server and ability to follow guide about setting either coinjoin software. But gaining people's trust and liquidity to perform CoinJoin isn't simple. In any of these 2 cases though, you'll still be running a centralized service. As a coordinator, authorities will be able to pressure you into shutting down, implementing privacy-breaking changes and helping them deanonymizing users through blockchain analysis. Maybe they'll force you to partner with a blockchain analysis firm, even. Does some of this sound familiar? That's true, although authority would have harder time pressure anonymous person/group. One solution would be to switch to decentralized approaches, such as JoinMarket. That's valid solution, although it remain less popular since it require you to run full node[1] is AFAIK there's still no user-friendly interface which can rival Wasabi or Samourai wallet. [1] https://github.com/JoinMarket-Org/joinmarket-clientserver/blob/master/docs/JOINMARKET-QT-GUIDE.md |
|
|
|
Now on topic, I wonder if samurai and watnotsabi use the same technology?
They use different technology. Samourai uses Whirlpool/ZeroLink[1] while Wasabi use WabiSabi[2]. What exactly is needed to run such a service? honestly if both wallets are completely open source, then there is no need to point fingers and have such dramas, one could simply fork the wallet and start a new service, a better one.
At bare minimum, a server and ability to follow guide about setting either coinjoin software. But gaining people's trust and liquidity to perform CoinJoin isn't simple. [1] https://docs.samourai.io/en/wallet/features/whirlpool[2] https://github.com/zkSNACKs/WabiSabi |
|
|
|
So, I was curious to know what methods were used by Satoshi, Hal Finney and the first participants? Can anyone share links about?
Nobody knows because we weren't with them when they created their keys. We can only guess that they used the only existing client (v0.1) to generate it. Although there were lots of tools to generate a 256 bit random elliptic curve key back then too. In addition, they can generate 256-bit of data manually using certain RNG source. Today I read some reports from users with problems related to Electrum on Tails.
I didn't find anything on either Electrum's GitHub[1] or Tails's GitLab[2]. I fail to see correlation between your post and OP's question. That feature contact that IP address and expect Bitcoin address as response, before the software can create Bitcoin transaction. [1] https://github.com/spesmilo/electrum/issues[2] https://gitlab.tails.boum.org/tails/tails/-/issues/ |
|
|
|
1. I see. It looks there's major trade-off between preserving backward compatibility (not many things could be added) or breaking backward compatibility (less adaption/usage). I don't think so. OP's proposal as it stands is 100% backwards compatible. If I generate a new 15 word seed phrase with the 32 bit versioning system, old software will still see the entire seed phrase as a valid BIP39 seed phrase and will recover the exact same wallets (provided of course I know my script type/derivation path, since old wallets won't be able to interpret the 32 extra bits). Any legacy seed phrases will still be recoverable by new software, provided there is a simple check box to indicate it is a legacy seed phrase so the software does not try to interpret the first 32 bits of entropy as versioning data. Yes, i'm aware OP's proposal is backward compatible. What i actually wanted to say are, 1. With backward compatibility, that means there's not much room for more improvement/change. In this case, some people may think "Why bother accepting/using this proposal?". 2. By breaking backward compatibility, it could hamper adaption or usage. Perhaps you could even stipulate that the new seed phrases must be either 15, 21, or 27 words long, and so any seed phrase which is 12, 18, or 24 words is immediately known to be a legacy seed phrase.
As reminder, BIP 39 allows entropy from 128 - 256 bits with multiple of 32 bits. It means you can generate 12, 15, 18, 21 or 24 words of BIP 39 mnemonic. |
|
|
|
Few thoughts, 1. Long time ago i read Bitcoin Core doesn't implement BIP39 due to security issue[1], which isn't solved by your proposal. 2. If i understood your proposal correctly, does that mean 12 word mnemonic have less than 128-bit entropy due to version field addition? [1] https://bitcoin.stackexchange.com/a/88244[1] If the security issue you are referring to involves the use of PBKDF2, this could be addressed by implementing versioning, although it would break compatibility with non-versioned BIP39 software. [2] Correct, a 128-bit entropy results in a 15-word mnemonic when considering the 24-bit general-purpose field is used. For a 12-word mnemonic phrase under the versioned BIP39, you can attain a maximum of 120 bits of entropy, whereas the non-versioned BIP39 allows for 128 bits of entropy with a 12-word mnemonic. 1. I see. It looks there's major trade-off between preserving backward compatibility (not many things could be added) or breaking backward compatibility (less adaption/usage). 2. 120-bit should be fine since IIRC 112-bit security is still acceptable today. |
|
|
|
I did further check and found out that signet version also offline. The Tor link mirror only provide mainnet network even when i add "signet." or "testnet." to the Tor link manually. I don't know other website which also host btc-rpc-explorer. I guess you must self-host it if you insist using btc-rpc-explorer. |
|
|
|
Few thoughts, 1. Long time ago i read Bitcoin Core doesn't implement BIP39 due to security issue[1], which isn't solved by your proposal. 2. If i understood your proposal correctly, does that mean 12 word mnemonic have less than 128-bit entropy due to version field addition? [1] https://bitcoin.stackexchange.com/a/88244 |
|
|
|
We can also severely penalize storing arbitrary data on the blockchain by making witness data starting with OP_FALSE OP_IF taxable as standard OP_RETURN bytes.
This isn't going to cut it if you want to protect BTC from illegal content, making something more expensive doesn't stop an attacker from doing it, especially if they need to do it only once. But don't you agree it's better than doing nothing? What about using Zero Knowledge Proof to make pruning the UTXO set possible? I recall reading about something like that in the past. I mean, my node would keep only block headers and UTXO commitments, and your node would provide a valid ZKP that certain parts of the UTXO set that I am checking are valid. Do you refer to ZeroSync ( https://zerosync.org/)? I think Zcash operates in a similar manner.
IIRC ZKP on Zcash used to create private/anonymous TX rather than UTXO set. |
|
|
|
If everyone use wallet which support full RBF, they can replace their transaction with higher fee rate even when the transaction itself doesn't have RBF flag. Since we have some nice miners here on Bitcoin talk, how about a reputatable miner here creates a self moderated thread for forum users to drop their transactions which have been stuck for while to be accelerated.
I expect all miners would join certain mining pool, where those miners have little or no control which transaction included on a block. So those miner have switch to different pool which let miner choose which transaction added to a block. |
|
|
|
IBD, why every node has to do it?
If I only run a prune node, I can not use my node to check too old block details like genesis block, because it exceeds my prune node limit. I feel it is like unnecessary to sync it from genesis block.
Downloading whole blockchain is necessary to verify that all transaction and block follow Bitcoin protocol/consensus. IBD, why every node has to do it? You can of course use prunednode.today, and download a pruned node. I just tried: it took my server 75 seconds. But you'll never be absolutely sure it's completely legit. And if enough people do it, someone will find a way to scam them. This guy knows a thing or 2 about the subject: FWIW, I just removed a nearly year old post with a .bitcoin directory download that would have stolen all your bitcoins.
Case in point as to why these "download the blockchain" links are a disaster. God knows how many people got robbed due to it. But the chainstate database/etc. aren't intended as external interfaces and I would be totally unsurprised if there was a way for malicious data in them to result in code execution. And if OP want more recent data, he can check https://bitcoin-snapshots.jaonoct.us/. I haven't tried it, but the owner also provide assumeutxo file which should be better than copy of Bitcoin Core folder. |
|
|
|
|
Do we need another sidechain? Liquid and Rootstock already exist, while Drivechain still in development. In addition, many things available on SatoshiVM already offered by one of those. For now there's little technical detail, so i only say the author should explain why Bitcoiner should use SatoshiVM rather than other sidechain.
|
|
|
|
|
I thought they left this forum after both of their main account got banned/nuked. It looks like they create their thread on "Service Announcement" rather than "Electrum" to avoid people who raise skepticism against them, which seems to work until you create this thread. Anyway, since most of the shill post got deleted i only able to report "CryptoAIDev" and "sedinvore" for ban evasion.
|
|
|
|
Can I add extra nodes that are more close to me, to speed up the syncing?
As stated by other user, usually there are other factor which limit sync speed. But FYI if you use Bitcoin Core, you can't connect to more node since Bitcoin Core only let you connect up to only 10 nodes (outgoing connection). The only way to increase that is by editing Bitcoin Core source code and then compile it. 2. Bitcoin Core happen connect to node with slow connection speed or physically very far from where you live (which cause slower download speed).
You can try close and reopen Bitcoin Core in order connect to different full nodes, but don't expect much difference.
Where to find the node list? There are many website such as bitnodes.io/ which provide such list, but you can't know which of those have fast connection. |
|
|
|
|
Show Posts
