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 |
|
|
|
|
ArchLinux is best choice if you can and want to bother with various configuration/deal with fast-rolling update distribution.
CentOS/Fedora might serve as good alternative as it based on Red Hat, even though i still prefer Debian.
|
|
|
|
But if you seriously need privacy, you should consider other wallet such as Wasabi Wallet, Samourai Wallet or Bitcoin Core. All of them offer different kind of privacy though. I always used Electrum. I guess it's time for me to check some other wallet. Knowing more wallet is great, but each wallet have it's own advantage and disadvantage. TLDR, if you don't want take risks with unpopular wallet or uses lots of resources, generate new Electrum wallet which only used with Tor connection is best solution. Wasabi Wallet : + Use Chaumian CoinJoin (basically use you and other's bitcoin/UTXO on a transaction to prevent tracking) + Forcing user to use Tor connection - Generally new wallet and still unpopular Samourai Wallet : + Use Stonewall (basically generate transaction which looks like using CoinJoin, while actually it's not) + Have option connect only to specific nodes (such as your own full nodes) + Support Tor connection - Only available on android and still on alpha version (on-development) Bitcoin Core + As full nodes, Bitcoin Core broadcast/share all transaction (including your transaction), so it's difficult to know the origin (the one who broadcast/share the transaction) of the transaction + Also support Tor connection + AFAIK it's most stable/secure and thoroughly tested - You must sync Bitcoin Core which is resource intensive When is the possible time to record my IP?
The moment you connect to the node. After that your client requests transaction data regarding your addresses which are disclosed to the node operator. @ETFbitcoin pointed out that there is no point in using Electrum with Tor unless you generate a new wallet. I have described how you should transfer your coins in this post. Basically when you open your wallet |
|
|
|
Also I would like to have a discussion about this solution I have to make EDCSA quantum resistant without changing to a different algorithm.
Why so persistent not to change ECDSA signature when there are asymmetric quantum-resistance signature such as Lattice-based Cryptography and Multivariate-based cryptography? How about making it a requirement in the Bitcoin code that public addresses can only be used once? For quantum computers to impose a threat to EDCSA they need to know the public address. By not reusing public addresses we will be effectively making EDCSA quantum resistant. Users could be trusted to do this themselves but honestly I think people aren't security conscious enough to do it every single time. Therefore implementing it into the existing code would probably be a better choice.
Not bad idea, but this requiring every wallet not to reuse Bitcoin address or hard-fork. Additionally, if quantum computer is fast enough to brute-force private key in matter on minutes (which means transaction hasn't been confirmed) then miners with quantum computer can steal anyone's bitcoin. |
|
|
|
|
Steam can't lose, especially after gamer enjoy have all of their games, friend and community in one place. I won't move from Steam either.
Besides, while Epic Games only take 12%, Steam have regional prices which allow gamer from developing world spend less money. Based on some reddit community, it's customer service is horrible/non-existent.
So while it could attract developer and publisher, they won't able to attract Gamer, at least without major improvement.
|
|
|
|
Let's keep LN underrated until it's stable enough and easy-to-use LN wallet are available. Is there a wallet that the average person (i.e. not someone on this forum) can use to make a payment over LN right now?
There are few wallet with that goal such as Eclair Wallet (Android and Desktop) and Zap (Desktop). I've tried both of them on testnet few months ago and clearly it's not suitable for regular person, but it's easy for Bitcoiner who know the basic of how LN works. Eclair requires no configuration while Zap still need few configuration. But it should be possible now on Eclair if the store/services generate QR code. For example https://www.lightningspin.com/ already show QR codes when you want to start gambling, even though i haven't tried it as it's on mainnet. Also, link shared by figmentofmyass also show pretty much what you ask/think |
|
|
|
|
How about only seriously consider appeal if :
1. The member have good reputation or known to help others
2. They have high rank or/and received lots of merit (earned in correct way)
3. Many members agree to unban. This is should be easy and good way since so far i only see 2 banned member got support from other member to be un-banned
Additionally, escrow some Bitcoin is unnecessary and limit to those who have lots of Bitcoin. Simply remove signature space 1 year - forever is easier solution. If the user only care about earn money, he will leave while actual member will stay and continue being helpful.
|
|
|
|
|
Show Posts
