the average joe is not going to want such a volatile ass income. It's not volatile income - it's volatile savings. There's a big difference between the two, although people who live paycheck-to-paycheck might not know what savings are and so might not recognize the difference. If a person who is paid regularly in bitcoin buys as much local currency as they'll need before their next paycheck on the same day they get paid and saves the rest, they are not affected by short term volatility. |
|
|
|
I would recommend using bitreserve.org where you can hold your bitcoin in dollars or pounds so you are protected against volatility your money would stay the same in $ or £ but its on the bitcoin network.
Of course this is a lie. When you give your bitcoins to somebody else, they sell them on the market and hold $ or £. When you want your money returned, they buy back the $ or £ value at current market prices and give them back to you. Giving your bitcoins to somebody else to hold on for you "protected against volatility" is loaning your coins to short sellers, except in this case you generally pay them for the privilege of borrowing your coins to short with instead of getting paid interest. |
|
|
|
aa5db7de00ec7876173bdbabe559deb297c3034d doesn't build: g++ -Icryptopp -Imdb -DUSE_CRYPTOPP -D__STDC_LIMIT_MACROS -I/usr/include/python2.7 -I/usr/include/python2.7 -std=c++11 -O2 -pipe -fPIC -c UniversalTimer.cpp
g++ -Icryptopp -Imdb -DUSE_CRYPTOPP -D__STDC_LIMIT_MACROS -I/usr/include/python2.7 -I/usr/include/python2.7 -std=c++11 -O2 -pipe -fPIC -c BinaryData.cpp
g++ -Icryptopp -Imdb -DUSE_CRYPTOPP -D__STDC_LIMIT_MACROS -I/usr/include/python2.7 -I/usr/include/python2.7 -std=c++11 -O2 -pipe -fPIC -c lmdb_wrapper.cpp
g++ -Icryptopp -Imdb -DUSE_CRYPTOPP -D__STDC_LIMIT_MACROS -I/usr/include/python2.7 -I/usr/include/python2.7 -std=c++11 -O2 -pipe -fPIC -c StoredBlockObj.cpp
g++ -Icryptopp -Imdb -DUSE_CRYPTOPP -D__STDC_LIMIT_MACROS -I/usr/include/python2.7 -I/usr/include/python2.7 -std=c++11 -O2 -pipe -fPIC -c BtcUtils.cpp
g++ -Icryptopp -Imdb -DUSE_CRYPTOPP -D__STDC_LIMIT_MACROS -I/usr/include/python2.7 -I/usr/include/python2.7 -std=c++11 -O2 -pipe -fPIC -c BlockObj.cpp
g++ -Icryptopp -Imdb -DUSE_CRYPTOPP -D__STDC_LIMIT_MACROS -I/usr/include/python2.7 -I/usr/include/python2.7 -std=c++11 -O2 -pipe -fPIC -c BlockUtils.cpp
g++ -Icryptopp -Imdb -DUSE_CRYPTOPP -D__STDC_LIMIT_MACROS -I/usr/include/python2.7 -I/usr/include/python2.7 -std=c++11 -O2 -pipe -fPIC -c EncryptionUtils.cpp
g++ -Icryptopp -Imdb -DUSE_CRYPTOPP -D__STDC_LIMIT_MACROS -I/usr/include/python2.7 -I/usr/include/python2.7 -std=c++11 -O2 -pipe -fPIC -c BtcWallet.cpp
In file included from BtcWallet.cpp:11:0:
BlockDataViewer.h:112:9: error: extra qualification ‘BlockDataViewer::’ on member ‘registerAddressBatch’ [-fpermissive]
void BlockDataViewer::registerAddressBatch(
^
Makefile:87: recipe for target 'BtcWallet.o' failed
make[1]: *** [BtcWallet.o] Error 1
make[1]: Leaving directory '/home/justus/src/BitcoinArmory/cppForSwig'
Makefile:9: recipe for target 'all' failed
make: *** [all] Error 2 |
|
|
|
|
Nice to see this thread merits the attention of the professional trolls.
Cypherdoc must be doing something right.
|
|
|
|
What is the status of the btcd wallet? We're quite happy with btcd as a node, but haven't gathered experience with btcd's wallet yet. Is it ready for production? Or, let's rephrase this: is someone using it for production purposes already?
Monetas has two full-time programmers developing new features for btcwallet so that it can be used in production in our system, but that's just because we need features that don't exist in any wallet yet. As far as I know, it work fine as traditional wallet. |
|
|
|
|
Armory's startup time is lower than I can ever remember it being before.
|
|
|
|
|
For this to really happen the network protocol needs to allow for 256 bit peer addresses.
|
|
|
|
|
Gresham's Law is statement about the effects of legal tender laws - not a statement referring to any kind of intrinsic property of money.
|
|
|
|
Yeah, what a piece of shit, I hope he chokes on a Gyro and I hope Greece goes down in flames. Greece doesn't have the balls work ethic that Iceland or Switzerland have. They will sell out their people and lands elect more corrupt socialists and demand more free shit funded by wealth confiscation. There, I fixed it for you. Median age in Greece is over 43 years old. Every young person with any kind of talent or ability has fled. It's a country full of ageing people who are desperately trying to believe that when they get too old to work they'll be able to pay the younger generation that doesn't exist to take care of them with the money they won't have. |
|
|
|
Let's go Lunar!  Wow, the market really responded well to our Bitcoin Meetup tonight in Austin. Since they price moved up during our meetup, I'm just going to assume that correlation=causation in this case. |
|
|
|
Issue should be fixed now, feel free to pull 0.93-bugfix and give it a spin. As usual, wipe your existing DB beforehand
0.93-bugfix now works for me. |
|
|
|
I currently suspect it is some sort of blind spot in the code in regards to out of order data in blk files. This is something I have not worked with at all, I simply trusted the unit tests we have for it, and now I realize it is the one factor I have never tested my code against. I would definitely withhold all other suspicions until I have scanned a 0.10 mainnet chain. I didn't realize you had not tested against this yet. That sounds to me to be the mostly likely possibility. As for your wallets, how many addresses do they contain in total? More like 1k, 10k or 100k+?
10 3 |
|
|
|
|
Still can't successfully index the blockchain.
Using this morning's version of the 0.93_bugfix branch, and Bitcoin Core 0.10.0_rc3 (this time, bootstrapped from the most current bootstrap.dat instead of purely from the network) I get to block 323413 before it throws an error.
Is it possible for the contents of a wallet to interfere with a blockchain scan?
The reason I ask is because I did get Armory to scan the blockchain successfully once, before the HDD_optimization branch was merged, with just one wallet.
After the sync, I imported several more wallets and the rescan time was reported at 2 weeks. During several attempts at a complete rescan, and switching to the HDD_optimization branch and then back to the 0.93_bugfix branch, I've been unable to get a complete index of the blockchain.
Maybe one or more of my wallets is triggering a bug?
|
|
|
|
Ok, I'll try it out
Thanks, much appreciated It does fail at block 161352 every time.
Thanks for the block upload. Unfortunately I am unable to reproduce your issue. With the 24 block files you provided, I scanned up to block 197431. Can you try 0.93-bugfix and let me know if the issue reappears? Also please make sure to delete existing DB files first. Somewhere between when I first reported this and yesterday, that branch stopped failing at block 161352 and started failing at block 221346 instead. I'm currently re-bootstrapping Bitcoin Core from a bootstrap.dat file (previous instance was bootstrapped using the new headers-first process) to see if that makes a difference. |
|
|
|
Could you send me your first 14-15 block files? (I expect your first 165xxx blocks to be covered by that few files)
What's the best way to transfer files of that size? |
|
|
|
|
On the plus side, the scanning process is very fast (until it stops unexpectedly).
|
|
|
|
That block is present: $ bitcoin-cli getblockhash 161352
00000000000001b06ca92a86d168d11525dd6868690ad601cf453582750d6d5b
$ bitcoin-cli getblock 00000000000001b06ca92a86d168d11525dd6868690ad601cf453582750d6d5b
{
"hash" : "00000000000001b06ca92a86d168d11525dd6868690ad601cf453582750d6d5b",
"confirmations" : 178563,
"size" : 10274,
"height" : 161352,
"version" : 1,
"merkleroot" : "71fc1f32d7c40333872800801270fc6119e66a8e2eb3ac1e117b016378c3bd6c",
"tx" : [
"750f6786dd6b197341873956a1c2f72eac5885dea39f888def891158a4be83fe",
"ef3ba9761f838db8f891c38a12e8cf918252439fe9dc6cc098554607f98a060f",
"430483c55f60afd74f97f33d047f23e823f140eae3767ff91a70979bb3f7d563",
"fdfced841e0a38b7bdb4a14785d0f0bbe6c0c274d1fc3f9096d12fa1c140a91a",
"de26dcfe7ce13ccdafeb2efb434db4ef9176c1e48705bca07e26dab262a9b6eb",
"60e1b38b550a9671de2304e05d88d0c867d02e7a8b83e3a5ee89e4eaed969b2e",
"bd8b0c3c3bee955218f59c103a37f946b77e48d7858b4c6140c23ded0548264e",
"e0eb0fe4b6db08764b481875d70b2657a31903e222f85a70a3ce043a825b601f",
"75573387681c7c094f6d5e2c7dd27c4d685e44d630a462eb4661e803c234d553",
"087ef5a0cada7e423b7ce95913bdf03aac1ce027bfb227d019cf74c87dc9df75",
"9eb4a039e2483cc9691be9fa24c9afd5d63049d4b71616f5b37de962197ec519",
"155ad81aee29d314b5d29f65b5898ed6130cc2e178338c2c473b6552f9f5752f",
"6fffac9877c666422641a2c9d13ecbb620c48a774de113c003dfcdff5bded9fe",
"1479889653b4bb7ae2eb03ac74264e305a986e5b50459dcbebe2f948e82962b5",
"f8d68d38e71f0ac8babedc9768cbb9a3606cee380470e17c2d9911c5378877ef",
"a89e10073dacc27f437903ec299a8fe02b4cfd3f853cfa68035379efccd99cfe",
"6360d4a266a270280d8b4e768de8655816c34ab6705cb2a5be67b7e232009659",
"880f9b2da2aa155f0ad7c19d349292c29474e88361d7645cd771bfc34d758bc2",
"386fb9f2480a0074487b091236edd56a7a17dca6c902cbc5abc180bdd002e535",
"1f6bd7f7b3eeb0504e09f18bd1e83ea1ac9e847f8bb54991bf6f7e70f4e418c9"
],
"time" : 1326086768,
"nonce" : 148885393,
"bits" : "1a0d69d7",
"difficulty" : 1250757.73927466,
"chainwork" : "00000000000000000000000000000000000000000000000b2ce69723a41929b7",
"previousblockhash" : "00000000000004754688e78ddfd1caa9ccbd3750dbc28389efc4bbc4496197ae",
"nextblockhash" : "0000000000000774676c1436f6fe5626273c98d841f9328ed069bdc4fe829d90"
}
|
|
|
|
|
Show Posts
