Quote from: titeuf_87 on September 19, 2012, 08:41:03 PM

As an Ubuntu user though, a lot of applications I use are made in Python and they work just fine.

Yes. Python works very well on Linux because it is shipped out of the box, has good bindings to the native toolkits, etc. But most people don't use Linux.

Quote from: titeuf_87 on September 19, 2012, 08:41:03 PM

I was thinking about something similar, except without any blockchain at all on the client side. Since there needs to be a central server anyways to collect all signed inputs, that central server can keep track of the blockchain too.

Yes, it could do that. It complicates the client/server protocol though, and in future I'd hope to see assurance contract support integrated into wallet software. As it's already doing the block chain tracking, it'd be easier for those clients to just submit the transaction directly.

You can set up a basic GUI wallet app in bitcoinj with only a few lines of code, it's not very complicated.

Quote from: titeuf_87 on September 19, 2012, 08:41:03 PM

2) It notifies the server about this address: when bitcoins are sent to it, the server will let the client know and the client will sign a pledge for the assurance contract and send it back to the server.

The server has to indeed track the block chain no matter what, so it could pass transactions back to the client for signing. But there's already a protocol that lets a client find transactions given some keys/addresses - the regular Bitcoin P2P protocol. It's weird to reimplement that. Bear in mind, if you don't care about handling re-orgs, the default P2P protocol is quite easy to use. But you probably do care about re-orgs, otherwise you'll end up with weird edge case bugs.

This is why I recommend just using a pre-written Bitcoin library. Switching out the bitcoin P2P network for something HTTP+JSON based doesn't change the fundamental rules of the system, it doesn't let you ignore re-orgs and other details of the chain consequence-free.

Quote from: titeuf_87 on September 19, 2012, 08:41:03 PM

3) Whenever the server got enough pledges it'll broadcast the final transaction to the server
4) If there aren't enough pledges and the user wants their bitcoins back then the client can create a new bitcoin transaction and send it to the server who will broadcast it.

Why should the client depend on the server to help them undo their pledge? That seems like an inherent conflict of interest. Again, just talking to the P2P network when possible solves this issue.

Quote from: titeuf_87 on September 19, 2012, 08:41:03 PM

Also, with protocol buffers, you mean to use that for the communication between the client and the server, right? If so, why not just use a http server and json?

You can use HTTP if you like. Why protobufs? Because I think they're better than JSON. Firstly there's a simple schema language that's easy to read. Most of the time when I see JSON examples they roll their own way to describe the protocol and rely heavily on examples. Secondly there are protobuf compilers that generates wrapper code for you based on the schema language, for almost any programming language you can name. So you can work with data structures directly instead of awkward JSON data types. Thirdly it's efficient and robust, especially when transmitting binary data (which is common in Bitcoin protocols), there are no weird encoding quirks that can bite you like with JSON.

In short I can't see any reason to use JSON for anything unless you're communicating with a web browser and are OK with just eval()ing the response. But even then sometimes it's unsafe.

Also protobufs are gaining pretty good adoption, there are lots of libraries and things that integrate with them. Eg, the Netty async IO library in Java can handle protobuf+HTTP natively so there's almost no code needed.

I can guess the protocol might look like

Code:

// Stored in a file and downloaded from some web server/email attachment/etc.
message ContractDescription {
required bytes output_script = 1;
required uint64 target_value = 2;
// An HTTP or HTTPS location where a Pledge message can be POSTd.
// Can be missing in protocol variants where this is provided by context.
optional string pledge_submit_url = 3;

// A human-readable description of what the contract is about.
optional string description = 4;
// A 600x300 PNG that can be displayed in the GUI alongside the description.
optional bytes logo_image = 5;
}

message Pledge {
// Sends target_value funds to output_script
required bytes serialized_tx = 1;

// A human-readable message (maybe of encouragement) to the entrepreneur
optional string message = 2;
}