Berbicara tentang kecepatan dan transaksi Bitcoin yang lama dan cukup mahal tidak terlepas dari pembahasan dari ukuran blok Bitcoin saat ini yang tidak boleh melebihi 1 MB.
Sejak Agustus 2017, maksimal ukuran blok bukan 1MB, tetapi 4 juta weight (satuan ukuran). Intinya ukuran blok bisa sampai 4MB, tetapi pada umumnya hanya bisa mencapai 2-2.5 MB Masalah ukuran Blok Bitcoin, setelah saya baca dari beberapa literatur masih menjadi perdebatan diantara para developer Bitcoin dan belum menemukan titik temu.
Menurut saya, meraka tidak akan menemumkan titik temu atau sepakat karena ideologi yang berbeda
Reference : https://en.bitcoin.it/wiki/Weight_units |
|
|
|
Most of cryptocurrency exchange (such as LocalBitcoin & BTC-e) has always been centralized, but the difference are they didn't comply with KYC/AML, didn't ask personal information and allowed user with private connection. All anonymous (and centralized) exchange these days are scam or simply will be removed by the government soon. don, that is the problem i am talking about, there should be no problem that requires blocking of funds. When BTC is deposited it stays as btc and that is your money regardless of where it originated or who it used to belong to.
If you don't own the private key of your Bitcoin, then you don't own it Hopefully proper p2p stuff is going to get more robust and easier to use. Right now it's on the painfully clunky side.
And some DEX even require lock small amount of Bitcoin as insurance, but it should be more user-friendly if more people use DEX and atomic swap can be used securely |
|
|
|
I'm not expert or fans of LN so i can't answer all question 2. It looks like the most efficient evolution is a network where everyone connects with only a few, big, stable nodes?
On LN? Yes & it already happen naturally as merchant/seller usually become "big" nodes. 3. What happens if everyone wants to get their bitcoin out of the network at the same time?
If you meant LN network, then main-chain will be flooded with transaction about closing LN channel 4. What happens if the big nodes decide to just go offline??
There's no thing such as big or small nodes. If some nodes are offline, bitcoin network will run just fine. But if you're talking about LN nodes, then user funds are locked for some times and there are 2 possibility with transaction routing : 1. User simply route their transaction through another nodes/channel 2. User is forced to make new channel 6. If the Lightning Network ends up being what everyone uses, who will use the main network? Also, does that mean that mining might be impacted?
You still need main network even if everyone use LN. You still need to create on-chain transaction to open and close LN channel. 7. If block rewards keep reducing but transaction volumes don't increase, will that impact mining? Or is the idea that fees will high enough to pay miners? Does this also assume that the value of Bitcoin must be high?
The scenario you mentioned is possible, but if both don't happen then mining difficulty will drop when block rewards decreased |
|
|
|
Have anybody try to run vanitygen on Google's TPU cloud machine or any HPC service? What's the best keysearch rates has it archive so far?  Why would you run it online? It is risky to do that because your data could be intercepted. You should run vanitygen offline on a secure computer. Using OpenCL is fast enough for me. I think his point is Google's TPU or HPU can generate vanity address at faster rate. While it's true that the information could be intercepted, using encrypted connection could solve the problem. Using split key is a much better solution, so that Google itself can't know your private key either. They can still know you generated the address through. I totally forget about split key. But google knowing user generate vanity address doesn't matter unless you could know bitcoin address just from partial private key, brute force to get private from an address with partial private key or have serious privacy concern. |
|
|
|
Have anybody try to run vanitygen on Google's TPU cloud machine or any HPC service? What's the best keysearch rates has it archive so far? Why would you run it online? It is risky to do that because your data could be intercepted. You should run vanitygen offline on a secure computer. Using OpenCL is fast enough for me. I think his point is Google's TPU or HPU can generate vanity address at faster rate. While it's true that the information could be intercepted, using encrypted connection could solve the problem. But Google's TPU is optimized for AI stuff (deep learning, neural network, machine learning, etc.). |
|
|
|
|
Android file system don't use NTFS or FAT/FAT32, most devices uses ext4 so you should select "ext2, ext3,ext4, ufs, ufs2, etc.", otherwise you won't able to find your wallet files or other data you have.
You also need to know where the wallet keep wallet file, but most times it's placed on Android/data/<application directory>
|
|
|
|
Looks like ASIC and non-ASIC discussion won't stop, but people should remember that it's easy to put backdoor on ASIC (such as antbleed) as it's closed source and allow government/actor to control PoW-based cryptocurrency easily. Without ASIC which is fully open-source and have good efficiency, GPU is clearly superior in this case. I guess there's a market for computational power outside of mining (cracking passwords? training neural networks?) but I doubt that it's mature or profitable beyond the occasional hobbyist.
The market is bigger than you think and there are more fields from astronomy to medical fields. But i doubt they'd buy second-hand GPU, only hobbyist or budget users who would buy second-hand GPU It's an incredibly interesting discussion and there's definitely a conflict of interest between ASIC manufacturers vs miners (ie. ASIC manufacturers being miners themselves) that doesn't doesn't apply to GPU manufacturers. Still I doubt that this problem is inherent to ASICs. Given a strong and stable enough market, GPU manufactures might just as well enter mining eventually (there's little risk to their core business after all, beyond the risk of mining). And the ASIC market might become more competitive and diverse in terms of available vendors.
Little risk? Both Nvidia and AMD suffering from overstock after various coins price crashed. They need to think ways to sold older GPU series while there's no way they delay their GPU launch. I don't know about AMD, but Nvidia now focusing their product for gaming, deep learning & anything related with GPGPU. So i doubt GPU manufacture would enter mining unless party with power (government, banker, etc.) took interest with cryptocurrency or mining become popular again to the point where they'd take the risk again. |
|
|
|
Bitcoin script is pretty small as each codes only have 4 byte in size, so it only save less than 16 bytes and contribute little to reduce blockchain size growth. Also, all wallet must adopt to this format and i doubt it can be done without hard-fork, unless you introduce new opcodes and older nodes treat it as anyone-can-spend (just like SegWit backward compatibility). Roughly it look like this where nodes automatically convert it to proper script and put the signature to correct position. OP_PRESET <preset_id> <signature>
Using this method means that you can get size of input signatures down from O(n) to O(1). There is also space saving on the outputs because you only need to use a pub key and not other scripting stuff.
It's still has O(n) space complexity unless you're talking about MuSig Schnorr |
|
|
|
|
Another feedback :
1. Last time i missed the part of your target audience, so IMO it's too detailed and looks like it's targeted for tech savvy or computer science student. You should remove the details on Internet and TOR, unless you specifically want the reader know about it.
2. I don't see why CT/Confidental transaction is grouped with CoinJoin since both of them aren't dependent to each other
3. CT and stealth address proposed/developed by one of Bitcoin developer, but it's not used on Bitcoin. So i think you shouldn't include it on your Infographic
|
|
|
|
|
There's no wrong time, but it might be best time, especially following momentum sometimes is good idea. Even so, there are many problem that must be overcome such as :
1. Get community support, especially most people are against hard-fork
2. Make sure Bitcoin network isn't vulnerable during transition, there are few things that should be thought seriously such as initial difficulty
3. Get miner support, which is unlikely because SHA-256 ASIC pretty much only can mine Bitcoin. Even BCH only have 3% of BTC's hashrate, so their ASIC essentially become expensive heater.
But while ProgPoW is great idea, i don't like the fact it's utilized for GPU.
|
|
|
|
The cases I linked above are also a 1-of-n multisigs, so technically the output script isn't going to get bigger every time because only one signature is required..
I'm not sure about if you can re-use signature to reduce script size, but i'm sure script size is going bigger as you need to state same public key multiple times. A bit off-topic, i found formula to predict multi-sig size which can help you predict actual script size at https://bitcoin.stackexchange.com/a/52720 |
|
|
|
When people are saying that we can use the blockchain technology to either store or just verify documents, do they mean the bitcoin blockchain or is it just the idea behind the bitcoin blockchain that could be utilized in other blockchains? That depends since both of them are possible, but on most cases people are talking about it's application on another blockchain. But beware that most them are using "blockchain" term as buzzword and actually they're using distributed database. There is not difference between what these people do and what proofofexistence.com do except that for the last one it is an intentional spam and you are not really saving files but a hash that proves you had the file at a that moment.
You can store the file on another blockchain/side-chain, so people who wish to obtain data just need bitcoin transaction id/hash and see it's OP_RETURN data. I'm pretty sure another cryptocurrency/blockchain have similar feature, although i can't remember it. |
|
|
|
This has been mentioned before, but remind me: Is the Bitcoin Development & Technical Board a section that tends to be under-merited?
Used to be, but recently it's not anymore. That's a section I have on ignore, but not because of the quality of posts. It's because of my own ignorance. All of my education has been in fields having little to do with computer science, and when I see people incorporating a lot of tech jargon in their posts, my eyes glaze over pretty quickly.
You can start by only merit question/answer that you can understand, i also use this method You would think that Bitcoin Discussion would be the place where most merit-worthy posts get made, since this is Bitcointalk, but it's the exact opposite. Yet it makes sense that the technical sections would be places where the shitposters don't go, because they can't get away with having their shitposts hidden in an ocean of similar vacuous nonsense, nor can they simply tap out a generic statement about how bitcoin has a bright future and is increasing day by day and expect it to fit in with the members who really know what they're talking about.
Besides, i read all thread on those section (since usually there's only 3-10 bumped thread everyday) & i report all recent spam/plagiarism, so there's no way shitpost exist on recent threads. Still, there's few spammer who throw jargon (such as using SHA256 to encrypt data) and think no one would notice |
|
|
|
|
IMO the problem in that video is,
1. The merchant don't have much knowledge and barely use Bitcoin
2. The merchant use wallet that isn't intended to accept Bitcoin payment
3. I never experience invalid address, so i guess it's the problem with the wallet (whether Coinomi generate invalid QR code or Ethos wallet don't support Bech32)
So even LN won't help at all with Bitcoin usage if those problem still persist
|
|
|
|
What happens? Does the "longest chain win" and thus all communities, except that which had the longest chain somehow, are now considered untrue -- effectively reversing the transactions of all communities that reunify except the one that happened to have the longest chain?
By default, that happens expect it's not "longest chain win", but "chain with biggest proof-of-work/hash-rate" Is there a cryptocurrency that is better suited to this type of fragmentation->reunification series of events, or does bitcoin handle this?
That depends on your perspective, but other cryptocurrency have different solutions such as : 1. On some PoS-based cryptocurrency, block made by address/node with biggest coins is considered as "longest chain" 2. Few cryptocurrency use validator who determine which transaction/block is valid Another way to put it is how would these disparate bitcoin merge multiple histories and provide a managed way to deal with those "merge conflicts" ?
Solving merge conflict is impossible without human involvement, which makes decentralization pretty much useless. Additionally, you would mess up with blocks hash and re-computation is required. It seems to me that once fragmented, nodes should never re-unify, and should instead trade against each other on some market. i.e. BTC-CommunityX and BTC-CommunityY would have to both exist independently... but what if you're not an expert at blockchain and you're just the community member standing up all these services and bitcoin just happens to be the solution you went for, and suddenly the network reunifies, all your history is suddenly lost?
Yes, i also agree it's the best solution. But there are cheap way to prevent lose history when connected to nodes with "chain with biggest proof-of-work/hash-rate" and it's called checkpoint. Basically it makes a node reject block/chain which don't have same block hash on specific block height. So if at least one people have enough knowledge to read documentation, source-code and made minor modification, then the problem is solved (since Bitcoin used checkpoint feature) |
|
|
|
the scaling issue, is a disk issue, we use to host bitcoin nodes and 40gigabytes was fine but when it goes over 100gb and up to 150gb then its a hosting
problem , meaning the network will be smaller cuz less stuff running on raspberry pi'es and other cheap hardware, what u need is a good way to verify transactions without saving them
It's problem for initial sync, not on-chain scaling as old/cheap hardware can run full nodes smoothly (assumed they have big HDD capacity) what u need is a good way to verify transactions without saving them
How can we verify that you truly own the bitcoin if we don't have a history of past transactions? I think he's talking about pruning, but this still require you download all blockchain, verify all block/transaction, record UTXO on chainstate and remove older blocks. But this isn't real solution against increasing blockchain size problem. Those two are related imo. If we increase block size & time, the size of blockchain will definitely get bigger and probably cause some kind of centralization too in terms of who store the blockchain. We need to find a way where we can verify more transactions without increasing the block size too much, which Segwit did. CMIIW.
I have to agree that both are related, there are many solutions to the scalability issue and one of them (but not the best) is increasing block size. Now, the blockchain size issue is not that urgent especially with the fast growth of the technology industry (high Internet bandwith/ storage devices) or we can simply refer to Satoshi recommendation since all of this is his idea in first place: as the network grows beyond a certain point, it would be left more and more to specialists with server farms of specialized hardware. A server farm would only need to have one node on the network and the rest of the LAN connects with that one node. https://satoshi.nakamotoinstitute.org/emails/cryptography/2/There are better solution such as : 1. Move transaction to off-chain/side-chain (such as LN and Plasma) 2. Reduce transaction size (such as MuSig:Schnorr and MAST) 3. Reduce bandwidth used when propagate transaction/block (such as Minisketch) Increasing block size is needed, but IMO we shouldn't use it as 1st option. |
|
|
|
I doubt anyone would share their wallet.dat, even if it don't have balance. If you don't mind empty wallet, you can generate it from older client at https://satoshi.nakamotoinstitute.org/code/Few warnings : 1. Old client can't sync as some protocol changed 2. Old client performance is very bad 3. Older protocol have P2PK transaction which used on IP Transaction |
|
|
|
Bagi intermediate/advance user, bisa melakukan verifikasi installer dengan signature installer dan public key PGP resmi. Link guide : https://bitzuma.com/posts/how-to-verify-an-electrum-download-on-windows/
Daftar server jahat (mungkin tidak lengkap) : 'gregoire12.mldlab-works.space:50002:s',
'readonly.23734430190.pro:50002:s',
'wireless12.bitquantum.space:50002:s',
'superuser.23734430190.pro:50002:s',
'pacslinkip12.krypto-familar.fun:50002:s',
'topicres.imaginarycoin.info:50002:s',
'wlseuser12.bitcoinplug.website:50002:s',
'operatns.imaginarycoin.info:50002:s',
'superman.cryptoplayer.fun:50002:s',
'lucent01.23734430190.pro:50002:s',
'qtmhhttp12.mldlab-works.space:50002:s',
'plmimservice.bitcoinplug.website:50002:s',
'username.cryptoplayer.fun:50002:s',
'qlpinstall.krypto-familar.fun:50002:s',
'adminstat.imaginarycoin.info:50002:s',
'lessonuser2.cryptoplayer.fun:50002:s',
'utilities12.pebwindkraft.space:50002:s',
'openspirit.cryptoplayer.fun:50002:s',
'qautprof12.coinucopiaspace.xyz:50002:s',
'prodcics12.imaginarycoin.info:50002:s',
'vcoadmin.23734430190.pro:50002:s',
'siteminder.23734430190.pro:50002:s',
'videouser.bitcoinplug.website:50002:s',
'anonymous.bitcoinplug.website:50002:s',
'oraprobe.23734430190.pro:50002:s' Sumber : https://github.com/spesmilo/electrum/issues/4968#issuecomment-450046206 |
|
|
|
|
Show Posts
