[For reference: the idea I proposed is a special blockchain pruning method that allows nodes to verifiably query any address balance with only a couple kB download -- and the pruned data would be maintained & enforced on a second/alternate blockchain using merged mining] A quick question. Does downloading of few kilobytes imply a connection to full nodes for that or the same lightweight nodes might also happen to have this info? If network is mostly populated by nodes who are asking for those small downloads and most of the nodes don't have the data then where is it going to come from? From trusted nodes. That would apply to Electrum/Stratum architecture, but there is no such thing as a trusted node in etotheipi's proposal. |
|
|
|
[For reference: the idea I proposed is a special blockchain pruning method that allows nodes to verifiably query any address balance with only a couple kB download -- and the pruned data would be maintained & enforced on a second/alternate blockchain using merged mining] A quick question. Does downloading of few kilobytes imply a connection to full nodes for that or the same lightweight nodes might also happen to have this info? If network is mostly populated by nodes who are asking for those small downloads and most of the nodes don't have the data then where is it going to come from? |
|
|
|
Sorry for reviving a 2 month old thread but upon insight then lost bitcoins really wouldn't affect the bitcoin economy.
The lost bitcoins would be so negligible, even now it is definitely negligible.
Since bitcoins go up to 21000000 in integers, that's quite good. It also goes in the decimal places as well.
If .00000001 BTC became worth $1 in the future if it were globally adopted by many people, then you could easily revise the client to handle that in integers instead, and "move" the decimal place out.
Realistically, we can represent 2,100,000,000,000,000 units.
The amount of lost coins is probably very small, and you could just possibly add more decimal places in the future to bitcoin to accomodate rising deflation, which would make bitcoin theoretically infinite despite the "finite" 21,000,000 coins.
This is also a reason why introducing endless inflation would be such a bad idea.
I wouldn't say the amount of lost coins is going to be negligible or small over time. Just imagine 1 million Satoshi's coins (which AFAIK haven't moved yet) would be considered lost at some point. That's 5% of the whole Bitcoin economy no matter how much further you divide the units. Another half a million belongs to a dozen of other guys who jumped in early. So this problem will have to be solved in the future, but we should also take into account how and when the original Bitcoin idea was introduced into our society. Having a limited amount of coins is very easy to explain to people tired of endless and unsustainable inflation carried out by their governments. People wanted a return to the Gold Standard and having a limited amount of coins is an easy sell. So I guess it was more important to get people attracted to a whole concept of P2P currency where they essentially control the rules of money generation and then later people themselves will decide what inflation rate and policy is best for them. PS: Regarding Satoshi coins and another half-a-mil, I really believe that people who invented Bitcoin to save us from the current system will spend their millions of bitcoins for the betterment of humanity and peace on Earth  PPS: I do not support original idea of wallet heartbeats. I'd love to live in a remote village for 10 years and be sure that my coins are safe when I return back to civilization. |
|
|
|
The economy isn't broken. It doesn't need "fixing". This is exactly its intended condition. Money isn't real. Interest and debt are not real. Our whole economy has been set up to steal.
Awesome quote! For those who are wondering where it's from: http://www.youtube.com/watch?v=ELEwjVRxxGEat 2:53 but better watch the whole thing, it's precious! By the way those guys accept bitcoin donations at: http://thejuicemedia.com/donate/ |
|
|
|
RE: why would you want a bitcoincard versus just using your cellphone: I personally think you'll want both; I'm trying to convince them that the bitcoincard could be a perfect "second device" for multisignature transactions. Cell phone viruses and trojans and malware will be the next big wave of security vulnerabilities.
Now, this would make me buy one. Yes, I'd be all over that. Something small enough to keep in my wallet, so that it's typically on my person that I can use for multisig with my phone or, say, an untrusted computer or something. I don't think it would be simple to implement. As I understood the radio technology used in the card is different from wireless technologies used in phones so they won't be able to communicate. Also the card can only store two Bitcoin addresses and two private keys at the moment. So either it would need to share one of those for multisig or drop this functionality all together. Edit: it seems that I confused the limit of two inputs and two outputs per transaction with the limit on private keys. More info is here: http://bitcoincard.org/product.php |
|
|
|
I like the idea about merged-mined second chain since its optional and non-disruptive. I think you should go for it etotheipi! It will be your answer to a competing Electrum/Startum client-server approach. You have a large group of followers with Armory, so adoption shouldn't be a problem. At some point in time Armory would need to get rid of bitcoind dependency for networking. That would be the right time to introduce the concept! PS: I recently started using Armory for off-line transactions and I love it |
|
|
|
|
Since you mistyped it twice it's unlikely that you made the same mistake.
I would check the version with inversed capitalization in case you had CapsLock On and didn't notice.
Or if you have multiple languages on your computer try changing the language.
|
|
|
|
What would you do with identical tweens, provided that one of them went rogue? Also fake mustaches and wig might be hard to recognize in a video chat. Just check out The Juice Media | Rap News ( http://thejuicemedia.com/) it's all one guy most of the time! By the way they accept donations in Bitcoin |
|
|
|
Is there any way to restore the wallet from a seed in Armory?
It claims to have deterministic wallets, but I couldn't find an option to restore.
Wallets -> Restore from Paper Backup Ok I somehow missed that, is there a way to get the seed without a printer and physical paper? |
|
|
|
|
Is there any way to restore the wallet from a seed in Armory?
It claims to have deterministic wallets, but I couldn't find an option to restore.
I'm looking for a brain-only cold-storage wallet solution.
Is there a plan to add this functionality to Armory?
|
|
|
|
Yes it creates the wallet file that way, but if you then type: electrum addresses -ak it won't print any, that's the problem for me. I already asked Thomas about the fix and he said it should be possible, so no worries. PS: I'm using Ubuntu 10.10 Live CD with Wi-Fi device turned off (physically) |
|
|
|
use the -o (offline) option when working with wallets on a non-networked computer.
You can create more than 5 addresses by editing the code, but you have to remember to do that same count when/if you restore in the future. I believe the actual line/file you need to change is documented earlier in this thread.
Line 257 in wallet.py:
self.gap_limit = 5 # configuration
Or, new receive addresses get automatically created by the client as you use the existing ones. Thanks for you comments guys, first -o option doesn't seem to affect the generation of addresses/private keys, they are not created in offline mode. Second I haven't tried it but I thought that gap_limit was the amount of addresses that could be imported without breaking the sequence, not the overall amount of addresses. Is that correct? |
|
|
|
Ok I see, so it only needs to know how many addresses were used.
I would definitely prefer an option to restore the full wallet without the network.
If it's a brain-only cold-storage wallet there shouldn't be any problems remembering the amount of addresses. I could easily specify that number during restore process, and if there is more it will generate them when connected to the server. Is this possible to support?
Regarding the source code, I still think it's easier to find an old client than try to mess with a server code just to restore the wallet.
yes it would be possible to support that. Great! Will be looking forward to it. So basically client needs to ask how many addresses to pre-generate (5 as default seems reasonable) when creating/restoring a wallet. |
|
|
|
... If we assume that each book contains on average 10000 sentences (a very generous estimate), we get around 10^15 sentences to test. In contrast, a random seed with 128 bits of entropy yield 3.4x10^38 combinations. Do you understand the difference between those numbers? So if we take two books instead of one and 4 numbers instead of 2 which is still reasonable to remember and concatenate the two sentences we will be approaching 10^15 * 10^15 = 10^30 which is more like it. Add some magic to the process and some secret tricks and you are good to go! Ok maybe it was easier to just remember the 12 words |
|
|
|
without network connection, there is no way to know how many addresses need to be restored. of course we could generate a fixed number of them, but that solution is probably worse than the problem it tries to solve... note that if you wake up years from now and the Electrum network is no longer there, I believe the source code will still be available. it is difficult to remove such things from the internet. Ok I see, so it only needs to know how many addresses were used. I would definitely prefer an option to restore the full wallet without the network. If it's a brain-only cold-storage wallet there shouldn't be any problems remembering the amount of addresses. I could easily specify that number during restore process, and if there is more it will generate them when connected to the server. Is this possible to support? Regarding the source code, I still think it's easier to find an old client than try to mess with a server code just to restore the wallet. |
|
|
|
I've been playing with offline mode and I have a question. When I restore/create wallet offline the client doesn't generate the addresses and private keys until I connect to the server. Is it a design decision or just a bug? My concern is that if I wake up two years from now with my perfectly remembered seed and for some reason Electrum infrastructure is not around (unlikely but theoretically possible), then how do I restore my private keys? I can keep the current client on a USB stick but that doesn't seem to be enough. Also how do I generate a new address (besides 5+1 originally created)? PS: Regarding seeds from sentences in the book, I agree it's not entirely safe but you can always salt it with your favorite pet's name and your mother's birthday Ok just kidding, never use books! |
|
|
|
Not sure if it was discussed here or not, but I think the easiest way to memorize your seed is to: 1) Pick up your favorite book 2) Remember the page number 3) Remember the number of the sentence from the top of the page 4) Compute md5 of that sentence and you got your seed!!! So it comes down to remembering just two numbers and your favorite book instead of twelve random words. I've just discovered Electrum for myself and I think it's awesome!!! I'm gonna test offline transactions tomorrow. Also this wiki page: https://en.bitcoin.it/wiki/Electrumseems to suggest that "restore" command requires network connection while "create" doesn't. They both seem identical to me with respect to network connection as one command generates random seed and another one takes it from the user. Both commands shouldn't require network connection IMHO. |
|
|
|
|
Do you have any idea why ABCpool is not on the hashrate chart on bitcoincharts.com?
At >700 Ghs it should be there somewhere in the middle.
|
|
|
|
I think a better approach for coins redistribution would be to create thresholds for three classes of accounts:
1) spam/dust account x < 0.5 mc
2) low income account 0.5 < x < 10000 mc
3) high income account x > 10000 mc
Then the rules would be the following:
- spam/dust accounts gravitate to zero over time (decay with fees)
- low income accounts gravitate towards middle threshold 10000 mc (grow with interest)
- high income accounts gravitate towards middle threshold 10000 mc (decay with fees)
EDIT: plus add the rule that if any account hasn't been spent from for a period of time,
the interest (if any) drops to zero, the fees start to apply (if haven't before).
This will allow dead accounts no matter of which class to eventually decay to zero.
Just my two cents.
Why exactly must people lose their money for participating in the currency? Nobody has articulated that need to my satisfaction. I agree with you, no need to lose money and we already have bitcoin for that. Actually what I just described wouldn't work as people would just start splitting their accounts as they get to the middle threshold and above. |
|
|
|
|
Show Posts
