Is that gavinandresen/bitcoin-git or bitcoin/bitcoin? If I also pull the anon-ish 'coin control' is that likely to interfere with 0.6 testing? How and where would you prefer test feedback?

Keep an ear out for it, people will refer to hours after morning or hours after lunch, etc. But I've never seen it written or on clocks or anything like that. I think it's basically a lost tradition. But the idea has fascinated me for a long time. I wanted to produce a clock with only one hand and thought there might be inspiration in Thailand. But nope, everyone I asked nodded and smiled then looked at me like I was crazy.

As to why? Why what?

Dude. You are out of line. It is clear you dislike the changes, but you should be humble and grateful. The client is a gift from the developers to you. Oh, you have some suggestions? Great. Share your opinions.



This may be true, but it is not the dumb-device network-edge masses that drive innovation. I believe you are a Linux user and are therefor familiar with the fiasco of Unity and Gnome 3 Shell? While building an UI that caters to the masses is important, alienating the power users is project revolt and stagnation. However, I don't see any radical UI changes from 4 to 5 and I look forward to new the new features in 6 and beyond. All in all, I'm happy with the direction of the reference and alternate clients.


Yes! There are many concepts that are difficult to grasp. But by assuming they are ungraspable we guarantee that users remain stupid. While this problem will solve itself with new clients, I believe the client evolution has been a bit backwards. The client could have been more transparent, modular, and simpler and we would have learned much from the experimentation and even mistakes of early adopters who are typically quite tech-savvy. But I believe that's the past. The code is getting cleaner, there are several libraries, alt clients, and web services available or in development. The future is bright!

Hey Ty Goat,

On the topic of timezones and Thailand, have you ever seen a six hour watch or clock (or gong)? I gave it an honest search in SE Asia but failed. I might exchange my left testicle for one.

    ... mong chao (Thai: ...โมงเช้า, [mōːŋ tɕʰáːw]) for the first half of daytime (07:00 to 12:59)

    Bai ... mong (บ่าย...โมง, [bàːj mōːŋ]) for the latter half of daytime (13:00 to 18:59)

    ... thum (...ทุ่ม, [tʰûm]) for the first half of nighttime (19:00 to 00:59)

    Ti ... (ตี..., [tīː]) for the latter half of nighttime (01:00 to 06:59)

Gavin, I agree with your sentiment, on both the potential experimentation that could be happening as well as the actual failure to truly innovate.

Having said that there have been some minor variable tweak itch scratching of note: shortening the block reward (has anyone bothered to analyze the dis/advantages?), forcing miners to use the CPU (has that broadened the miner-base, produced any social or other advantage?), and... well that's it, actually, as far as I've noticed.

While Satoshi's public, proof-of-work transaction ledger seems obvious now, it is of course revolutionary. But I can't help feeling there's got to be a better way to prevent double-spending. I would like to see an algorithm that can be done on paper; an altcoin party trick; a truly anonymous, side-channel, no electricity, post-nuclear Armageddon stone age, isolation tolerant blockchain something. I certainly don't have the answer, but I miss discussions of that level around here. Where has all the creative intelligence gone?

Puik, are you still charging a transaction fee? I don't see mention of it on your site. I didn't receive an answer by PM several weeks ago, so I'll address this publicly. I believe it is too early for you to impose a transaction fee. Your efforts and service are certainly worth paying for, however, I have been playing and testing your site out of pure fascination and for your benefit. I can not justify experimenting if I have to pay you even one penny for the privilege. Donations are different. For your own financial interest, I hope you will reconsider the transaction fee at this time.

+1

I strongly support the boycott of GoDaddy. Zhou, I enjoy the services that you offer and hope you do switch away from GoDaddy. I intend to boycott all sites that support SOPA including sites that support GoDaddy. This political issue is more important to me than trading on leverage. I think many of your customers will agree.

Ah, right. Thank you.

Genjix, are you not considering the Lesser/Library extension?

That is a strange site. Is it a parody? Why are they writing in English? Americans for Ayatollah?

Thanks for the links, particularly Charles M. Hannum's comments on NetBSD licensing. It contrasts the opinions of O'Reily which have been quite influential over the decade. I had suggested a playful BSD-like license (Poetic License), but perhaps the Affero extensions and strong copyleft are necessary with respect to bitcoin, and the Lesser extension for libraries such as libbitcoin. Though isn't LGPL (in contrast to GPL) essentially BSD?

Sounds excellent. Looking forward to playing with it. I'm curious, does Armory support plaintext i/o for command line pipes? Have you and Genjix (libbitcoin) shared C++ code or are you both reinventing wheels?

I've generated multiple wallets over the year, created on different machines, with different client versions, with different levels of trust. I've transfered those funds to my latest and greatest secure wallets, but every once in a while I go through this corpus of wallets looking for coins. I have no specific reason not to trust those old keys, but for example, one was made on a Windows machine at work when I was very new to bitcoin. It doesn't have the same level of security in my mind as my wallet on an offline private Linux box.

I will likely import and merge all of my old wallets into a single untrusted/old wallet. But it really should not be difficult to continually sweep those keys. I think it's a reasonable use case, with a relaxed definition of 'insecure'.


You are taking my 'off the top of my head' example too far. But yet you admit the problem of social engineering through code. You can't prevent users from doing what they want. You should give them tools they don't need to break, but might learn to understand.

If something is a security risk, or it's a pain in the ass to code without any immediate benefit, that's fair, but I do not like the question "Is it something we want to support and encourage?"

Rather than the recipient republishing an address received from an unknown untrusted entity, you could vaguely imagine cases where trusted (but potentially incompetent) users share some fund. Suppose my girlfriend and I have a bake sale and share an address, either one of us could sweep the keys. Of course there may be better ways to handle this particular instance, but I only use it as an example legitimate case.

btc_artist, what if the client maintained a wallet.dat and untrusted.dat? The coins in untrusted.dat would never appear in the client balance. A menu option would allow for 'Sweep Untrusted Keys'. An opt-in automatic asynchronous process could sweep periodically. If you wanted to interact with the keys directly, you could simply backup and rename untrusted.dat.



It IS published in the block chain. Who knows where else it may exist in print.



I think you are putting too much emphasis on 'insecure'. In PGP parlance, it would only not be ULTIMATELY trusted.

Let us not be limited to use cases we can currently imagine.

This is my way of thinking as well. But we must admit that we are not the typical user. I have little understanding of the average user's mental model (of any technology, whether email or electricity) and I imagine they have none at all but it is hopeless to try to educate them at this phase. Shouldn't the 'coin control' patch give you what you want?

I'm actually pretty cool with the idea of a 'trusted wallet' and an 'untrusted wallet'. I would like a service that does pull/sweep untrusted keys periodically. In fact, I'd like a service that randomly scrambles all of my coins while I am sleeping. These features are possible but perhaps none of them are on topic with respect to 'sweep/import private keys'.

I misunderstood your position before your re-edit (EDIT: and Etotheipi's re-clarification). I suppose sweep and purge is at least consistent with respect to the data model. As is pure import.

Call me a pack-rat then, I abhor the idea of throwing a published address into the aether. But, my use cases are admittedly obscure. If I want to keep an untrusted key, I could just import it into a untrusted wallet. Everyone is happy. OK, I'm on board for exclusively both IMPORT and SWEEP (and forget).

Then that can and must be handled at the user interface level. Not twisting up the data model.

Flag the address in the wallet as untrusted/imported and mark it with skull and cross bones in the GUI or: "100 BTC (20 untrusted)" in the HIGHLY UNLIKELY case of this occurring. You could also perpetually import coins sent to imported addresses to new addresses, but second class keys in the data model is a backassward design.


It can and should be optional, recommended or not. It is far worse to have strange behavior ALWAYS, rather than strange behavior in the unlikely and potential malicious case of someone planting a trojan-address in your wallet.


How is this 'new class' of flagged key different from your 'second class' swept key?


That's draconian and at best it could be optional though I am sure no one would elect to throw a key away. Why should anyone ever throw a key away? On this point Satoshi would agree with me.

Genjix's libbitcoin will contain firstbits. He went on a tangent removing the '1' prefix, which has subtle but incompatible implications. I believe he's returned to your implementation. FreeMoney and Puik had a short conversation about order within blocks. It should be possible to find real-world test cases.

Why not the third option, where "SWEEP" means, "Import and immediately transfer coins"? I think "SWEEP" with second class keys is the worst of all worlds: confusing to newbies, disempowering to geeks, and complicated to maintain.

Thus with import implied, the only question is: "Do you want to transfer funds to a new trusted address?" Yes (recommended) or No (I know what I'm doing).