Please don't do it, it's a terrible idea. How many BTC did you get? Is it really worth permanently defacing your body for?

I said encrypted key! Though if you're drunk you may also blurt out the password...

Seriously though - for the love of all that is Bitcoin, please nobody tattoo QR codes on yourselves!

Here's what you need: https://chart.googleapis.com/chart?chs=150x150&cht=qr&chl=Hello

Replace the 'Hello' part of the URL with your (preferably encrypted) private key, print out the result and take it to your local tattoo artist.

And hope he doesn't make a mistake!

Ah, I think I now remember hearing these objections before regarding Namecoin. In my opinion the key would be to have a generic system, even more than worrying about the block chain baggage - you really don't want to start polluting the code base with for example NC specific code.

Incidentally this is what I probably like the most about Bitcoin - it exposed so much uncharted territory

Alright, thanks for the lead - I see that Mike has been quite active, I have a lot of reading to do :-).
Not including the data directly in the main block chain is exactly how I was thinking about it - I believe you simply need to include a hash of the external 'symbiotic' Merkle branch. It's still 'extra baggage' I suppose but it will be a tiny fraction of sizeof(vtx). I'd say the indirect benefit of having these very useful services only purchasable with Bitcoins combined with the extra mining revenue make this quite useful - what's the official take on this?

In fact thinking about it - it doesn't even have to be in CBlock, it could just be a regular transaction with some fancy scripting...

I will now crawl back in my hole and come back when I'm not quite so ignorant, hopefully with some code.

Thanks chodpaba.

Regarding D.H.'s client - I was also thinking about direct integration with Dropbox but with stories like this one about lapses of security, I'm not sure it's such a good idea (even with encrypted wallet - why expose yourself to attacks if you don't have to). My current thinking is to simply let the user specify a list of backup paths that the wallets will be automatically replicated to. I haven't figured out how to make the UI 'mom-friendly' but it would then let the users pick the backup service of their choice (I do like Crashplan btw). Not forcing everyone's eggs into the same basket is probably a good idea.

I really do like the suggestion of displaying insufficiently verified transactions as 'in progress' - I think that works even better than my iconic representation of the state. It would also help communicate to the user why there is a fee on spending these young transactions.

So we're Microsoft now?

We're OSS fans - we'll use it when it makes sense for business. AllBitcoin subscribes to the 'do no evil' philosophy. We want to see many competing clients in the Bitcoin ecosystem because we believe that is the only way the system can be successful.

Let's not bicker over this - I think we have the right to license our code as we like and you have the right to not use it if you disagree with our decision. We both agree that Bitcoin is awesome and that's what counts here.

How's this?

http://download.allbitcoin.com/Images/shot.png

 

Hi there!

I was wondering if anyone is working on the idea of generalizing the transactions that go into a block. Right now the only type of transaction supported is moving Bitcoins between addresses but as Namecoin demonstrated - there are certainly other uses for a block chain backed by so much processing power.

I think it is possible to extend the protocol to allow for other classes of block entries. They would be announced through the P2P network just as regular transactions and they would include a fee transaction to whoever mints a block containing it. To validate an entry, it should be possible to extend the existing script VM (e.g. support for key value store in the block chain) or create a new one to avoid introducing vulnerabilities to Bitcoin.

I imagine mining pools would list prices for the various types of services that they're willing to process into their blocks (or refuse to deal with some no matter what the price). The market would then find a value for the individual services in relation to the resources needed to process them. It would also provide extra compensation for the miners that could well exceed the Bitcoin transaction fees and coinbase reward).

Not only would that allow Namecoin like service with the security of nearly 15 thash/s but open the doors to further innovation.

Other than Namecoin, another concrete example is a trivial time stamping service. The validation script for the 'transaction' would simply return 'true' and would include a small data payload (say a sha-256 hash). Now if you come up with say a particularly clever piece of code - you can submit its hash in a time stamp transaction with a payment of 1btc. If you have to ever prove you had the idea first at some point in the future - the evidence is right there in the block chain (I'm sure there are less contrived uses for it, this just popped into my head first).

I think the biggest problem is to do with increased bandwidth and storage demands on the nodes. This could be mitigated with opt-outs for the lighter nodes, though even the nodes would benefit from servicing these symbiotic transactions indirectly by keeping all miners working on one chain and increasing Bitcoin's inherent value.

I'm curious what you guys think of this (and I apologize if this has been discussed before).

I guess it's just like with those sneaky folks over at Bank of America - now that they have my trust they'll probably be running off with my savings real soon...

Seriously though, as I have pointed out in the other thread, OSS does not imply trust. The advantage of open source in this context is that in case of a breach of trust, another group can take over the project. However that won't protect your wallets. AllBitcoin was set up because we believe in Bitcoin's potential. We think it's a game changer. Rather than trying to make a quick buck mining or day trading, we want to help build the infrastructure to fully realize this potential. As we do, I believe we will earn people's trust and that trust will be more valuable than any scam you may suspect us of right now. You are certainly right to be suspicious - we have not earned it yet. I do hope that doesn't prevent us from discussing the UI design of the next wave of Bitcoin clients.

So as to not hijack D.H.'s thread anymore than I already have, I would really appreciate if we could take this discussion elsewhere.

I'm sorry, there is none - this has been discussed here already.

Hey guys, I already made a post about this in the newbie forum earlier but I feel it's relevant to your efforts - http://allbitcoin.com

I have gone a step further in simplifying the UI, though our ideas are quite similar. Check out the screenshots and let me know what you think!

They have now started the account recovery process. I do hope they thought it through a little better this time...

I am not sure what you mean about the project seeing the light of day, though I commend you for actually working your way through the code. You represent a tiny minority of computer users however and AllBitcoin is clearly not for you. OSS has many fantastic properties and I'm a big supporter of it. Many eyeballs on the code are great for security and bug finding. However OSS does not imply trust. For your amusement I recommend you check out some of the code presented here: http://underhanded.xcott.com/

Most of us trust banks, OS vendors, video game developers, etc. enough to use their closed source software. I would prefer for it to be open sourced too, but that would not influence my level of trust in these organizations.


I meant it in the sense that prior to Bitcoins, most losses due to compromised computers could generally be reversed. Bitcoins give us irreversible transactions and a store of wealth sitting directly on our hard drives. We're not quite ready for this in terms of both social and software engineering but I'm sure we'll figure it out.

This is where I disagree - I feel that we have a very good reason for not releasing the source code (yet). Our focus is on making a client for people who may not even know what source is. For a vast majority of software users out there trust isn't derived from availability of source code. We want to keep the source to ourselves because we think it offers compelling features that other clients don't and we'd like to maintain that edge for a little while. I understand that in an OSS community this argument will fall on deaf ears but we're not forcing you to use AllBitcoin.

I would also recommend that you don't trust binaries just because their source code is available. It is perfectly feasible to hide malicious code in plain sight or introduce something bad in the build process. We're working on a distributed web of trust solution for code signing to solve these issues in general. Bitcoins have helped expose how lax our security has been and if we want it to succeed, we have a lot of work ahead of us.

Also please keep in mind this is early beta, we're simply hoping to get some feedback on our progress so far (other than 'source or GTFO')

Few reasons (in no particular order):

• Distribution size and ease. Qt DLLs are pretty weighty - the basic set (Core, Gui, Network) come in at over 11 megs on top of our download. Admittedly .Net is an order of magnitude bigger, but on most PCs the runtime is already there. Also the oneclick deployment platform automatically deals with the dependencies.
• Qt is probably as good a cross-platform UI toolkit as one could hope for, but Qt apps still fall short of the native experience. We've gone with .Net for now for speed of development but the long term plan is to have a light, snappy native Win32 client with as few dependencies as possible (a single, small EXE that can live on a USB drive would be ideal).
• Licensing - Qt would cost extra.
• There's already a Qt client project, we didn't want to duplicate efforts unnecessarily.

I'm still trying to work out what Bitcoin is all about . I would argue that having an ecosystem of competing clients would be more in keeping with the spirit of Bitcoin. As I've mentioned before, closed source is a temporary state while we feel it makes business sense. If we succeed the way we'd like to - it is inevitable that the source code will be available for thorough inspection in some way.

See my earlier points about only testing with trivial amounts if at all.

I would also like to point out that it would quite monumentally stupid for us to have AllBitcoin do anything fishy at all. Any breach of trust would render all of our hard work so far useless.

I support all investigative efforts - monitor the traffic, disassemble the code, dump the memory. Look for unencrypted private keys or password - it should be highly unlikely to capture one in a memory dump and absolutely impossible over the network.

I am a C++ developer and have worked in the industry for 10 years, though I've been programming for another decade prior to that. This is my first startup and I have only limited web development experience (as evidenced by our website). Since most of my prior work was also public facing, I'm going to plead Satoshi on that to protect myself and my colleagues until I have a long and expensive talk with a lawyer.

I agree and wholeheartedly support this sentiment.

We hope to earn people's trust over time (by actually being trustworthy). We are planning a code signing system in the future - a combination of code and procedure to ensure safe, verifiable binaries. It's a tricky problem and until we figured it out we don't want to give the impression that a random binary is safe - whether from a newcomer or a trusted source.

I build all my Bitcoin related programs from source and carefully check the diffs. This is sadly not an option for the vast majority of people out there.