watching
|
|
|
... anybody here read the latest by Neal Stephenson .... REAMDE MMORPG game currency and economy is a central theme ... crypto, gold, etc. Lots of ideas in there. http://en.wikipedia.org/wiki/Reamde
|
|
|
There are the winners .......
and then there are the Losers.
Edit: slush I'm happy to send you back the 2 btc if you think someone can find a better name.
|
|
|
I'm not sure if the name should have anything to do with "electrum." At first I thought it should, but this proposal could be implemented by any exit node for thin clients.
It is unavoidably related anyway by the technical task being performed, thin-client/bitcoin-server federation. Fortunately, they happen to share the same suffix, um. It could be nice to have any other thin clients identify with Stratum in a similar manner and hat-tip to the founding idea of Electrum, that now becomes the special case of the wider family, but it is not necessary, eg. Aurum, Hum, Drum, Plum, Rum, etc. Also related layers can easily be identified superstratum, substratum, etc. Slush : PM coming your way Hope you have fun with your new layer, Stratum. I wonder how much overlap there might be here with the OpenTransactions client-server federation crypto-currency transaction s/ware that is already built?
|
|
|
Stratum (new layer) or if it really is an unneccessary layer, "Administratum" Edit: also reserving some stratum derivatives Superstratum (in latin literally overlay or 'the layer above/over /'on top of') Suprastratum
|
|
|
Happy Christmas!
|
|
|
Can you confirm if the following is correct?
The imported keys are not contained among the deterministic key set generated so if/when you delete your wallet the imported keys will not be coming back when you use the seed-phrase to regenerate the deterministic portion of the wallet.
that is correct. perhaps I should add a big fat warning during the import command? in any case, I think that this command should not be available from the gui, in order to make sure that it is not used too easily. Thanks. A big, fat warning would be good. I knew it would be as much the case but wanted to make it clear to those who are unaware ... if it was left 'unsaid' who knows what grief may come back on Electrum for no good reason, except that it had an extra feature that was misunderstood.
|
|
|
I just uploaded version 0.35 to the website. Changelog: * New 'import' command to add extra keypairs to your wallet. Example: python electrum.py import 1MtQTsraWDcb7REUnVu8LS9hZswrLfWbH9:5KeCdRAkygEGfSzQ3ZNpQ2qE6PdEYCZ52S9Uq5DoBxkSgayX6ng
Note that you can export your keypairs in the same format using: python electrum.py addresses -k
Can you confirm if the following is correct? The imported keys are not contained among the deterministic key set generated so if/when you delete your wallet the imported keys will not be coming back when you use the seed-phrase to regenerate the deterministic portion of the wallet.
|
|
|
2112 The replies from slush and SgtSpike show that they simply don't understand generally accepted accounting principles.
Neither it seems do wall st. banks or the federal reserve. As I recall they suspended GAAP to weather the financial panic in 2008, as far as I'm aware those "toxic assets" that were exempted from GAAP rules are still stinking up the joint underneath a TARP somewhere, still exempt from GAAP. Perhaps channel your anger in that direction? (i.e. the destroyers, not the creators)
|
|
|
Not as far-fetched as you might think.
Most all inter-country electronic bank transfers in the world goes through essentially the ONE global clearing/settlement system.
It makes it pretty easy to do what he's suggesting. Also makes it pretty easy for the whole thing to come unstuck and send us all to monetary hell. Oh, the joys of a centralised system.
|
|
|
Looks cool. Lock has at least one use case I can think of but do not want to state here.
Wonder if you could swallow the thing in a hurry? .... nice and round for the exit at least.
|
|
|
It could purchase the resources it needs to survive (hosting/cpu/memory) and sell services to other agents or to humans.
It can survive indefinitely doing nothing but sitting on a large enough chunk of bitcoin as long as there is general economic growth. It just has to spend less to keep itself alive than it earns in interest on the bitcoin appreciation. Hey, if you can get enough of them out there in the wild and multiplying you could create some real demand for bitcoin .....
|
|
|
What happens when the .bit domain gets officially used by ICANN? Has anyone thought about that?
Nothing? Since namecoin is a different dns system, the two can work together. Of course you need to tell your browser if the .bit address you are looking for is a namecoin one or a normal icann one. That situation seems decidedly un-nothing-like to me, and awfully browser-centric. As it currently stands, DNS resolver operators can add transparent support for the .bit space 'as if' it were the same as any other toplevel domain. Scripts/email systems etc can then resolve .bit names without specific configuration. The fact that ICANN may effectively yank this mode of operation out from under us (you can bet nearly all resolver operators will revert to resolving official ICANN names) is surely a risk which may make it hard to convince operators to support it in the first place. Why would ICANN want to use .bit TLD in the first place ... see how much resistance they put up to extending beyond the limited set they began with. Adding in .bit for them would create more confusion than clarity. There is little upside for them to commandeer it at this stage. Why would they it is not like it is .com or .org ...
|
|
|
You guys need to hurry up :
-rescan functionality still not working -wallet encryption not working -GUI nowhere to be found -alternate clients without TX fees requirement ?
They will be open for help I'm sure. If you were a paying customer it may be different .... but you are not.
|
|
|
why on earth would you run your bitcoin wallet on tor, to me that's just asking some to hack you.
Actually almost the opposite is true. Running an unproxied bitcoin always from the same static IP on the internet is like dropping your trousers in public. (Having an unencrypted wallet connected to such a node would be like bending over with trousers around ankles in public.)
|
|
|
Any plans to make that a https connection to a server for added privacy possibility (man listening in the middle)? I suppose connecting to a electrum server across tor would work just as well against that anyway.
Only if you're talking about a server which is a tor hidden service. Connections to hidden services are encrypted and authenticated, end-to-end. If only the client is using tor to connect to a normal server (public IP), then it's much worse, you must use ssl in this case, as otherwise the exit-node can do pretty much what he wants. So, if the current client does not support ssl connections, do not put it behind Tor, unless you're accessing a hidden server. Yes. But only connecting to trusted Electrum servers over plain text http seems to be a requirement for this system work as a default position no? Or is there some way that a client can figure out if the server (or interceptors) is not just spoofing an Electrum server for nefarious purposes? A client behind tor to a trusted server removes traceability of transacting BTC addresses to originating wallet IP, since they could have come from anywhere on the tor network. An end-to-end ssl connection is obviously better but allows the server to know the IP of the transacting wallet addresses. The ultimate would be a federation of trusted Electrum tor hidden servers, I agree. No way for server (or interceptors) to link transacting Electrum client wallet BTC addresses with originating IPs. (Of course there are many other ways to do this besides, drive-by public wifi, etc)
|
|
|
|