So the network itself is definitely not a problem. Could be a permissions problem?
I don't think it is permissions. I think it has to do with how cifs does file sharing, although, again, I'm not sure. I'll open an issue on github since I have also had this problem before. |
|
|
|
In theory, there should be no way for the Bitcoin software to distinguish between a local and a network drive. That's why I do not see why it should not work.
In theory, yes. In practice, the software implementation may be doing something which differs from a local drive and causes Bitcoin Core to react in unexpected ways. Is there a way to have a more precise error message saying what is wrong?
Those error messages are in the debug.log. Can you post that here so that we can see what the errors are? IIRC, though, the error messages for this are not all to helpful. Is this the right place to ask support for that software?
No. The developers do not use these forms anymore. The proper place to report bugs and issues is on the github issue tracker at https://github.com/bitcoin/bitcoin/issues |
|
|
|
|
Are you sure that you checked all of the addresses? What armory version are you using?
|
|
|
|
Hi guys..i was just wondering is it possible to make some bitcoins by reffering others to btc gambling and faucet sites.if so can anyone tell me what is the best way to get refferals and which site is best for getting some btc that way..thanks
It is possible, but you are not allowed to post any referral links here on Bitcointalk (you can have them in your signature). You will need to find somewhere with a high enough traffic to post your ref links. |
|
|
|
Is there any way to download old versions of Armory? I'm looking for the 0.92.3 offline bundle for Ubuntu 12.04 but unfortunately can't find this anywhere. Thanks for any hints.
The oldest ones are 0.93.3. If you want older, you will need to build it yourself. But why do you want old software? |
|
|
|
Why aren't network drivers ok?  I haven't fully investigated it yet, so I don't know why. But after some experimentation, I do know that network drives do not work. |
|
|
|
Why do they cause problems, may you elaborate on that, please
That level of divisibility makes user usability problems. It allows for dust outputs and low fees. A dust output is an output with a value less than 2730 satoshis. This can be a problem when sending transactions, especially with poorly written software which do not take into account dust outputs. With low fees, satoshis allow for very small fees which can be problematic with getting transactions confirmed quickly. |
|
|
|
So is it kind of anticipated that one day we will shift the decimal point?
Perhaps, it all depends on the value of Bitcoin. The value of Bitcoin would have to go up significantly. Even today we don't need satoshis. They are simply too small and actually cause problems. |
|
|
|
Hello
In a tx output you specify how many satoshis you assign to it. This is a 8 byte value so the maximum amount of satoshis you could transfer theoretically would be 2^8*8 = 1.84e19 = 1.84e11 Bitcoins.
However, this wastes 4 !! digits as in practical terms the maximum amount of bitcoins can never exceed 2.1e7 bitcoins.
So actually it would make more sense if one satoshi was 1e-12 bitcoins instead of only 1e-8.
What do you think about it?
regards
We don't need that level of division yet. |
|
|
|
Hi there!
I have installed the Bitcoin client for Linux (bitcoin-qt).
I have started it, and it started synchronizing blocks. After a while, my disk got full.
I have then moved the ~/.bitcoin/blocks and ~/.bitcoin/chainstate to a different partition and created symlinks. The client started again and downloaded blocks for some hours, then also that partition got full.
I have a NAS mounted via cifs (smbfs) with huge disk space. If I move the blocks and chainstate folders there and symlink them, exactly in the same way i did with the other partition, I get an error opening blocks database. It asks me if I want to rebuild it. If I answer yes, it then says the same error again and exits.
Any ideas?
Thank you
I'm pretty sure that is a problem with cifs since I have done this before and it has failed. You should really only be doing it with locally connected drives. |
|
|
|
The HDD is fine - I use it for several tasks - never had any Problems.
I reindexed 4 times in the past 6 Weeks and the problem came back 2-3 days later.
The HDD is encrypted - I reindex - after that the wallet syncs and works fine.
Then I close the wallet and unmount the external HDD.
I mount it again and open the wallet again - and I will get the database error again.
But that's exactely how I did it before - and before it worked fine for 2-3 years.
Honestly, then, I'm not sure what is wrong. You should open a issue on the github: https://github.com/bitcoin/bitcoin/issues. Or if you don't want, I can do it for you. You will need to include the debug.log and mention that you are using an encrypted external hard drive. Also, software changes over time so newer versions may not behave the same way as a version from 2 or 3 years ago. Maybe I try to delete the whole Wallet and reinstall it and just download the blockchain again.
Do I need to save anything else than the wallet.dat file ?
Yes, you just need the wallet.dat. You can try to do that, and if it doesn't help, then open a issue. |
|
|
|
|
This is interesting. You will have to reindex again. However, since this has occurred multiple times, you might actual have hardware errors. I would suggest that you run some diagnostics on your hard drive and see if there are any problems.
|
|
|
|
Ah, I recap just to make sure I understand correctly:
Every node has a local database where it indexes all unspent tx, correct?
greets
yes. |
|
|
|
|
It depends on the software implementation. A poorly written software will crawl though the entire blockchain and that will waste time and energy. Well written software keep their own databases of every single Unspent Transaction Output. This is much smaller and easier to search through. Once a UTXO is spent, it is removed from this database. This database is built from scanning all of the blocks as it receives them and updating this database when transactions are confirmed.
|
|
|
|
what I don't get is that if you receive 2 BTC and then 3 BTC on 2 different transactions, They won't merge into 5 BTC but will remain as 2 separate value in your wallet. (as explained here : http://bitcoinfees.com/) However, when I send 5 BTC and choose to send those 2 separate amounts (2BTC and 3 BTC) via a single transaction, THEN they will merge as a single amount of 5 BTC in the receiving wallet. is that right? The separate 2 and 3 BTC amounts would be combined when sent normally, but it is possible to do it differently, as Shorena pointed out. when odolvlobo says "The separate 2 and 3 BTC amounts would be combined when sent normally" does it mean that the 2 BTC and the 3 BTC sent together as 5 BTC will reach an other wallet as a single entity (5 BTC entity). right or not? Yes, if you create a transaction which spends from those two outputs to a single output, that output can have a value of at most 5 BTC. |
|
|
|
thanks.
if I understand well what knightdk said, blockchain can not grow more than 144 Mb a day as 144 blocks of 1 MB are generated per day as a maximum. is that right?
Howerver, if block size increases (as a decision of the miners) or if number of blocks generated per day increases (don't know if this is possible), blockchain can grow at a higher rate. is that right?
Yes and yes. |
|
|
|
The difficulty is adjusted every 2016 blocks. The formula for adjusting difficulty requires looking at the total amount of time that it took for those 2016 blocks to be solved. If it is more than 20160 minutes, then it took too long and difficulty is too hard. If it is less than 20160 minutes, then it didn't take long enough and difficulty is too easy. The current difficulty is adjusted by the exact same proportion as the amount of time that the 20160 minutes was missed by. So if the 2016 blocks were solved in 10080 minutes, they came twice as fast as they should, and the target is cut in half (difficulty is doubled). If the 2016 blocks were solved in 22176 minutes, then they came 10% too slow, and the target is increased by 10% (difficulty is reduced by 10%).
To be specific, the calculation is defined here: https://github.com/bitcoin/bitcoin/blob/20f9ecd343bbd305f0aeb829f42e61edea8de62f/src/pow.cpp#L52It is: (bits of previous retarget period)*(time in seconds of the retarget period)/(time in seconds of the intended target period). The result is converted to hex and then encoded as described here: https://bitcoin.org/en/developer-reference#target-nbits |
|
|
|
But if a username of trusted user is already taken,how can other impersonate him?if it is an hacked account,this warning will not be shown because it is displayed only when newbies send message They can register with a similar looking username but has one character changed. It will look like the actual user but not actually be that user. |
|
|
|
2016-04-29 00:19:35 Bitcoin version v0.9.2.1-g354c0f3-beta (Thu, 19 Jun 2014 09:51:15 +0200)
Well you are using a pretty old version. I suggest that you upgrade to the latest, 0.12.1 Otherwise, it seems like there isn't any problem, you just have to wait a while for it to finish loading. |
|
|
|
|
When you get to the output section, instead of doing "address":amount, do "data":"hex" where data is the word 'data' and hex is the hex of whatever data you want to encode. You will get up to 80 bytes of data.
|
|
|
|
|
Show Posts
