|
Silverwallet Current Account: Our most popular account is for customers wishing to retain the greatest flexibility in the management of their silver balances. Buy and sell at the lowest fees. Want to switch between silver and Bitcoin without cashing out? Should be possible before summer!
|
|
|
|
|
Actual physical silver is scarce - only a few grams per person exist in the world. Most "silver" investment opportunities offer a way to speculate on the price of silver, but hold little or no actual physical silver. Silvervault stores the silver balance of each customer in our own full-security bank vault, in the form of international standard coins. You may take delivery of your silver any time. Since 2010, we have provided our services to 800 private and corporate clients, and the vault currently contains about 3 500 kilograms of silver belonging to our customers.
|
|
|
|
|
'Silvervault Deep Storage: Are you a long-term investor? We have good news for you. The new Silvervault Deep Storage sets the standard for a low-fee long-term silver storage'
Can I suggest:
Silvervault Deep Storage: Are you a long-term investor? We have good news for you. Silvervault Deep Storage sets the standard for low-fee, long-term storage of silver
|
|
|
|
|
'Start saving for retairement' - retirement
|
|
|
|
Seems to be missing 'Bitcoin accepted here'  |
|
|
|
|
It still seems to me that the suggestion of adding a mechanism to alert miners and merchants of any branches over a certain size would solve this problem?
|
|
|
|
|
Ah right, that makes sense. So rather than being cancelled they go back into the pool of unconfirmed transactions. From there, any conflict will naturally be resolved, because double spends from 0.8 chain already appear in the 0.7 chain and therefore get rejected. Thanks for the insight.
|
|
|
|
|
Okay, so how does the merge work exactly? Do all transactions get accepted apart from double spends, where any conflict on the 0.8 chain get rejected?
|
|
|
|
My understanding is from a pre-0.8 chain point of view, this case had a 0-confirm transaction that was in the network for some time
If anyone can provide insight here I'd appreciate it.
Yes, that's basically what happened. The problem arose because the 0.8 miners viewed this block as valid, accepted it, and continued the chain from there. This created a fork with two competing parallel chains, until the 0.8 miners reverted to 0.7 and effectively cancelled all transactions on the 0.8 chain after that block. |
|
|
|
Basically, having to wait for 6 confirmations is already long enough to barely make it useable, and it turns out this is not (always) enough and it could fail due to a simple bug. Call it FUD if you like, but this is bad news, no matter how you spin it.
The way I see it, if the transaction is large enough to make it worth attempting a double spend, then the parties involved ought to be willing to wait for the full 6 confirmations in the interest of security. For smaller transactions, it would not be worth attempting a double spend due to the low success rate and the time and effort required. Also: In fact, you could easily implement a fork-detection system: whenever a fork(i.e., two branches with more than one block) is detected, wait for more confirmations until one branch stops growing, this is not something requires protocol overhauling or even client reprogramming.
|
|
|
|
|
No reason not to I guess, it just seemed uneccessary. I was wondering if there's a specific reason?
|
|
|
|
Why is this post signed?  |
|
|
|
|
I *think* that they're still safe, even in the event of a hard fork. If this were to happen, your coins would still be 'valid' on whichever chain survives the hard fork, as long as you upgraded to using whichever version of the protocol becomes widely accepted. I might be wrong but in the event of a hard fork where both chains survive, I think you'd be able to spend the coins once on each branch of the fork?
If my understanding is correct (I'm still learning too...)
|
|
|
|
|
As well as signing messages, PGP is also used to encrypt messages containing confidential information. You can safely send a private message to someone encrypted using their public key, and not have to worry about it being intercepted at any point. Only the owner of the private key can decrypt the message to reveal its contents.
|
|
|
|
I think most people's greatest fear is the governments/established organizations' retaliation.
This was my main fear for a while until I read a post (I forget which one exactly) suggesting the following: Assume that Bitcoin has the massive potential that we'd all hope for. Which government will want to be the first to try and implement some sort of ban? It could prove to be massively detrimental to that particular country in the event that Bitcoin survives (which it probably would). Whichever country implemented a ban would have deterred adoption amongst its own citizens and therefore missed out on the potentially massive growth of the Bitcoin economy as a whole. I'd be interested to hear other peoples thoughts. |
|
|
|
|
Just found this thread because I was wondering what will happen in the future if (when) the user base is many times greater. Will we reach a point where it's no longer feasible for the average user to run a complete node? If so, being able to run the watching only copy of an armory wallet using a light client would seem to be the solution?
|
|
|
|
And this is not changing until bitcoin economy is self contained - i.e., there are iron mines accepting bitcoins in exchange for ore, smelters working for coin, and all the way up to warehouses which have prices set in bitcoin.
This will take a very long time to achieve, if ever. Much longer than most speculators here are willing to wait - ten years at the very least. Until then, bitcoin will be slowly growing in price, because once bitcoin economy is self-contained, it will quickly suck in all other economies (due to its obvious superiority), and so coin value should be up to the task.
If this happens in the next ten years I'll be laughing the whole way there |
|
|
|
|
Show Posts
