--snip--
It seems that having 10 outbound connections is a bit low to my liking compared to the 12x larger value for maximum incoming connections. So what gives?
That might be bad idea. With number of node which accept incoming connection which is quite less than number of all nodes (based on Luke's data), that would exhaust total incoming connection of node which accept incoming connection. |
|
|
|
And for the OCD among us, or at least those who have the great idea that I will get organized *soon* it allows us to categorize some things.
i.e. bc1qCarStuff...... or bc1qH0tSauce.... or bc1qC0llect and so on.
Your idea violate BIP 173 though. I also expect some software would throw error or invalid address message. Decoders MUST NOT accept strings where some characters are uppercase and some are lowercase (such strings are referred to as mixed case strings).
|
|
|
|
If you want to organize your UTXOS in some way with some specific denominations/balance, which one do you want to choose?
For personal usage, i don't see any advantage of creating new UTXOs with specific amount. So i'd use different way to organize merge my UTXO such as merge UTXO from signature campaign. If you want to organize your UTXOS in some way with some specific denominations/balance, which one do you want to choose? I like using decimal numbers. That means, you start from 10 as your base, and split it into 1, 2, and 5. Which means, this is my set of amounts: 50.00000000 BTC
--snip--
0.00001000 BTC
The lowest value is 0.00001000 BTC, just because of the dust limit, and because it is "safe" amount, no matter which standard address type you pick. But looking at average TX fee rate in last few months, personally i'd avoid creating UTXO with less than 10K satoshi. |
|
|
|
To add: for using the Tor browser, you don't need to install a separate Tor client. It's all included in the browser. Just like Unstoppable Wallet on Android has everything it needs to connect through Tor already.
I guess Bitcoin Core sticks to the basics, and doesn't add anything that can be handled outside Bitcoin Core. That makes sense, it's just more work.
That works, although there are few things to note, 1. The port opened by Tor Browser is 9150, not 9050. I don't remember whether mobile version have same behavior though. 2. Make sure Tor Browser already opened and connected. 3. For mobile device, you also can use Orbot. |
|
|
|
All,
I'm honestly not interested in running any of the recent versions as I don't support taproot. Reason being is that it appears there's a consensus that this has actually made the ordinals and inscriptions possible which seems to directly correlate to the mismatches I've been seeing between my nodes.
Thanks.
Unfortunately, it's common misconception among Bitcoiner. Ordinals is fully possible without Taproot since the arbitrary data is stored on witness data. Actual Taproot mess up is no longer have 10000 script size limit[1]. And even without Taproot and SegWit, what Ordinals do could be replicated using OP_RETURN, address/pubkeyhash, multisig address and others with few limitation. [1] https://github.com/bitcoin/bips/blob/master/bip-0342.mediawiki#user-content-Resource_limits. |
|
|
|
I don't know the answer. However it's first time VPN claim they can give onion address (rather than allow or can access onion address without Tor Browser).
Seriously? I have been using NordVPN which has the ability to connect to an onion server. I've already managed to access onion addresses, in Chrome. But connect to/access onion address and giving onion address (also called Tor Hidden service) are two different thing though. I briefly read NordVPN's page about Tor/onion, but there's no indication they setup Tor Hidden service for their VPN users. And FWIW, accessing onion address without Tor Browser offer less privacy since your browser have unique fingerprint. |
|
|
|
https://cointelegraph.com/news/bitcoin-needs-ethereum-evm-botanix-founderBotanix Labs founder Willem Schroé argues a “huge amount of value” from real-world assets will be captured on Bitcoin, provided it connects to the Ethereum Virtual Machine.
Mainstream Bitcoin adoption won’t happen until it bridges to the Ethereum Virtual Machine (EVM) — the first point of entry for many real-world assets moving on-chain, a Web3 executive argues.If that's true then it doesn't look for bitcoin. Might as well invest in ethereum... Looking at their website[1], it looks like Botanix already do that by creating their own blockchain which support EVM[2] and people can bridge their Bitcoin to their blockchain[3]. So IMO his statement is just a way to promote their blockchain. [1] botanixlabs.xyz/en/home [2] botanixlabs.xyz/en/faqs [3] docs.botanixlabs.xyz/botanix-labs/get-to-know-botanix/introductory-concepts/how-does-botanix-work |
|
|
|
I'd like to add: for privacy, run Bitcoin Core through Tor, and always make use of Coin Control.
Any good tutorials for this? Run Bitcoin Core via Tor? Or just click on the option that appears in Bitcoin Core? Is it viable to use a VPN system that allows SOCKS5? If you only want Bitcoin Core connect through Tor, you can just tick option which available on Bitcoin Core GUI. Otherwise, check this guide https://github.com/bitcoin/bitcoin/blob/master/doc/tor.md. But the other part is you using a pruned node means you’re trusting a third party
Did you mistype something? Pruned node download and verify whole blockchain, so it doesn't trust any 3rd party. |
|
|
|
The main problem is: When I need to send a bit large amount of BTC, the inputs quantity can reach 400-500, with the corresponding
high transaction fee
I checked bcoin docs and found out there's parameter maxFee for API call POST /wallet/:id/send[1]? Have you tried using that? The main problem is: When I need to send a bit large amount of BTC, the inputs quantity can reach 400-500, with the corresponding high transaction fee
How to decrease commision of such transactions? I know nothing about "Bcoin" --snip-- Bcoin basically is JS Bitcoin library with full node feature. In past, i reviewed it's full node feature. [1] https://bcoin.io/api-docs/#send-a-transaction |
|
|
|
First of all, this legendary member with more than 1350 merits can try to get the medicine degree, before spreading complete fake information in the forum about cancer.
- Based on BPIP (https://bpip.org/Profile?id=149737), that user actually receive 355 merits.
- The first 1000 merits was airdropped when merit system introduced.
- I don't understand why should people with many merits should get a degree. You can't convert received merit to money and Bitcointalk doesn't offer scholarship either.
- As other user said, just ignore that user.
All this is evidence that merit system do not work and is useless.
If you're going to present evidence, at least perform non-random sampling among user who receive many merit ( https://bpip.org/Report?r=earnedmerit), perform detailed analysis on selected users and them present result of the analysis. |
|
|
|
I only skimmed it, but i find this part is interesting. The Taptree might become huge and have a billion Tapleaf Scripts, but its on-chain footprint is minimal.
Billion sounds impossible and after re-reading BIP 342 there are 3 resource limit regarding Taproot, Sigops limit The sigops in tapscripts do not count towards the block-wide limit of 80000 (weighted). Instead, there is a per-script sigops budget. The budget equals 50 + the total serialized size in bytes of the transaction input's witness (including the CompactSize prefix). Executing a signature opcode (OP_CHECKSIG, OP_CHECKSIGVERIFY, or OP_CHECKSIGADD) with a non-empty signature decrements the budget by 50. If that brings the budget below zero, the script fails immediately. Signature opcodes with unknown public key type and non-empty signature are also counted..
Stack + altstack element count limit The existing limit of 1000 elements in the stack and altstack together after every executed opcode remains. It is extended to also apply to the size of initial stack.
Stack element size limit The existing limit of maximum 520 bytes per stack element remains, both in the initial stack and in push opcodes.
In particular, it looks like sigops and stack limit would be main limitation about complexity of script/smart contract. |
|
|
|
I disagree. Imagine what would happen if full nodes by for-profit service (e.g. exchange, custodial wallet) got attacked. Their customer would have bad time (e.g. feeling uneasy their deposit never shown on the service) and it could affect their business profit/reputation. Even if the full nodes owned by individual, they would waste some time checking what's wrong with their device/full node software.
That's exactly the reason that for-profit nodes should be connected as close to the only source of truth which is mining nodes . The only source of truth? Bitcoin isn't centralized. Only mining nodes have the economic incentive to be honest by receiving rewards from subsidy and fees .
Malicious node would be banned quickly, so anyone who want to run full nodes for non-malicious purpose (e.g. perform full verification, need whole blockchain data) also have incentive to be honest. Most people can't understand that even mining nodes aren't the same . Have a look at the pools history and you will notice that there are always 3-4 nodes that solve the majority of blocks .
I already know that. Although FWIW one mining pool may have multiple full nodes. That image doesn't represent Bitcoin or other decentralized network. The issue with lightweight clients like Electrum or the Neutrino protocol or even the Lightning network is that they are dependent on communication with honest nodes. If those communication channels are cut off and infiltrated with malicious sybil attacks, there is all kinds of shenanigans an attacker could do. It's not necessarily the double-spend someone loses it all problem. But it could be the case for lightweight and second layer solutions. Communication with "honest nodes" is key to security of funds, aka for funds to stay with the rightful owner.
Fortunately some light wallet (such as Electrum) connect to multiple server, node or backend which make such attack more costly and difficult. |
|
|
|
Actually it's interesting idea, data stored on UTXO is enough to display basic information of address. Creating additional index for fast lookup shouldn't take much storage either. For people who curious about what kind of data available on UTXO (specifically chainstate on Bitcoin Core), check https://github.com/in3rsha/bitcoin-chainstate-parser. We can get 4 TB M.2 SSD around $200 nowadays so the cost of maintaining the full blockchain data is cheaper now compared to few years back, so I will still recommend go with the full data I already have one full archival node, and many pruned nodes. The cost is not the issue in case of local node, the problem is you usually don't get hardware with built-in 4 TB disk, so you need some external one. But on other hand, most device let you replace it's internal storage. Some laptop even have multiple slots for internal storage (such as SATA + M2). |
|
|
|
Saya tidak tahu tujuan pelarangan plagiasi di forum ini
Seingat saya, salah satu alasannya untuk mengurangi spam dengan cara copy-paste artikel atau berita yang terkadang tidak relevan dengan topik sebuah thread. ~snip~
Beneran gan diperbolehkan? Karena ini sesuatu yang rawan banned, apa agan punya referensi peraturan yang membolehkan tentang njiplak dari tulisan sendiri yang di post di web lain? Tidak ada masalah karena self-plagiarism biasanya hanya diperhatikan pada bidang pendidikan dan penelitian. Link referensi, https://bitcointalk.org/index.php?topic=5390888.0. |
|
|
|
The file is encrypted with WinRAR and 7-Zip.
Both WinRAR and 7-Zip use AES-256 which usually considered secure (although as @o_e_l_e_o said, it comes down how they implement it). Anyway, if you plan to store the encrtypted data for really long time, you need to consider possibility AES-256 deemed obsolete or no longer secure enough in distant future. (2) I have purchased a few high-level encrypted USB drives, including two fingerprint USB drives. The seller claims that these encrypted USB drives cannot be cracked. Therefore, relatively weak passwords (~20 characters) can be used for the electronic files stored on these drives. Also, every encrypted file must have a password explanation.
I doubt security of such USB drive, especially since usually biometric usually only used as authentication (not encryption). And there's also possibility serious theft would just open the USB drive and take NAND/flash drive. |
|
|
|
Saya sudah cek sekilas dokumen tersebut dan kelihatannya proses verifikasi identitas akan semakin ribet. Pasal 12 menyebutkan 8 cara untuk hal tersebut, termasuk wawancara dengan calon nasabah. Kira-kira ide awal satoshi mengenai pemilik Bitcoin dan penggunaannya untuk transaksi yang bersifat anonim berhasil atau tidak khususnya di Indonesia? Terlebih mengingat perkembangan perdagangan aset kripto di Indonesia seperti pada quote di atas, ada saja yang menyalahgunakannya sehingga mau tidak mau berlaku KYC sehingga menghilangkan sifat anonim-nya.
Sebagai catatan, Bitcoin (dan mayoritas cryptocurrency) hanya bersifat pseudonymity. Hanya pseudonymity dengan fitur privasi yang bagus seperti Monero yang biasanya dapat dikategorikan sebagai anonymous. Tentu saja sifat pseudonymity hilang jika pengguna Bitcoin berinteraksi dengan jasa yang mewajibkan menggunakan identitas asli/dunia nyata. Dan menurut saya, sayang sekali banyak orang kehilangan privasi nya karena segelintir orang menyalahgunakan cryptocurrency. |
|
|
|
|
Show Posts
