As of your inquiry for a timetable, I'm considering a demonstration of dual ASIC+GPU mining fork of bitcoin on a testnet and it will be launched in April 2019 expectedly. But it is not anything related to a fork attempt because as I've mentioned above-thread there are other issues to be included in a hypothetical hard fork.
We need to discuss everything in details with prominent Core figures and have their support or at least to become absolutely sure about it not being considered a hostile act or a shitty ico/altcoin attempt. Without this condition being somehow fulfilled there will be no fork as far as I'm concerned.
Godspeed to you! While I doubt that a PoW-scheme change will make it into an "official" upgrade-hardfork any time soon (at least without an acute state of emergency) I'm looking forward to see a working PoC. |
|
|
|
I don't think NVIDIA or AMD would ever be able to take advantage of their premier in gpu development to be used in mining. They have been profiting from the market ever since Bitcoin got GPU-mineable. There's simply no other game in town for GPU mining other than NVIDIA and AMD. In Bitcoin's late GPU-mining days it was even worse, with AMD's cards being the only option to mine profitably. It is because gpu industry is not just like ASIC, new technology in gpu is very expensive and as a common practice people wait like months for cards to become more reasonably priced before installing them on their rigs. Most importantly, Game industry is just in its infancy and shows no sign to cool down, NVIDIA and AMD are dominant but not done with other competitors, most importantly Intel has every potential to kick in, not to mention ARM and others.
NVIDIA has utterly dominated the GPU market for more than 2 decades; they've essentially invented the market. AMD / ATI joined a bit later but is just as dominant. I wouldn't expect Intel or ARM to join the top ranks any time soon, especially since developing new GPUs is very expensive and requires a lot of expertise as you rightfully pointed out. Additionally NVIDIA has been only upping their game with their involvement in the development of autonomous cars. (I personally wouldn't want to be the one buying a GPU that has been slaving away in a mining rig for months on end)
or you could buy them in half of the price (or less) and statistics show that the most problem with GPUs that has been in a mining rig is their MOSFET component that could get repaired with something around 30 USD. Ooh that's neat. Wish I'd been aware of that sooner. 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. *cough cough* SPECTRE *cough cough* MELTDOWN *cough* CPU and GPU architectures are closed source as well. GPU drivers mostly too. Heck we've had two critical CPU vulnerabilities just a year ago. Not that it makes Antbleed any less bad. It's just that that's a general problem we are facing with hardware and drivers nowadays. 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 I have no doubts that it's a huge market, but what good is a huge market if you can't make use of it? Can you profitably sell computational power (ie. as in a paid folding@home, not as in selling hardware)? Serious question btw. Apart from some half-baked ICOs obviously. 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. I doubt that NVIDIA and AMD suffered much. NVIDIA's cards simply went back to the price point that they were 2 years ago at time of the GTX10xx's series' release. Let that sink in. A whole generation of GPU's not getting cheaper for 2 friggin years. Not sure about AMD though, I didn't keep track of them as much. Don't get me wrong, I'm not arguing that NVIDIA and AMD will start mining themselves anytime soon. But there's little stopping them from doing so if the market reaches a high enough level of maturity. Also be aware that I don't think GPU mining is bad. I'd be very interested in seeing a GPU-mining based Bitcoin hard fork that isn't a mere cash grab. I'd just like to point out that the grass is not necessarily greener on the other side. |
|
|
|
Blockchain.com offers a wide range of APIs that covers most of the basic use cases: https://www.blockchain.com/apiYou could also look into Electrum's API: http://docs.electrum.org/en/latest/protocol.htmlIn this case you'd still need to install Electrum on one of your servers and secure the wallet yourself, but you wouldn't need to run a full node. I think for the more funky stuff you'll probably have to look into Electrum's API rather than Blockchain's though. |
|
|
|
Professional miners, don't switch between coins just because of temporary price fluctuations as reported by coinmarketcap or other indexing services, they consider choosing coins with stronger infrastructure and long term perspective as well. As a result we have an objective measure regarding actual value of coins. When something bad happens for a coin, both price and hashrate will drop and vice versa and mining industry acts more coherent with basic incentive system designed for bitcoin... In a way NiceHash made switching between coins due to short term price fluctuations their business model. It was also their hashing power that was used for the 51% attack on Bitcoin Gold. That's only possible due to a lot of free-floating multi-purpose hashing power. Accordingly I'm not sure whether the assumption of professional miners not switching between coins based on short-term profitability quite holds. Obviously they likely won't switch for intra-day price fluctuations, but on a weekly scale it may make sense to simply go for the most profitable coin and exchange for your target currency from there. Let's look closer to the recent event in ASIC industry, Bitmain is launching its 7 nm ASICs while bitcoin is in the lowest price levels in a year, now what do miners have to do other than buying new hardware and dumping their now useless ASICs? See? It is worse than slavery!
This is very different for gpu miners, when the whole market is down, there is a chance to assign other jobs to gpus and more importantly, there is no force to install new hardware. For people mining as a hobby, using their gaming GPU, sure. Once mining is not profitable anymore, they'll simple continue using their GPU for gaming. But any commercial miner still has to upgrade their GPUs regularly, as GPUs are no exception from Moore's Law. As far as other jobs are concerned I doubt that dedicated mining rigs will see many uses besides mining other coins. 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. So short of selling your GPU to an unwitting buyer (I personally wouldn't want to be the one buying a GPU that has been slaving away in a mining rig for months on end) the "chance to assign other jobs" is realistically speaking rather marginal, even for GPUs. I think it is all about exchanges and their poor software designs: typically they do not distinguish between a multi million dollar and a one hundred dollar txn and use a same stupid parameter as the number of confirmations. it is really crazy, you don't need to wait like two days to be convinced about my deposit of like 5 etc but if I had enough money to buy like 1,00,000 etc from you, I wouldn't release the funds sooner than a week after the first confirmation. When two entities have chosen a low hashrate coin to do a high stake business, they need to treat it properly.
Sure. But on the other hand we are also lacking hard rules in terms of confirmation counts for vulnerable networks. You can't expect proper implementations if there are no proper recommendations (ie. like Bitcoin's 6 confirmations). --- 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. |
|
|
|
Hi, I'm not sure what do you propose. If you are talking about "an inbuilt method to process these tx" (in which software ? bitcoin-core ?) then there is createrawtransaction which takes as parameter almost what you described. If you are talking about kind of a script language that would compile to Script there is Ivy but I have not tested it yet. If I'm not mistaken OP is suggesting a method to reduce transaction size and therefore blockchain bloat. So current tx. is (basically) like this right; inputs;
<unlock script>(n times)
outputs;
OP_DUP OP_HASH160 <hash> OP_EQUALVERIFY OP_CHECKSIG (n times)
but this is really boilerplate. And probably like 90% of tx. are like this^. so why not have an inbuilt method to process these tx. much easier and more scalable? I think one of the problems is that replacing boilerplate code like above with an abstraction makes it incredibly hard to upgrade the network when the logic behind the "simple_unlock" changes (or should change, due to a shift in usage of transaction formats). Case in point -- the script used in the example above is already more or less obsolete, it's a legacy P2PKH transaction. Wrapped SegWit P2SH transactions already look different, native SegWit transactions look different still. All based on the same op_code primitives that every node understands (Well not quite, SegWit also saw the re-introduction of some formerly deprecated op_codes, but to be honest I'm not sure whether they are unrelated or necessary for these redeem scripts). However I guess the main reason why we don't have a transaction type as suggested above is the lack of a viable ECDSA signature aggregation method. My understanding of cryptography is spotty at best though. |
|
|
|
I personally am still pro-ASIC mining for various reasons. Mainly because it increases the stakes that miners have in Bitcoin; to a lesser extend because it decreases the vulnerability of Bitcoin's PoW to future quantum computers (under the premise that early quantum computers will be even more centralized than early ASIC miners).
I don't follow how ASIC or gpu based PoW would have anything to do with QC vulnerability. Actually I believe they don't. I assume you are speaking of SHA256 immunity to QC attack but it is the same for ProgPoW and many other gpu/cpu friendly algorithms, they are as resistant to QC as sha2 if not even more. QC is supposed to crack ECDSA encryption in the transient phase in which pub key is disclosed by user (to claim the utxo) and has nothing to do with mining. ECDSA is definitely the more worrisome factor, but I'm indeed referring to using quantum computers for mining. While quantum computers don't have any apparent computational advantage over classical CPUs as far as SHA256 is concerned, they are also not especially disadvantaged. With classical computing reaching its physical limits and quantum computing just getting started, it seems rather likely to me that quantum computing (assuming it doesn't hit a wall itself) will outperform classical CPUs / GPUs in terms of SHA256 hashes within our lifetime -- with ASICs offering a much wider margin of safety. I have to admit though that this point becomes utterly moot under the assumption that Bitcoin's future PoW scheme is as resistant against QC as it is against ASICs. Given the size of the industry nowadays I also have my doubts that a mere switch to GPU / CPU mining would help decentralization all that much; at least not without additional measures to make pool mining significantly less attractive.
You are absolutely right, and you may be already aware of my other proposal, Proof of Contributive Work, PoCW which is presented in a topic titled as Getting rid of pools ...Obviously, we are discussing a hard fork here and it is totally possible to have both at the same time but we need to discuss each issue separately. I'm afraid getting into pooling problem would be a distraction here. I'm aware of your proposal and didn't mean to distract  I just think it's worth keeping in mind that not ASICs per se are the problem, but the centralization that they enable (ie. nothing is gained if we get rid of ASICs only to be re-centralized soon after). Regardless of this, economics of scale would still apply and whether big miners buy ASICs or GPUs wholesale seems to make little difference to me. However I'm not quite up-to-date with the current mining hardware market and Bitmain's stranglehold may be worse than I think.
It would be interesting to see what sharing mining hardware with Bitcoin would mean for alts though (and vice versa).
GPU industry is far more competitive and healthy than its ASIC counterpart and more importantly, gpus are distributed around the globe more evenly. A gpu friendly algorithm of any type has a large memory footprint (to resist being cracked by ASICs like what happened to bitcoin) and memory banks are a rare resource with limited global supply, a scene that is unlikely to change for near future. IMO, there is nothing to worry about gpus being monopolized, nobody could afford such a huge investment because the demand for mining is a fraction of the total demand for gpus and manufacturers won't sacrifice their market for a tricky one time business. Is it though? The GPU industry is essentially a duopoly of NVIDIA and AMD, with Bitcoin's GPU mining era having been an AMD monoculture. Additionally the 2017 bubble had enough of an impact on the GPU market that regular gamers were facing a supply shortage and prices inflated way beyond the original release date prices. And that was just alt coin mining, even excluding Scrypt-based coins. GPUs are definitely wider distributed than ASICs, but don't underestimate the market impact of crypto. Given a crazy enough market high-end GPUs (ie. the ones that are relevant for mining) can become just as hard to attain for the common mortal as ASIC miners. As of altcoin gpu miners, I believe it is really interesting because they can act as another stabilizing factor.
Funny, I personally assume quite the opposite as I'm instantly reminded of the BCH / BTC hashrate fluctuations and the recent 51% attacks on minor alt coins. Not necessarily a problem for Bitcoin, but definitely not stabilizing for the ecosystem as a whole. That's just my thoughts though, what leads you to the conclusion that Bitcoin sharing hashrate with alts would be stabilizing? In cryptocurrency we have no assumption about loyalty, all in all it is about being rational instead of loyal. I know you are aware of this point I just don't get it why should you make such a weird argument tho. If your investment is at stake and you can't use it for anything else (as is the case with ASICs), loyalty becomes the rational choice. Granted, it's the kind of "loyalty" that only lasts until the hardware becomes obsolete, but that's still a couple of months of hashing that you would otherwise need to continuously compete for. Let's forget about 50%+1 attack, not everything is about such an attack and it will never happen for a big fish like bitcoin or ethereum and smaller ones should take care of their business by smart measures, I've proposed one earlier: require more confirmations for more precious txns.
Requiring more confirmations is the obvious solution, but also an incredibly impractical one. Having your customers wait for a day worth of confirmations on the off-chance that a someone is about to mount a 51% attack is rather crippling, even if you only apply it to larger transactions. |
|
|
|
|
I personally am still pro-ASIC mining for various reasons. Mainly because it increases the stakes that miners have in Bitcoin; to a lesser extend because it decreases the vulnerability of Bitcoin's PoW to future quantum computers (under the premise that early quantum computers will be even more centralized than early ASIC miners).
Given the size of the industry nowadays I also have my doubts that a mere switch to GPU / CPU mining would help decentralization all that much; at least not without additional measures to make pool mining significantly less attractive. Regardless of this, economics of scale would still apply and whether big miners buy ASICs or GPUs wholesale seems to make little difference to me. However I'm not quite up-to-date with the current mining hardware market and Bitmain's stranglehold may be worse than I think.
It would be interesting to see what sharing mining hardware with Bitcoin would mean for alts though (and vice versa).
|
|
|
|
I read one article in 2017 highlighting the negative impact quantum computers will have on Bitcoin, but what I want to ask is if this will only impact the Proof of Work coins only or it will also impact Proof of Stake coins also?
Future quantum computers are more likely to attack the cryptographic algorithm used to sign transactions (ie. by deriving the private key from the public key); this is largely independent from whether PoW or PoS is used. Accordingly whether a coin will be vulnerable to quantum attacks will mostly depend on the respective coin's transaction formats and the type of public-key cryptography being used for the signatures. It's rather unlikely that future quantum computers will have an advantage over ASICs, making quantum attacks (ie. 51% attacks using quantum computing) on PoW uneconomical. At the point where quantum computers are more effective at mining than ASICs they will probably be used to simply mine the coin, rather than to attack it. Either way it's currently still pretty much impossible to tell how long it will take for quantum computing to become a threat to current common cryptographic standards. |
|
|
|
Sorry to ask a stupid question, but does this mean it's possible to have legacy and SegWit addresses in one wallet? From the discussions seems it's possible but I had always thought this couldn't be the case and still maintain 2 wallets. Or does the getnewaddress command also generate a new wallet? If Bitcoin Core could do that then it solves one of my old issues (providing legacy address but maintaining in same wallet).
Yes it is possible to have both - see screenshot. I think it is because Segwit is backwards compatible (being a soft fork). SegWit being a soft fork has nothing to do with the way Bitcoin addresses are generated. Good question though. From what I've gathered so far P2SH-SegWit and native Bech32 SegWit addresses follow different derivation paths, but I guess legacy addresses and P2SH-SegWit addresses share the same derivation path? Or maybe that's just specific to Bitcoin Core's HD Wallet implementation? |
|
|
|
I dont believe any quantum computers that are out or coming out anytime soon can break SHA256 yet.
When something like that comes out, we should have some time to react before it starts breaking things.
Dont forget that a computer that can break SHA256 is a huge threat to the entire internet, not just bitcoin.
It is worth noting that the real worry regarding quantum computing and Bitcoin is not a possible breakage of SHA256 but of ECDSA, Bitcoin's transaction signing algorithm. For SHA256 there is currently no known algorithm that would give quantum computers an edge above classical CPUs, let alone ASICs. As far as ECDSA is concerned things could turn out bad though... eventually. It will likely still at least take a decade or two until quantum computers become a practical risk for ECDSA, if not longer. Either way it should be plenty of time to harden Bitcoin transactions against possible quantum computing based attacks. |
|
|
|
|
I mostly spread out to various index funds -- S&P 500, DAX, CAC 40 etc. Since I live in the EU mostly biased towards EUR based indizes to limit foreign exchange risk.
The classical markets are pretty grim right now as well though, so I'm in the red ¯\_(ツ)_/¯
Still a better hedge than alts though and not money I need in the immediate future, so it'll turn around eventually.
|
|
|
|
|
I guess that's what happens when KYC/AML requirements clash with business requirements.
On the one hand exchanges have to follow KYC/AML procedures, on the other hand they want to on-board their users as fast and easy as possible. Throwing KYC/AML requirements straight into your newly registered user's faces could drive them away and apparently KYC/AML only becomes relevant once money moves out of the exchange. So you keep that complicated, user-unfriendly stuff for later, once you already got the user's business and they have some proper incentive to follow your KYC/AML procedures ie. to get access to their money.
Kinda scummy, likely a dark pattern but whatcha gonna do. I think there are a handful of exchanges that verify your account before money can even enter the exchange, but those seem to be rather the exception.
|
|
|
|
Slightly wrong section, this thread should probably be in "Meta" or "Beginners & Help" Posting a link to an article is fine as long as you add a bit of context to it, eg. what aspect specifically you are wondering about. If you just throw in a link without any additional thoughts it comes off as rather spammy. Just don't copy / paste articles or content without referencing the source, otherwise you'll get banned for plagiarism. |
|
|
|
Not all combos are valid, because of the checksum, amirite?
Yes. I think actually most combos won't be valid. However there's little to be done besides brute forcing the available combinations and then 1) checking whether the checksum is correct, and if the checksum is correct 2) whether it's associated with any transactions. |
|
|
|
thank you for correction. I directly jumped in timeline section, and unfortunately there was no information about bug release date - so it looked like the bug was in a release that published the same day.. however, I am still happy with the response time, but why such important information doesn't exist in timeline!? It's right above the Timeline in the Technical Details section: In Bitcoin Core 0.15, as a part of a larger redesign to simplify unspent transaction output tracking and correct a resource exhaustion attack the assertion was changed subtly. Instead of asserting that the output being marked spent was previously unspent, it only asserts that it exists. I don't think disclosure timelines usually include the "release date" of the bug, as the introduction of exploitable code can not always be easily pin-pointed (and in some cases it's been there all along and becomes exploitable as technology progresses). Heartbleed [1] and Cloudbleed [2] are other good examples of well documented timelines. (Bonus timeline: Remote installation of the original Doom on network enabled Canon printers [3]) [1] https://www.smh.com.au/technology/heartbleed-disclosure-timeline-who-knew-what-and-when-20140414-zqurk.html[2] https://blog.cloudflare.com/incident-report-on-memory-leak-caused-by-cloudflare-parser-bug/[3] https://www.contextis.com/en/blog/hacking-canon-pixma-printers-doomed-encryption |
|
|
|
Hello ChipMixer,
From last 1-month after transferring BTC to your wallet when ever we try to restore session to withdraw our BTC your page goes dead and we always get error "Server internal error".
This error pop only after we transfer the BTC to your wallet, if we don't send BTC and we try to restore session is work perfectly.
SO KINDLY TELL US WHAT'S THE CATCH.
Have you tried accessing their website via Tor on their onion address? ( http://chipmixerwzxtzbw.onion/ ) I've occasionally had problems accessing their clearnet address as well, but their onion address seems to be unaffected by whatever is causing this occasional issue. |
|
|
|
Timeline for September 17, 2018: (all times UTC)
>> 14:57 anonymous reporter reports crash bug to: Pieter Wuille, Greg Maxwell, Wladimir Van Der Laan of Bitcoin Core
>> 15:15 Greg Maxwell shares the original report with Cory Fields, Suhas Daftuar, Alex Morcos and Matt Corallo
>> 17:47 Matt Corallo identifies inflation bug
.
.
>> 23:21 Bitcoin Core version 0.17.0rc4 tagged
September 18, 2018:
>> 00:24 Bitcoin Core version 0.16.3 tagged
which means within 3 hours the bug identifies and patches in less than 10 hours.. this is a great benchmark. so a bug that only lived in 10 hours is really like it never exists. its an honor, not hilarious. A bug that was known for 10 hours The bug was introduced with 0.15 [1] which was released in September 2017 [2], so the bug was around for about a year. Excellent response time nonetheless. [1] https://bitcoincore.org/en/2018/09/20/notice/[2] https://github.com/bitcoin/bitcoin/releases/tag/v0.15.0 |
|
|
|
While there are wallet clients that are written using JavaScript / Node.js, getting deep into the matter will likely nonetheless require solid c/c++ knowledge though (or Go or Rust if you feel especially fancy today).
not necessarily. i dare say in 90% of the times you just have to be familiar with A programming language. as someone who has looked at a lot of source code i have to say it is not hard reading them, you may not know 100% of what they are doing but you can see what is happening. I meant for writing the code (or maintaining a project) As far as reading the code is concerned I fully agree with you. |
|
|
|
Honestly? If you want to attain the skills of working on your own cryptocurrency (or whatever else you want to build around a blockchain or distributed ledger) knowing your way around consensus algorithms, cryptographic standards and general application security is much more important than the question of which programming language too choose. Knowing c++ inside out won't prevent disaster if your security knowledge is lacking, especially in this field. And in the right hands even JavaScript can become an incredibly powerful tool. In terms of getting started with programming I'd probably recommend JavaScript or Python, as both are relatively easy to get into, with JavaScript being ubiquitous to boot. Especially for anything web related (eg. block explorers) you won't get around using JavaScript (unless you fork an existing solution with little to no changes). While there are wallet clients that are written using JavaScript / Node.js, getting deep into the matter will likely nonetheless require solid c/c++ knowledge though (or Go or Rust if you feel especially fancy today). But to repeat -- choosing the "right" programming language is secondary to having a firm grip on the theory. Also keep in mind that starting in one language won't keep you from specializing in another, so try not to overthink your starting point. Here's some fun crypto related programming challenges to get you started, by the way. Regardless of which language you choose: https://cryptopals.com/ |
|
|
|
Both phone numbers and SMS gateways are centrally controlled, so there's no way to decentralize phone verification in an automated manner (similar to how converting crypto- to fiat-currencies requires cooperation with the classical banking system).
Actually, in that case, a system such as whatsapp could be used for verification. If you make it more email based then it'll work better. I think phone based messengers such as WhatsApp also rely on SMS verification though? https://faq.whatsapp.com/en/android/20970873/Which would put us back to the problem of centralized SMS gateways. Good point nonetheless, maybe there's a way to associate a phone number to a user via SIM card access. I have no idea what SIM data is available to apps however. I've often thought Bitcoin has a similar issue to TOR, no one without money can derive an address they can easily remember. Facebook had to devote an entire datacentre to mine Facebookcorewwwi.onion for example for a week.
Got any experience with Namecoin? I remember this project trying to solve the problem of decentralized name-derivation vs human readability but I never looked into the technical aspects to be honest. |
|
|
|
|
Show Posts
