This is why we chose iOS as the first platform for breadwallet.
Interesting choice of words
|
|
|
Something similar already exists and it is currently active on the forums. That being said, it would be an amazing tool for forum admins if it works just like what we have here on bitcointalk.
|
|
|
This is a funny idea, but not all that useful as far as I can see... And this is definitely not the first physical Bitcoin wallet, lol. It will be something interesting to play with, I guess. you still have to trust that opendime didnt record the private keys when they created the units. i dont see the advantages over traditional physical bitcoins
They don't contain any private keys when you first get them and you can also use it offline , you are the one who should create them so It's secure enough If you ask me . IS THE PRIVATE KEY UNIQUE AND SECRET?
Yes. Opendime is delivered without any private key. You must give it entropy (random numbers) the first time you use it. Once it's gotten enough numbers, it will hash them all together and use that to pick a random number to use as the private key. At that point, the payment address is generated and set in stone.
This whole process is very easy: just copy some files into the USB drive. When it's got enough bits (250k) it will eject itself and come back with its final payment address.
You still have to place trust on how the keys are generated. We feel that we've created whole new product category: disposable hardware wallets. We're really excited to see what people will do with this. Maybe we'll see whole new economies based on Opendime spring up! That might be a real godsend in some countries that struggle with limited network infrastructure and corrupt governmental systems. At around 8$ each, excluding shipping and excluding the fact it has to be bought in packs of 3 or more, I definitely do not see this as something disposable.
|
|
|
Struggling a bit to update my Windows 10 online machine, but so far so good. Ran into some issues already addressed around here, so here's my experience so far, hope it helps people:
1. Install 0.94 2. Rename your old Armory dir and make another one 3. Boot up Armory, say yes to the agreements, deactivate auto bitcoind management 4. Close Armory 5. Start bitcoind manually, let it sync 6. When it's synced, boot up Armory and let it work. 7. Import your wallet
I got crashes on step 6 (when it finished building the database) and step 7 (after adding my watch-only wallet)
It's now scanning my transaction history.
What file should I use from the old database to recover my transaction and addresses details and comments?
|
|
|
Reading now and will probably add it. Thanks for the input, bud.
You're welcome. Since I'm at it, here's a bit more reading for you: Alex Green/Ryan Kennedy, Ferdous Bhai, Mike Chu - Mintpal References: 12Link compilationAnother messy situation... This time involving what seemed to be old partners and a legal fight between them.
|
|
|
Robert Keith Christopher Jr - CryptoRush References: 12 (This link has the word "drama" in the title, OP is going to approve that)3They handled very badly the withdrawals situation before closing, if I well remember, so they deserve a place here. And if I well remember, the person I referred to wasn't the only one responsible. Messy situation back then, and I don't quite remember everything.
|
|
|
I'd simply create the keys on an offline computer, dump them there are store them in the same place. As for encryption, PGP is an option as said, but I think I'd probably just encrypt the drive holding the keys.
|
|
|
Hi to everyone Payment were sent and you will receive the PMs soon
Thank you, 2 confirmations are already in. I see we're back on track apparently
|
|
|
Should bumps for 3/4/5 year old threads be reported? I've been seeing some posts being made on old threads like these which don't make any sense whatsoever... But there isn't really a rule for that as far as I could see.
|
|
|
Maybe they profit on ads? Or paid services...
|
|
|
This section is called Bitcoin Discussion... Also there's a place for faucets in the Micro Earnings section, although this would probably fit the Altcoin section better
|
|
|
-snip- how much RAM do you have, what are you running and what bitcoind version?
VPS #1 - 2GB, limited to the default 300MB that came with 0.12, no crashes since the update (March 1st)[1] Edit: I had constant problems with this node before upgrading to 0.12.VPS #2 - 6GB, limited to 1500 MB has not reached the limit since the last reboot (March 24th)[2] Home node - 16GB, limited to 1000 MB, barely runs long enough to fill the available memory. I think I left it running for 3 days once since the last update and it did not use more than 900MB. All given values are for memory used for TX. I dont track overal memory imprint, but whenever I check htop on the VPS's there is memory left "free" (used for caching). In fact I have trouble getting the 6GB VPS to go over 3 GB used. All run 0.12 64 bit. They VPSs are Ubuntu variants, the home node runs Win7. @knightdk could it be that you see higher memory use becasue you use test builds with additional logging? [1] http://213.165.91.169/[2] http://188.68.53.44/Thank you for your insights! How does one see how much of the mempool is filled? Can't find a command for that on the Bitcoin Core documentation. I find it odd that you see free memory on your nodes and that your 6GB one does not top 3GB... A few minutes after syncing are enough for me to see all my RAM being consumed regardless of the amount and bitcoind version.
|
|
|
Thank you very much! This is a pretty substancial update. I'll be upgrading my online machine later today. It will be nice to have a smaller database
|
|
|
You can't really compare both, as Electrum doesn't exist for iOS and breadwallet does not exist for PC. They both serve different purposes. Electrum can cover what breadwallet does, but breadwallet cannot cover what Electrum does. As far as security goes, both are equally secure, just like any other well known Bitcoin client. There are no known vulnerabilities in the ones featured on the forums/bitcoin.org. Security is as good as the user wants it to be. You can have a wallet that allows you to deploy extreme security measures and you might not be knowledgeable enough to deploy them, as an example...
|
|
|
There is only one Bitcoin Core. Core and Classic are two different clients. No one is trying to compete for names and both are proposals for a set of rules in Bitcoin. There is no "core altcoin". I don't see any confusion here
|
|
|
300Mb mempool takes bitcoind to the limit in a 4GB machine. I've seen it quit unexpectedly even in a 6GB machine, both during the "stress test" periods that happened last year. So I think we definitely cannot extrapolate, especially when the machines in question were only running Ubuntu + bitcoind (0.10 and 0.11 at the time).
That limit was only recently introduced in Bitcoin Core 0.12 so setting that in 0.10 and 0.11 nodes shouldn't work at all since it didn't even exist. I pretty sure it can be extrapolated, you just need to use 0.12 and simulate stress test conditions. A question to fellow node owners: how much RAM do you have, what are you running and what bitcoind version?
I have been running a build of the latest master branch for a while now (including when the stress tests were happening). I constantly update it. Sometimes I also have a testnet node running and occasionally a segnet (segwit test network) node running as well. I also have Armory running and when I have testnet up usually Armory Testnet is up as well. These are usually all running simultaneously and I don't see any lags or crashes at all. I use Ubuntu 15.10 with 8 Gb of RAM. All right, thanks for the feedback... I'll be testing. Sometimes it took over a week to get crashes, I'll see what can be done now with 0.12 and I'll try to get a 4 or 6GB host for this.
|
|
|
Bitcoin Core by default has a 300 Mb mempool.
That's correct, but... AFAIK running Bitcoin Core requires a machine with at least 4 Gb. I would try extrapolating from there, e.g. 600 Mb for a 8 Gb machine etc.
300Mb mempool takes bitcoind to the limit in a 4GB machine. I've seen it quit unexpectedly even in a 6GB machine, both during the "stress test" periods that happened last year. So I think we definitely cannot extrapolate, especially when the machines in question were only running Ubuntu + bitcoind (0.10 and 0.11 at the time). A question to fellow node owners: how much RAM do you have, what are you running and what bitcoind version?
|
|
|
After setting up a few nodes, on different hosts/connections and on virtual and physical machines, there's a question about setting them up that I still haven't solved: what is the correct size for a mempool given the computer's total RAM?
I've tried searching for this and I didn't find any answers or benchmarks for this, neither have I found any kind of user feedback. I've setup nodes on machines from 1 to 6GB of RAM, most of them running only basic OS services and bitcoind, and on all machines bitcoind eventually crashes without any evident reason depicted on the debug file. The client just shuts down and the logs just stop where they were... When I turn it back on sometimes it asks for a reindex, and sometimes it doesn't. I've posted a debug.log of mine on the forums a few months back and the answers I got referred the mempool, but without certainty or any real data.
I'm running some tests on a 1GB machine I currently have serving as a node and I'll report back. meanwhile, it would be nice to make a table, with user input/feedback, regarding what kind of mempool size should bitcoind be launched with.
|
|
|
Summing this thread up: Bitcoin works correctly, but it can and will improve in the future Glad to see everything solved
|
|
|
Transaction times are not ridiculous, they're instant. How are they marked high priority? Did you calculate priority yourself?
As for dice sites, most required X confirmations before crediting.
No. Blockchain.info regards them as high priority. The dice site I was using requires 1 confirmation, and even in the client (as well as blockchain.info) I was still seeing 0 confirmations. Blockchain.info seems to be quite inexact calculating priorities, so no reason to really take their word... And your inputs? Probably the issue is there.
|
|
|
|