Another Quarter, Another Release! The Groestlcoin production factory has been working overtime as always in order to deliver even more tech to push Groestlcoin mainstream when the time comes. There have been many new fantastic wallets and exchanges added to Groestlcoins repertoire over the past 3 months so we will re-cap these before moving on to what is new today.
Groestlcoin added to SatWallet – A 3-in-1 service. Multicurrency wallet, exchange and soon a debit card!
ChangeHero announced a week of 0% commission for Groestlcoin trades.
Added to BC Bitcoin cryptocurrency exchange, offering 8 fiat pairs!
Added to Chameleon Pay mobile wallet for Android and iOS!
Added to the Okex' strategic partners cryptocurrency exchange; CoinAll! Offering BTC and ETH pairs! With a 21,5000 GRS Giveaway!
Added to Spark Card! Our second MasterCard for Groestlcoin! Provided by Pungoio, powered by TarjetaSpark and issued by Mastercard!
Added to Swirlpay! A decentralised peer-to-peer payment gateway.
Added to Archos Safe-T Mini hardware wallet! Built around encrypted Chipset memory.
Added to Agama Wallet – A multi-asset encrypted wallet for iOS, Android, Windows, Mac OS and Linux from Komodo.
Added to Mr Coin exchange, with 2 fiat pairs (EUR and HUF)
Added to CryptoFacil Exchange – An exchange powered by Bittrex and is a fiat gateway. Leaving you with the ability to buy GRS with Visa and Mastercard.
Added to Bits Game – A gambling service with 2 'PvP' games
Added to Boost X Change Cryptocurrency exchange!
Added to Sucon's Suworld Korean cryptocurrency exchange!
Added to DCXinsta cryptocurrency exchange and swap service with Fiat pairings.
Added to DCXtrade, an Indian cryptocurrency exchange with BTC and ETH pairings.
Added a fiat KRW pairing on Huobi Korea Cryptocurrency Exchange!
Added to AirGap wallet, allowing you to securely store your GRS on an offline device.
Added as a payment method on hodlhodl, allowing you to make global trades without KYC/AML.
Added to TrustWallet cryptocurrency wallet for iOS and Android
The existing Magnum wallet adds SegWit support for the wallet! Allowing SegWit addresses to be used and created from within the wallet.
Added to CycleBit – Who provide POS Terminals that accept GRS payments anywhere, in-store and online. 130 coffee houses in Spain already accept GRS using Cyclebit POS terminals!
Added to Bitinka Cryptocurrency exchange! The #1 exchange in Latin America with 5 fiat and cryptocurrency pairs!
Added to Atomic wallet, a non-custodial cryptocurrency wallet with encrypted private keys and 40,000 monthly users.
Added to NoMiddleMan cryptocurrency payment gateway, offering no usernames, no registration, no KYC, no fees. Completely free to use!
Added to Blockchair! An advanced data analysis tool, mempool monitor and block explorer!
Added to SecuX V20, SecuX W20 and SecuX W10 hardware wallets!
Re-forged: Groestlcoin Samourai
Groestlcoin Samourai is a wallet for the streets. A modern Groestlcoin wallet hand-forged to keep your transactions private, your identity masked, and your funds secure. Its main advantages are its extreme portability and is the most secure Groestlcoin mobile HD wallet. We've built a wallet that Groestlcoin deserves. If you are looking for a wallet that Silicon Valley will never build, the regulators will never allow, and the VC's will never invest in, this is the perfect wallet for you. ![Groestlcoin Samourai Release Video](http://img.youtube.com/vi/i3WU8Tde8XQ/0.jpg)
Head over to the Groestlcoin Samourai Release Page here for the full release announcement.
Groestlimage turns any file into a mnemonic phrase allowing users to generate Groestlcoin private keys and addresses based on the data URI of the provided file. A picture is worth a thousand Groestls.
Turn any image, document or audio file into a BIP39 mnemonic phrase
Groestlcoin Core Config Generator is a simple GUI to configure the groestlcoin.conf file – A developers dream tool! Each configuration option is available via the user interface, grouped by what attributes they affect. For ease of getting started with a new configuration, a variety of preset "node classes" are available on the right-hand-side of the screen. Selecting a preset will load our recommended base configuration for a node fitting that description, at which point you can then tune the configuration at the single option level.
Choose between Mining, Non-Standard Ports, Low Bandwidth, Pruned, Raspberry Pi, Tor, Testnet, Regtest, Non-Syncing and Lightning Éclair presets.
Groestlcoin Simple Push TX is a server to push Groestlcoin transactions via SMS. Now everybody can send new transactions via SMS if the Internet is not usable (i.e. blocked by government entities or becomes otherwise unavailable).
Ability to push either Base64 or Hex-Encoded Raw Transactions via SMS.
Send SMS transactions to PushTX through the number +32460224477 (+32460224GRS)
Electrum-GRS is Groestlcoins #1 thin-client for Windows, MacOS, Linux and Android, based on a client-server protocol. Supporting multi-sig wallets without the bloat of downloading the entire blockchain.
New Features (Universal)
Electrum Protocol: The client's "User Agent" has been changed from "3.3.6" to "electrum/3.3.6". Other libraries connecting to servers can consider not "spoofing" to be Electrum
Added CoinGecko.com fiat rate provider. Changed default provider to CoinGecko.com
Minor bugfixes and usability improvements.
New Features (Windows, MacOS, Linux)
Fix Crash during 2FA wallet creation
Fix Synchroniser so that it does not keep resubscribing to addresses of already closed wallets.
Fix removing addresses/keys from imported wallets
The logging system has been overhauled. Logs can now also optionally be written to disk, disabled by default.
Fix a bug in the synchroniser where client could get stuck. Also show the progress of history sync in the GUI.
Fix Revealer in Windows and MacOS binaries
Ledger Nano X is now recognised, supporting mainnet and testnet
KeepKey is now recognised and supports mainnet and testnet
Device was not getting detected using Windows binary
Support Firmware 6.0.0+
Implement "Seedless" mode
Coin Control in QT – Implemented freezing individual UTXOs in addition to freezing addresses
Fix CPFP – The fees already paid by the parent were not included in the calculation, so it was always overestimated.
Testnet – There is now a warning when the client is started in testnet mode as there were several reports of users getting scammed through social engineering.
CoinChooser – Performance of creating transactions has been improved significantly for larger wallets.
Importing/Sweeping WIF keys: Stricter checks
Several other minor bugfixes and usability improvements.
New Features (Android)
Fix rare crash when changing exchange rate settings
Fix bug with local transactions
Allow selecting Fiat Rate providers without historical data
Ultimate Software Verification Gude - Never get Hacked or Phished again!
Due to the amounts of scams and phishing websites and malwared softwares, I made this quick easy to understand tutorial how to verify that the Bitcoin Cash software that you use is legitimate. The core concept is that you should not rely on any 3rd party to prove the authenticity of files, not even this text, because any website can get potentially hacked so just do all the verification by yourself, as much as you can. It might be a longer work every time you update the software but it's worth it, since the alternative is being a victim of theft.
There are 3 ways to verify the authenticity of the software you download:
Verifying the authenticity of the website (EASY)
Verifying the authenticity of the software (MODERATE)
Compiling the software from source and comparing it against the downloaded authentic software (HARD)
The easy way only protects you against MITM attacks and assumes that the webmaster keeps it's website secure, doesn't have malware on it's website or the server hosting is also secure and the connection is encrypted with TLS (HTTPS protocol). This way in most cases it is safe to download from the website, but hackers sometimes go out of their way so it might not be enough if you really want to be safe.
The moderate way verifies the software independently and regardless of the website being compromized, you can be sure whether the software is genuine or not. This assumes that the developer is honest to begin with and the compiled software matched the source code deterministically.
The hard way totally proves that the software is genuine beyond the shadow of a doubt, and it's totally trustless, independent of whether the developers are honest or the website is honest itself.
Both ways assume that your computer is secure to begin with. If your OS is already compromised, then you have a much bigger problem to deal with already.
In case your IP address is specifically targeted it's advised to have a VPN connection at hand too, and do the verification both on your VPN and on your clearnet IP. I am using Firefox for this example and you should too. This method can be used to verify any website you want by cross-examining their authenticity against eachother relying on 3-4 more or less trusted authority figures. What you would do is just use 3-4 different search engines that you more or less trust: DuckDuckGo.com, startpage.com, bing.com, wikipedia.org. Open each search engine in a different tab in your browser, and enter in each one of them the software you search for, in this example "Bitcoin Cash". In the first search results you will see a link to the supposed bitcoin cash official website (on wikipedia you will just see the link at the right side of the article about bitcoin cash), click on that link from each tab and you will have the official website opened in 4 different tabs. Now the websites might look the same, but they might not be the same websites, since the connection could be hijacked so you could be on a fake website. In order to determine the authenticity of the website, click on the green lock icon in Firefox before the HTTPS mark, click on More Information, and click on View Certificate, then you will see there a SHA256 fingerprint, paste that into a text file. Now go to the other tabs you have opened the website in, and put that SHA256 fingerpring in the text file itself. Now see if all 4 of them match in the text file by pressing a CTRL+F and copying it in the search box. If they are the same, then you are very likely on the official website, assuming that all search engines remove phishing websites quickly and wikipedia is not hacked. You might also want to redo this verification from a different IP address in case you think a hacker is speficially targeting your IP address. Now just download the software from the genuine official website and you are ready to go. (Note I am not giving you the fingerprint I got from my verification so that you don't have to rely on my authority, you should do the verification yourself!)
You have to know how to use GnuPG software. I would use a Linux machine for verification since it's very easy to do it there. You can always burn a quick Live Linux DVD and boot that up to do the verification. Just watch some videos to learn how to do that, I assume you already know how to do that. Now regardless of whether the website is hacked or not, we only care about the software itself here, and if the verification is done properly, any discrepancy can be detected regardless of the website itself. A website can be far easier hacked than an offline private key used to sign softwares, so this method is much more secure. Every Bitcoin Cash software is usually signed with a GPG key. The issue here is to verify the authenticity of the key itself, once you have that, you can verify any package with that, regardless of source, assuming the developer is honest, so it's not fullproof, but good enough. Going with the example above you download the Bitcoin Cash software or Electron Cash or whatever, and you grab the software file, the GPG signature file and the GPG Public Key. Then import the GPG key gpg --import keyfilename.txt for example. The only thing you need to do is to verify the GPG Public Key itself. Let's go with Electron Cash in this example. Fyookball (the lead developer)'s official key is allegedly 0x4FD06489EFF1DDE1. We don't know if this is true or not, we can either e-mail him directly, but then who knows his e-mail could be hacked or whatnot, so we need are more extensive verification here. Each GPG key has a fingerprint which is your main point of reference, so the fingerprint you got for the downloaded key, which you can see in SeaHorse or by entering gpg --fingerprint 0x4FD06489EFF1DDE1 in a linux console after you have imported the key. You need to create a web of trust, enough reputable people vouching that this is indeed his genuine key, usually relying on people who have either met him or has extensively verified his identity. So we look the key up like in a phone address book, on the MIT server: https://pgp.mit.edu/pks/lookup?op=vindex&search=0x4FD06489EFF1DDE1 Also it's recommended to install Gnome Seahorse, a gui interface to manage GPG keys: sudo apt-get install seahorse It appears to be signed only by 2 people, I don't know them, but if you do and you have their keys too, then you can rely on their authority to confirm the authenticity of the key. If by the time you read this, the key will be signed by a trustworthy person from the broader Bitcoin Cash development team or some other well known entity, then what you would do is grab their key (and verify it) and in SeaHorse set their key to Trusted. Then automatically in Fyookball's key, the other people's signatures will show up, proving that other trusted entities who's keys you have already verified have signed this key, so on their authority you could trust Fyookball's key too. For example in Bitcoin ABC and other softwares, this is the case, unfortunately not for Electron Cash yet. So the only thing you can do is grab and verify fyookball's e-mail address, and message him and ask him his GPG key's signature. I have already done that so based on my authority his key fingerprint is: D56C 110F 4555 F371 AEEF CB25 4FD0 6489 EFF1 DDE1 The only other place that has the key referenced is Github, so you have to rely on their authority to host the genuine key and not get hacked in the process. There is only 1 electron cash repository which is a fork of the original electrum software: https://github.com/fyookball/electrum, again you could verify the authenticity of Github.com based on the previous method, but there is only 1 repository for Electron Cash so it's not hard to find it. There you can see the public keys in a separate branch: https://github.com/fyookball/keys-n-hashes It's not a lot of evidence, so I hope in the future more people will vouch for it, but for now this is all we have, for other softwares you can find a more extensive web of trust. So after you established the legitimacy of the key, just save it or write down the fingerprint on a piece of paper and put it in a safe, and from then on you can verify any new Electron Cash release against that. Simply just verify the signature file for example for the latest release: gpg --verify ElectronCash-3.2.tar.gz.sig And it should give back the fingerprint of it, if the fingerprint matches the one of your verified key, then the software is genuine. But again this relies on the assumption that fyookball is honest, which in my opinion he is, he is a trustworthy developer.
The ultimate way to verify the trustworthyness of a software is to:
Download and inspect the source code yourself
Compile the software from source
Verify the output against the downloaded package (verified by the previous step)
This is very complex, but if you want to have a fullproof guarantee that the software is genuine and untampered then this has to be done. It might be a bit paranoid but dozens of malware clients come out each day, most of them have sneaky code in them that sends out your private key like in this example:
If the developer is both shady and the source code doesn't match the binary, then you can easily get hacked and lose all your money. What you need to do to be fully secure in a fully trustless verification model is the following:
1) Do the previous step for verifying the signed package with the developer's genuine public key, all verified. So now you have an output package that is tied to the developer that is allegedly derived from the source code securely, assuming the developer is honest, and is compiling it securely. So in this case the risk is limited only developer malice or negligence. 2) Download the source code, from the main website, it should be correctly downloaded, so just download it multiple times to verify that the package was downloaded correctly. 3) Inspect the source code yourself or pay a programmer to do it. Especially watch out for the sensitive parts of the code, like the part that does the encryption and the part that does the communication. You should make sure that the private keys are never sent out. You could also use a network inspector software and test whether the private key is sent out. Now if you have verified that the source code is genuine, then assuming that Github is honest, many other developers will verify this too, so we can establish that the source code does exactly what it meant to do, with no backdoors. 4) Now you need to compile the source code and make it identical to the package you have just verified previously. Determinism is crucial, the package must match the source code 1:1. Now there may be some config files or cache files that will not but that is not an issue, the Electron Cash software is very messy so there will be a few files that will not match but usually it should. Open the README.rst file in the Electron Cash source code to see the instructions how to compile it for different OS's. By default I recommend Linux because it's easier to work on. 5) Now that you have a compiled source code folder, every single file in it should match the signed output package you have verified it earlier. Now you can write a quick code to parse through each file and check for discrepancies. You are lucky because I have already did it:
Download my script, unpack both archives in the same directory and put the script there too and make sure the root directory ElectronCash-3.2 is where the files are, sometimes it might be ElectronCash-3.2/ElectronCash-3.2 depending on how you unpack it with the archive manager. Now run the python script, and it will show you exactly which files don't match and which files are missing. Ignore the missing files, in fact just delete them from the other package where they are, since they are surplus files. The script verifies the untrusted package (the one you verified previously, yet untrusted because we don't know whether it's derived from the source yet) The missing files can't cause problem because they are just extra files put in the output package, if they don't exist in the source, then they are harmless. So just delete the missing files and you are left to deal with the corrupt files. Also do a search for .pyc extension files and delete all of those too, these are just cache files that get recompiled every time you run Electron Cash, so they can't be malware. And there are the corrupt files which are modified. Now this could be due to some discrepancies the way the compiler worked or it could be a backdoor we don't know, so we need to verify each corrupt file 1 by 1. 6) Now we need to verify each corrupt file one by one and see the discrepancy. Get diffuse, which is a simple tool to look for differences in the code: sudo apt-get install diffuse Open both of the same named files in it and check out in each pair the differences. Usually it will just be a few misc stuffs so in that case just copy 1 difference over to the other and make them identical. Do this for every corrupt file pair, and check whether any malicious code was added. After you are done run the script again and it should give out Packages are Identical! If you get that, you have now verified beyond the reasonable doubt that:
The source code is genuine and secure
The package file is certainly created by the developer and based on his reputation it's secure
Your compilation is secure
Your compilation mathes deterministically the source code
Your compilation matches the package file provided by the developer
Therefore the softare is secure and genuine and hasn't been tampered with. I have verified the ElectronCash-3.2.tar.gz file with the HARD WAY and based on my verification the SHA256 checksum da355ac3d198750e01acb8f1ada82c4d481036bee36fd9d3e2fdff972d9fc082 is genuine. But don't rely on my authority, verify it all yourself. That is the whole point of the trustless setup.
This discussion is also started on the OpenCAP discord, link is found here: https://github.com/opencap/protocol but I thought it would be good to get opinions from the reddit community as well. I would like to revisit the idea of removing the "login" endpoint and just requiring a "secret access token" for authorizing "address change" and "address delete" requests on the /v1/addresses endpoints. I know originally I advocated for the login endpoint because I thought it kept things simpler for the user. Now that I've been playing around more with the API and trying to find its limitations, I've found that the login endpoint can be restrictive for 2 reasons:
In order for it to be convenient, the app that is "logged in" must store the alias and password somewhere, which could put the users password at risk. If it is a secret key that is stored instead this is less of a problem because in the case of it being compromised, the user can just get a new key and not worry about their plain text password being compromised.
A users "account" on a given OpenCAP server may not be tied directly to one alias. They may have an account that has many or no aliases so requiring multiple logins from them seems silly. It would be easier to just manage a list of access keys.
Making this change now is still fairly easy because I believe the only developer that has even started working on front-end code for those endpoints may be Inkeliz (nanollet). I've written back-end stuff but I don't mind making changes. One of the cons to this approach is that servers, even if they don't allow users to have more than one alias will most likely need to have a login endpoint AND the secret key. It also changes the UX because now users won't be "logging in" to an OpenCAP account with an alias/password on the wallet, but will be authorizing it to make changes to an alias by pasting a secret key. I would love to hear opinions from everyone, developers and users alike! I'm not saying it WILL change or even that it SHOULD change, I just think we should really nail this down before too many apps are integrated to the protocol. This wouldn't change how wallets lookup addresses at all (which is good because more wallets like electrum and Bitcoin.com are already looking at that feature)
The World Wide Web runs on webservers in datacenters. The World Wide Blockchain should also run on "blockservers" in datacenters. The "sweet spot" of Bitcoin scaling, reliability, security & convenience is *nodes in the cloud* + *private keys offline*. The is the future of Bitcoin. Let's embrace it.
Four-Line Summary (1) Bitcoin nodes (and everyone's public addresses) should be online - in datacenters. (2) Bitcoin wallets (and your private keys) should be offline - in your pocket. (3) This architecture provides the optimal combination or "sweet spot" for short-term and long-term Bitcoin scaling, reliability, security & convenience. (4) The best communications strategy is for us to embrace the approach of "nodes-in-datacenters" a/k/a "blockservers-in-the-cloud" - instead of apologizing for it. Longer Summary (1) Bitcoin nodes should be online - on "online public blockservers", ideally running on big, powerful webservers with high connectivity & high-end specs, in datacenters.
In the early years of the World Wide Blockchain, many people - mostly hobbyists and geeks - actually ran full-nodes from their homes. But eventually, the World Wide Ledger / Blockchain will move to "blockservers" in datacenters / in the cloud.
The "sweet spot" of scaling, reliability, security & convenience for Bitcoin is: private keys offline + nodes in the cloud.
(2) Bitcoin private keys should be offline - in "offline private wallets", ideally running on tiny, cheap computers with no connectivity & low-end specs, in your pocket.
Bitcoin wallets, and their private keys, are private - they should ideally be kept permanently offline (on a tiny cheap computer with no software and ideally no hardware to connect to the internet - no Wi-Fi, no Ethernet, no 3G). This is the best way to provide the simplest and safest 100% guaranteed security.
The Bitcoin blockchain is public and should be online (on big servers in datacenters, with plenty of connectivity, RAM, CPU, and storage). This is the best way to provide the highest scalability, availability, reliability, security, and convenience.
Most of the code needed to do both of the above is already tested and deployed now, and it just needs to be combined.
For example, over 1,000 2M+ full-nodes have been launched in datacenters in the past month.
And "hierarchical deterministic (HD)" wallets like Armory and Electrum (supporting offline wallets and keys, and offline signing) are already available - along with sites where you can "broadcast" a transaction which you created and signed offline in total security, using your private keys, eg:
Full nodes in datacenters relaying big blocks for on-chain transactions would massively increase miner fees over time, while also supporting microtransactions, DACs (distributed autonomous corporations), IoT (Internet of Things), smart contracts, etc. - all using existing, tested software on the existing, tested network - with almost no changes needed.
On the other hand, Blockstream's / Adam Back's "vaporware" Lightning Network (if it ever would exist) would radically alter the Bitcoin software, network, and economic incentives. It would steal fees from miners, and it would be centralized, slow and expensive. For these reasons, it will probably never be widely adopted.
(3) We should embrace "nodes-in-datacenters" (ie, "blockservers-in-the-cloud") and "keys-in-your-pocket" as the future of Bitcoin, providing the optimal combination (or "sweet spot") of scaling, reliability, security & convenience.
Web-servers and email-servers are in datacenters, and "bitcoin-servers" ("blockchain-servers"? "block-servers") should be too. This is the inevitable path of Bitcoin growth and success, because it is the simplest and safest approach - much simpler and safer than Blockstream's / Adam Back's "Lightning Network", which will be a mess.
The best decentralization metrics for Bitcoin (volume, price, node count) will come from massive adoption by users holding keys offline in their pockets, and massive adoption by businesses and service providers, providing nodes (and "blockchain search engines") online in datacenters.
Details Bitcoin has been a success for 7 years and is continuing to grow and needs a simple and safe way to scale. So, now it is time for people to embrace nodes-in-datacenters a/k/a blockservers-in-the-cloud (plus private keys offline - to enable 100% security with "offline signing of transactions") as Bitcoin's future. Why? (1) ...because everything on the web actually works this way already - providing the optimal combination of scaling, reliability, security & convenience.
You already keep your passwords for websites and webmail on you - usually physically offline (in your head, written on a slip of paper, or maybe in an offline file, etc.)
When was the last time you ran a server out of your home to continually spider and index terabytes of data for the entire web?
Why should you need to hold 60 GB of data (and growing) when you just want to check the balance of a single Bitcoin address (eg, one of your addresses)?
Bitcoin is still very young, and if in order to fulfill its earlier promise about banking the unbanked, microtransactions, DACs (decentralized autonomous corporations), IoT (Internet of Things), smart contracts, etc., then we should hope and expect that the blockchain will someday take up terabytes, not "mere" gigabytes - just like Google's giant search engine index, which they update every few minutes.
Do you really think you should be performing this kind of heavy-duty indexing, querying and "serving" on a low-end machine behind a low-end connection in your home, when companies like Google can do it so much better?
As long as you physically control your own private keys, who cares if you rely on blockchain.info or blockexplorer.com (or someday: bitcoin.google.com or bitcoin.msn.com or bitcoin.yahoo.com) to lookup up public information about balances and transactions on Bitcoin addresses?
They're not going to be able to lie to you. The meaning of "permissionless" and "decentralized" is that anybody can set up a full-node / "blockserver" (plus "blockchain search engines"), and anybody can (and will) immediately report it to the whole world if a website like blockchain.info or blockexplorer.com (or someday: bitcoin.google.com or bitcoin.msn.com or bitcoin.yahoo.com) provides false information - which would seriously damage their business, so they'll never do it.
(2) ...because webservers and webmail don't lie to you, and "nodes-in-datacenters" (ie, "blockservers-in-the-cloud") aren't going to be able to lie to you either - since it would not be in their interest, and they would get caught if they did.
When was the last time google.com or or yahoo.com or msn.com (bing.com) lied to you when you performed a search or looked up some news?
When was the last time blockchain.info or blockexplorer.com lied to you when you checked the balance at a Bitcoin address?
Currently, with billions of websites and news sources ("webservers") running around the world in datacenters, there are "web search engines" (eg, google.com or news.google.com or msn.com or yahoo.com) where you can look up information and news on the World Wide Web. In order to survive, the business model of these "web search engines" is about getting lots of visitors, and providing you with reliable information. It's not in their best interests to lie - so they never do. These sites simply "spider" / "crawl" / "index" the entire massive web out there (every few minutes actually), and then conveniently filter / aggregate / present the results as a free service to you.
In the future, when there are 10,000 or 100,000 Bitcoin full-nodes ("blockservers") running around the world in datacenters, there will be "blockchain search engines" (eg, bitcoin.google.com or bitcoin.msn.com or bitcoin.yahoo.com - just like we already have blockchain.info and blockexplorer.com, etc.) where you will be able to lookup transactions and balances on the World Wide Blockchain. In order to survive, their business model will be about getting lots of visitors, and providing you with reliable information. It's not going to be in their best interests to lie - so they never will. These sites will simply "spider" / "crawl" / "index" the entire massive blockchain out there (every few minutes actually), and then conveniently filter / aggregate / present the results as a free service to you.
The business model for "blockchain search engines" might eventually showing ads or sponsored content along with the Bitcoin blockchain search functions which we are primarily interested in. This would be quite usable and simple and safe, and similar to how most people already use sites like google.com, yahoo.com, msn.com, etc.
(3) ...because "nodes-in-datacenters" (ie, "blockservers-in-the-cloud") provide simple scaling now.
Nodes-in-the-cloud are the only solution which can provide scaling now - using existing, tested software - by simply adjusting - or totally eliminating - the MAXBLOCKSIZE parameter.
They can use existing, tested, reliable software: thousands of 2MB+ nodes are already running.
"Nodes-in-datacenters" (ie, "blockservers-in-the-cloud") can be flexibly and easily configured to provide all the scaling needed in terms of:
Hard drive space (storage)
CPU (processing power)
The yes-men and sycophants and authoritarians and know-nothings on the censored subreddit r\bitcoin are forever fantasizing about some Rube Goldberg vaporware with a catchy name "Lightning Network" which doesn't even exist, and which (at best, if it ever does come into existence) would be doomed to be slow, centralized and expensive. LN is a non-thing.
"Hierarchical deterministic" wallets are required in order to be able to keep private keys offline, and "offline-sign" transactions. This is because a wallet needs to be "deterministic" in order to be able to generate the same sequence of random private keys in the offline wallet and the online wallet.
"Hierarchical deterministic (HD)" wallets are also required in order to allow a user to perform a single, one-time, permanent backup of their wallet - which lasts forever (since a HD wallet already deterministically "knows" the exact sequence of all the private keys which it will generate, now and in the future - unlike the antiquated wallet in Core / Blockstream's insecure, non-user-friendly Bitcoin implementation, which pre-generates keys non-deterministically in batches of 100 - so old backups of Core / Blockstream wallets could actually be missing later-generated private keys, rendering those backups useless).
Bitcoin is now over 7 years old, but Core / Blockstream has mysteriously failed to provide this simple, essential feature of HD wallets - while several other Bitcoin implementations have already provided this.
This feature is extremely simple, because it is all done entirely offline - not networking, no game theory, no non-deterministic behavior, no concurrency. The "HD wallet" functionality just needs some very basic, standard crypto and random-number libraries to generate a "seed" which determines the entire sequence of all the private keys which the wallet can generate.
Newer Bitcoin implementations (unlike Core / Blockstream) have now "modularized" their code, also separating "full-node" functionality from "wallet" functionality at the source code level:
in Golang - "btcsuite" from Conformal, providing "btcd" (node) and "btcwallet" (wallet):
[Tinfoil] The fact that Core / Blockstream has failed to provide HD and failed to clean up and modularize its messy spaghetti code - and the fact that Armory is now out of business (and both companies received millions of dollars in venture capital, and the lead dev of Armory left because the investors were creating needless obstacles regarding intellectual property rights, licensing, etc.) - these facts are suspicious because suggest that these corporations may be trying to discourage dev-friendliness, user-friendliness, security, convenience, and on-chain scaling.
(8) ...because the only thing most users really want and need is total physical control over their private keys.
Most people do not want or need to run a Bitcoin full-node, because:
A Bitcon full-node consumes lots of disk space and bandwidth, and can be expensive and complicated to set up, run, maintain, and secure.
A Bitcoin full-node requires an extremely high level of hardware and software security - which most computer users have never even attempted.
As Armory or Electrum users know, the simplest and safest way to provide 100% guaranteed security is by using "offline storage" or "cold storage" or "air gap".
In other words, ideally, you should never even let your private keys touch a device which has (or had) the hardware and/or software to go online - ie: no Wi-Fi, no 3G, and no Ethernet cable.
This offline machine is used only to generate private keys (where a Bitcoin private key is literally actually just any truly random number up to around 1078 ) - and also used to "offline-sign" transactions.
So it is simplest and safest if your private keys are on an offline machine which never can / did go online - and such as machine can be very cheap, because it really only needs to run some very basic random-number-generator and crypto libraries.
It would be simplest and safest for people to own a tiny cheap 100% secure offline computer to use only for:
generating / storing Bitcoin private keys
signing Bitcoin transactions
possibly also for generating / storing other kinds of private keys (other cryptocurrencies, GPG keys, etc.)
Four-Line Summary / Conclusion: (1) Bitcoin nodes (and everyone's public addresses) should be online - in datacenters. (2) Bitcoin wallets (and your private keys) should be offline - in your pocket. (3) This architecture provides the optimal combination or "sweet spot" for short-term and long-term Bitcoin scaling, reliability, security & convenience. (4) The best communications strategy is for us to embrace the approach of "nodes-in-datacenters" a/k/a "blockservers-in-the-cloud" - instead of apologizing for it.
Bitcoin addresses and private keys are not all that random. Please take caution.
I replied to another comment just now and thought others would be interested. I no longer let wallet programs generate address for me. They are simply not secure. Take Electrum, for example. Try to export your private keys, transform each key to its 64-char hex value, convert that to an integer, and then start a simple lookup of all 10 million values before and after your own hex value. You will find other people's used addresses. Do it to all your private keys and let it run. After a day you will start seeing the collisions. ie. Address: 15DTFio6WKG5HRHfRQNXXVhFroDbWwxJgp Private key: 5JSTpckYPqsPRxrkV3zZzVKMJFNGfVu9JWX721QXTMb5Wr82mSf Hex: 5224af20889ac590f79ca68588689d873ef60b206b33da6025ace0c90705c0b8 Int val of hex: 37154468760874988449110293609706090360941268111629659303434866284112583704760 Add and substract 100000000 to that last int, generate the private key and then address for each of those and test against a dump of all address with balances from a bitcoind. Wallets such as Electrum don't generate their private key from 1 115792089237316195423570985008687907853269984665640564039457584007913129639935. They stay within a much smaller bound somewhere in between. Pretty quickly you end with a dump like 176w5WyxEFVyzew5qSjoThoAt1ERwaqpKz 5KHSTeKtpXcaUJyz3iVAif76AHKZmzE4gqKkgnfBUmhS9GJNrt7 1GVBWqa8yU7s9JtNacVy72f6PQVdRbhaTt 5KHSTeKtpXcaUJyz3iVAif76AHKZmzE4gqKkgnfBUmkFt4TbqQt 1JiDAzNpoMX1zKBBGm5LGqp9W9cTNJbrEc 5KHSTeKtpXcaUJyz3iVAif76AHKZmzE4gqKkgnfBUmjg8AMcAA8 198Ld4Xd3Fvd9mpANheYQHhNrv19QNV7aA 5KHSTeKtpXcaUJyz3iVAif76AHKZmzE4gqKkgnfBUmjSkK5fVxX 16xaFP1PkrbE8a1phY4Tq1YTREH7Fbtq9y 5KHSTeKtpXcaUJyz3iVAif76AHKZmzE4gqKkgnfBUmjxNp2PDzY 14R4cWRLsKoKmVjqc57nCEAbACvtydExwe 5KHSTeKtpXcaUJyz3iVAif76AHKZmzE4gqKkgnfBUmiqT4FPnEm 17KdvJXmynTUsSRaf9FvGkVRCQyehrxgPh 5KHSTeKtpXcaUJyz3iVAif76AHKZmzE4gqKkgnfBUmiSXhHXrJ9 1FFgSq6nwTMRkRe33RpXa6mBhgJzr3fwY7 5KHSTeKtpXcaUJyz3iVAif76AHKZmzE4gqKkgnfBUmimdfA1Arf 14pGZ4BEewBkuTnwBeAX1Q54Voa9xV8y8B 5KHSTeKtpXcaUJyz3iVAif76AHKZmzE4gqKkgnfBUmhx4vtSWgj 14AS4r8eWtRHdHgLUb3x8FEwyvKyMKAaEu 5KHSTeKtpXcaUJyz3iVAif76AHKZmzE4gqKkgnfBUmkUWvFH5k2 and your address will be there too, along with others. That's why I generate my own addresses by hand from made up hex values that software wallets are unlikely to generate. I know the conventional wisdom around here is that there are more bitcoin addresses than atoms on our planet, but in reality that is simply not the case. We will start seeing collision faster than everyone assumes. Your addresses and private keys are not truly random and have never been that. Benford's Law applies here http://www.rexswain.com/benford.html I don't care either way. You are free to continue to use your addresses and keys as before. I'm just letting you know - they are not as safe as you are being led to believe.
[Technical] Address gap limit - a problem with Bitcoin wallets or I'm doing it wrong?
I run an app which accepts Bitcoin payments natively, meaning that I generated an xpub with my trezor and I derive that xpub in my app using Bitcore library to obtain addresses. Then, I register to a webhook on blockcypher for those addresses. I derive a new address for each new invoice. The problem is that once I create an invoice, the invoice basically is valid "forever". It doesn't really matter if it's valid only for one week (it would be minimum a few days). For each of these addresses, I subscribe to a webhook notification from blockcypher, so that my app is notified when a payment is made and can mark an order as having been paid. However, it does happen that there are sometimes 20+ orders in a row that are unpaid. In this case, although blockcypher has seen the transaction and told my app that the coins are received, and the order is marked as paid, I cannot see them in my Trezor. I've tried all wallets (mytrezor, electrum, copay, mycelium) that are compatible with trezor and all have the same issue. Essentially if I want to spend my bitcoins at this point I basically need to send microtransactions to the 19th unpaid address so that Trezor does the work to look at the next 20 addresses. I believe this is caused by the address gap which is "standard" to be 20 addresses for HD wallets. I would really like to be able to force my wallet (even if it takes much longer to sync) to look up 100+ addresses. Is there an automatic fix for this? I'm aware that there are some hacks we can build, e.g. using mybitprices.info to generate a CSV of addresses and lookup balances like that but it's what I'm doing now and trying to avoid. Thanks!
sx Bitcoin utilities (new installation instructions and information inside)
Hi! My aim with this project is to provide a set of modular Bitcoin commandline utilities, that admin types can engage with Bitcoin functionality without having to write code. By chaining all these commands together in different ways, you can do offline transactions, maintain a wallet, work with deterministic keys, ... It would be cool to see Bitcoin wallets written in bash script using these tools to handle the core functionality. I believe the more we give good tools to the community, the more we can decentralise development and increase access to the core technology for all types. Use this bash shell script to install sx: http://libbitcoin.dyne.org/install-sx.sh
Now send some funds to your address (0.01 BTC). In this example we will send the funds to 13Ft7SkreJY9D823NPm4t6D1cBqLYTJtAe.
100000 Satoshis (0.001 BTC) in total. 90000 Satoshis (0.0009 BTC) to send. 10000 Satoshis (0.0001 BTC) for the fee.
Use blockchain.info (or the history tool provided here) to lookup the output for this address. Note down the transaction hash and transaction index. Here is a screenshot of blockchain.info: http://i.imgur.com/dZvqJIV.png We can see the tx hash is: 97e06e49dfdd26c5a904670971ccf4c7fe7d9da53cb379bf9b442fc9427080b3 And there is a single output at index 1 that we want to spend (the 2nd one for 0.001 BTC). Construct the transaction:
Because there is 100000 Satoshis going in, but only 90000 Satoshis out, the remaining 10000 Satoshis (0.0001 BTC) will be taken by the Bitcoin network as a fee. This is how fees work internally in Bitcoin. 'showtx' allows inspecting of tx files.
You can use either the master_public.key or the wallet.seed for generating Bitcoin receive addresses. But you cannot use the master_public.key for generating the private keys for spending those Bitcoins.
For Electrum compatible 12 word seeds, use the mnemonic tool.
$ echo 148f0a1d77e20dbaee3ff920ca40240d | sx-mnemonic people blonde admit dart couple different truth common alas stumble time cookie $ echo "people blonde admit dart couple different truth common alas stumble time cookie" | sx-mnemonic 148f0a1d77e20dbaee3ff920ca40240d
The balance/history tools can then use a network connection to make requests against the load balancer.
It's possible to run as many backend workers as you like. The load balancer (obbalancer) will distribute requests evenly among the backends. Use worker-output.sh to view debug info from the worker. Each worker must have their own unique copy of the blockchain database. See the Obelisk config files in /uslocal/etc/obelisk/. The sx config file is stored at ~/.sx.cfg (there's an example at /uslocal/share/sx.cfg). You can change this configuration parameter using './configure --sysconfigdir=/etc/'. By configuring different workers and load balancers, you can run multiple setups on the same host. By default it is no pointing at my development server, but I will change this soon and migrate to a new host. Also I make no guarantees about stability or compatibility.
Blockonomics.co overview (quick and easy way to send hosted invoices to others)
Blockonomics.co has a couple very interesting tools I want to highlight. They just recently announced their new merchant API that web or app developers can use to integrate invoicing and payment tracking into their projects. However, here's three things that any Bitcoiner can do with Blockonomics right now:
Track your addresses or entire wallets! This is Blockonomics first and core feature. With or without registration you can plug an address or xpub seed into the home page and lookup transactions with monitoring for new transactions. In fact, by using the Wallet Watcher, you can track many seperate addresses and xpubs with email notifications when any transaction occurs (send or receive). Also included is a balance historical graph with multiple date ranges and transaction history export ability.
Have you ever wanted to send someone a request for bitcoin but didn't know how? Blockonomics makes it easy without an account! Just paste the address you want to receive with into their home page and click Create P2P Invoice. In addition to setting an amount, you can also add a text headedescription and even attach a file to the invoice. The invoice is encrypted in the browser and hosted on Blockonomics.co. All you have to do is send your payer the link to the invoice. The bitcoin amount will be calculated dynamically based on current exchange rates when the payer loads the invoice.
Want to create multiple invoices with different addresses each time? For regular use, I recommend creating an account for the Wallet Watcher and inputing an xpub seed from Mycelium, Copay, Electrum and others (preferably create a new wallet just for this purpose). xpub invoicing without an account didn't work too well in my tests, however, it is very good with an account. You can create invoices from the Receive screen within Wallet Watcher and even choose which addresses to use. Combine this with email or push notifications for a great invoicing solution, although I'd still lean toward CoinSimple for hosted, direct-to-wallet merchant invoicing.
Full tutorial for setting up a hidden service store
Hello everybody! There are a lot of vendors which reputation is very high and may be trusted for direct orders. If they do not want to rely only on third parties markets and be dependant to their downtime, death, exit scam etc. with this tutorial they will be able to easily setup a private store (and harden it a bit). Advantages:
No third parties involved
Funds are never stored on the server
A step toward decentralization
Basic server hardening
Responsibility for your server
This tutorial will guide you with the entire procedure, from buying a server to setting up Anonymart. This tutorial assumes that you will start with a freshly installed Debian 7. Other setup and software may interfere with my setup script, so if you are unsure read the source code.
Buying the server
This is probably the hardest part. You should look for a provider who accept Bitcoin and that has not strict practices on verifying customers identities. One of the best resources for finding out such providers is:
While there are some providers like vultr.com which will not ask for personal details and will not complain about tor, I'd suggest to avoid such large scale companies (especially if based in the US). For example, if we assume the scenario where everybody choose Vultr because it's the easier place to obtain a server, LE may force Vultr to monitor all instances which generate tor traffic without being a a tor node. After that they may cause some seconds of downtime each and compare the result to the availability of the store. The whole point of this tutorial is to decentralize, and you really should think always about that. On most providers you can't order via Tor with obviously fake credentials because all of them use MaxMind fraud prevention which will blacklist all orders done via Tor, VPN or anonymous proxies. First of all install proxychains on your torified system. You can install it in Tails and debian based distributions with
sudo apt-get install proxychains
(on Whonix this step is not required) Now, in order to place an order which seems legit to fraud prevention we need a clean ip from a residential connection. This is what Socks Proxies exist for so you should buy some at Vip72 (or obviously any other provider). The demo cost 3$ and you can pay with Bitcoin via Tor. After your payment has been verified you should be able to browse Socks Proxies by their Country/Region. Select one and test it via proxychains. Proxychains is useful because, as the name says, it can chain proxy, so you can connect to the specified set of proxy you want via tor. Here's the default configuration:
[ProxyList] # add proxy here ... # meanwile # defaults set to "tor" socks4 127.0.0.1 9050
Now add the selected proxy to the conf:
sudo nano /etc/proxychains.conf
[ProxyList] # add proxy here ... # meanwile # defaults set to "tor" socks4 127.0.0.1 9050 socks5
Now open a browser using proxychains:
Keep in mind that this should not be done with tor-browser because it's iser agents and other specifics are detected by the anti fraud system. If the socks proxy is working you should be able to browse the internet. If nothing loads, just get another socks and change the proxychains configuration. Now go to http://www.fakenamegenerator.com/ and get something which will match your proxy and seems to be believable. Choose your provider and try to order depending on which location you prefer and how much money you wish to spend. Keep in mind that this tutorial is aimed to full system, so if you are not ordering a dedicated server but a VPS you should select a full virtualized one (KVM, vmware, XEN-HVM). Unless you're expecting a huge load, 512MB of RAM and 10GB oh storage should be enough. Your provider will send you an email with information to access to you control panel from where you will be able to install the operating system. This tutorial is specifically for Debian 7 x64 (x86 is ok too), but if you know what you are doing you can obviously
Basic server setup
First of all you have to generate a ssh key if you already don't have one. ssh-keygen -t ecdsa With that command we are generating a 256 bits ECDSA key. If you left the dafult options you should be able to get the public key using: cat .ssh/id_ecdsa.pub Now login to your newly installed server. The panel should have generally asked you to provide a root password or sent via email a random generated one. Since here we're assuming that you are on Tails, Whonix or any othe system which force all connections trough tor. In particular, if you are on Tails, you should enable SSH keys persistence. If you continue on the tutorial skipping this part, you will loose your keys and the access to the server as soon as you shutdown your computer. ssh [email protected] Answer yes to the first question. Now the last step: git clone https://github.com/anonymart/anonymart.git /vawww/anonymart sh /vawww/anonymart/bin/full_setup.sh The installation script will update the system, remove useless packages, install the required ones, configure a nginx+php-fpm+mysql stack, configure tor, configure iptables and much more. If everything goes smoothly at the end it should tell you an onion address which will be the the url of your store and an onion address which you will use to connect via ssh to the server instead of the original ip.
Now go to your new url. You will be redirected to /settings/create where you will create the basic settings for yout store. Choose a very strong password. Bitcoin address for payments will be generated using your Electrum master key (which can't be used to spend the coins) using BIP32.
I've already coded a small script where vendors may enter their onion url signed with their GPG key. The script will look up on Grams for that GPG key and match the vendor to the url and add it to a public database. If some stores start to popup, i will make it available as a hidden service. Donations: 12xjgV2sUSMrPAeFHj3r2sgV6wSjt2QMBP
Some notes on anonymart
The original developer of anonymart has decided to abandon the project because interested in something else. I was already collaborating with him before that decision so he decided to pass to me the lead of it. I've reviewed part of the code and i haven't seen security issues, but this doesn't mean it's 100% secure. I'll do my best to review it all and add some missing features like:
Two factor authentication
Switch from blockchain.info api to lookup on Electrum stratum servers
Add the possibility to add more than one image per product
Change the order id from incremental to a random one
Add JSON api to list store products to facilitate third parties search engines
Unfortunately I'm not very familiar with laravel yet, so before messing with the code I'd need some times, so don't expect huge updates soon.
You can find your Bitcoin Cash (BCH) or Bitcoin Core (BTC) address for receiving payments into your Bitcoin.com wallet by tapping "Receive" on the bottom tool bar of your wallet. Your address will be the long string of numbers and letters directly below the QR code for that address. If the person/company is sending you BCH then select one of your Bitcoin Cash (BCH) wallets. If they are to send ... Buying crypto like Bitcoin and Ether is as easy as verifying your identity, adding a payment and clicking "Buy". Sign up for our Wallet today. Create Wallet. Trade Crypto at the Exchange. Integrated with the Blockchain Wallet, our Exchange is a one-stop shop where you can deposit funds and place trades seamlessly in minutes. Get Started . Dive Deeper. Buy Crypto. Bitcoin $ USD. Your Email ... Block Explorers provide a visually appealing and intuitive way to navigate a cryptocurrency's blockchain. Our Block Explorer launched in August 2011. It began as a way for anyone to study bitcoin transactions, along with a variety of helpful charts and statistics about activity on the network. This website is hosted by Electrum Technologies GmbH Electrum Technologies was founded by Thomas Voegtlin in 2013. Its mission is to develop, package and distribute Electrum software, and to provide services to Bitcoin users and businesses. Address Electrum Technologies GmbH Paul-Lincke-Ufer 8d 10999 Berlin - Germany Bitcoin Address Lookup Search and Alerts. View and research bitcoin ownership, transactions and balance checker by name, bitcoin address, url or keyword. Login; Signup; Report Scam; Tag An Address; Blog; BTC = $12914.95. BITCOIN ADDRESS REPORT Scam Alert: This address has been reported as fraudulent (24 times) × Watch. Please login to watch this address. Close × Add Tag * Enter Tag: Enter a ...
How to sweep private keys - Using the Electrum Bitcoin ...
Even if you lost the seed, as long as you have the correct private key, you can access your money. This is a useful resource for accessing, securely storing,... Robert Kiyosaki 2019 - The Speech That Broke The Internet!!! KEEP THEM POOR! - Duration: 10:27. MotivationHub 1,883,782 views You always dream of finding software to decrypt the private key of some Bitcoin addresses. Here you are the best private key decryption software. the bitcoin... How to Install the Genuine Electrum Bitcoin Wallet (and Avoid the "Fake" One ... Rex Kneisley 7,720 views. 27:12. How to Verify a Bitcoin address generated by Bitaddress.org - Duration: 15:51 ... How to use electrum bitcoin wallet How to use the electrum bitcoin cryptocurrency wallet, here this 30 min video will show you how to use the wallet and set ...