I don't care what forms suggest (mm/dd/yy), I always spell out or abbreviate the month (2011-DEC-14). On the interwebz, we're all confused by 39.45% of all ambiguous non- ISO 8601 numeric dates, whether Americans know it or not. |
|
|
|
I like "sweep" -- it has very clear semantics that I think users will understand: "Take all the funds that were sent THERE, and send them to me RIGHT NOW."
I like "sweep" as well, and I think it would meet all the use cases I have for importing, as long as it keeps a copy of the private keys that have been swept and implements "auto sweep" on them fairly often (once a day?). It would be nice if there were still an option to do a clean import. It can be hidden under an advanced tab, with a checkbox confirming that yes I really understand the implications and yes I know it is not recommended and that a kitten will die. A sweep to a single address has side effects that a non-guru, but still savvy user, might not appreciate, such as merging all transaction history into a single IDENTITY, throwing out any pretense of plausible anonymity. |
|
|
|
Would you like to secure these coins with a new private address? This is recommended, especially if you've received coins from another party.
([ Secure! ]) [no]
Default Secure (transfer coins). I see no realistic use case in which a user would be confused, no more than not having this feature (managing multiple wallets is much more confusing than merged wallets). |
|
|
|
|
Anyone clever enough to have two wallets is clever enough to understand the implications of merging them. The utility of merging, upgrading backed up wallets, splitting, side-channel transactions, etc far outweighs a bit of potential confusion.
|
|
|
|
You can say "Don't Do That", but if they CAN do that, then they WILL.
So what. They CAN delete their wallet, and they WILL. |
|
|
|
|
Exactly, it's not like bitcoin is fundamentally complex. It's basically PGP, GIT, and BitTorrent merged poorly.
|
|
|
|
Perhaps there's a market for higher denominations on the cheapest possible material. I am interested* in a graphs over time... * not so interested to do it myself.  |
|
|
|
|
Because Satoshi was a Windows developer.
Seriously. Tiny utilities piped together would have been more transparent, stable and extensible.
|
|
|
|
|
Seems to be the case with many of the 100 BTC bars. Have you compiled any statistics on the number of pristine/defiled coins or average deflowering time?
|
|
|
|
|
What language is the script? Ecma?
|
|
|
|
It's simply that you're inputting a private key from an external source, when the mindset most users will have is that their balance is theirs. ie, the risk that someone else somewhere has a copy of the private key.
I think you are pushing the general understanding of 'security' way too far. As if running shoes should be equipped with special sensors and alarms preventing you from tying your shoe laces together. How did I get this private key? I created it myself, I stole it, or someone gave it to me. If I now see transactions from before I imported this private key, that would be fully expected behavior. At most it is confusing, but I see no security issue what-so-ever. It's certainly valid to expect features to be well tested, but we should balance utility against impossible-to-protect-the-user-from-himself conservative development practices, lest we relegate the 'reference implementation' into oblivion. |
|
|
|
Pretty-please, is importprivkey or sweepprivkey or any similar functionality coming soon?
This isn't a place to spam feature demands. If you really want to see this functionality, help get it usable and stable/tested. The big issue is that importing a key as-is will suddenly show a bunch of "send"s in your history, and likely creates a security risk. What is more likely to be workable is the "sweep" functionality that resends any balance on a private key to a new known-secure private key, but nobody has written that yet. Is there a thread discussing these security risks? I no longer use the C++ client because it fulfills few of my use cases. Alternatives reduce the incentive to test and improve the 'reference implementation'. Perhaps there could be an unstable/risky 'and the kitchen sink' nightly build. |
|
|
|
Pretty-please, is importprivkey or sweepprivkey or (mergeWallet or) any similar functionality coming soon?
Beautiful-please... |
|
|
|
|
TL;DW: cute monkey 1:00, cute cat 1:45, internet something 2:00, tor 3:00, bitcoin text reference 6:00, bitcoin spoken ref 7:20, liberty reserve 8:00, summary discussion 9:00... pretty boring if you don't understand hebrew.
|
|
|
|
Funny, I think of the lack of exchange depth and corresponding illiquidity for a high volumes of USD-BTC makes the exchanges essentially fractional reserve USD banks. Bitcoins may be worth $3 each, but if everyone tries to cash out at once, they'll be in for a rude surprise as this is essentially a bank run (exchange run?) that causes liquidity problems, just like a real bank run, except that the last person to try to cash out only gets $0.30 (nothing) on the dollar You describe the difference between inflationary and default risk. A bank run is a default risk (you get nothing) while this 'exchange run' is inflationary risk (what you get is worth less) just as much as a deflationary risk (what you get is worth more). That potentially no one wants bitcoin is no different than every asset in existence sans pure energy. |
|
|
|
In other news, it is 12/13/11... Kinda awkward isn't it?
Only awkward in the dyslexic 'merkan system. Most of the civilized world calls it 13.12.11, 2011-12-13, or very similar variation. |
|
|
|
People say funny things about volume. When bitcoin was worth 10x as much as today, we might expect the volume in dollars to be 10x more. Let's compare volume during time periods with comparable prices, between $2 and $4...   Nothing unusual there |
|
|
|
|
How do you define transaction cost? Does it include risk, literal fees, confirmation time, convenience?
Mt. Gox codes present a default risk, but there are no fees, transactions are nearly instantaneous, and at least where accepted, they are convenient. They are essentially one-time use and could not replace bitcoin because of the redemption race condition.
But I don't see that it follows, as you seem to imply, that such instruments do not inflate the money supply even if only minusculely. During the short life time of a redeemable code, before it is redeemed, doesn't it carry the same transactional value of a static bitcoin that might otherwise have been used? Is it any different if the US Fed doubles the paper dollar supply in the morning and destroys the excess in the evening, versus some other doubled credit instrument with a twelve hour lifespan? I understand the stickiness of prices (wages probably won't budge nor will prices double), but when a street market vendor notices that his fresh fruit are selling especially quickly, might he not consider raising prices or pulling the discounts?
I could believe that digital money increases velocity by design, providing an extra inflation for which gold is not similarly susceptible.
|
|
|
|
|
Show Posts
