To be fair, r.willis acknowledged the issue earlier, before he released the code. Perhaps it was the reason he was reluctant to release the source to soon.


Or maybe the plan was indeed to have no verification in order to reduce transaction and block propagation time.

Actually, it's pretty clear that you're the one who doesn't know how the internet works nor what a mesh network is.

Does this include running a bitcoind instance each?

Anyway, maybe you should ask the mods for this to be stickied while the offer is available.

I find this political view rather naive, as if this good faith act of providing a compromise will count for anything in the eyes of those who don't like Bitcoin. Instead it simply provides a platform and a foothold on which to build. You cite DMCA as a good example, but ignore SOPA 

This isn't really a compromise at all,
- the regulatory side are given a tool for free which may or may not be helpful, depending on the adoption of users (assuming no legislation to make it mandatory).
- the users of bitcoin get a more complicated system where some coins are less than others, in exchange for the hope that governments don't ask for more.

The problem I see is that users will converge on a set of blacklists whether they agree with the reason for blacklisting or not. Here's how (so you can explain what I've missed )

Suppose someone obtains some coins through a drug deal, and I don't care about that, so I happily accept his drug money for some other service. When I later try to spend that drug money, a large number of people refuse to accept, so I'm forced to use clean money for that transaction. This essentially means that the drug money is unspendable, and hence worthless, or simply worth less than clean money. I decide I'm not making that mistake again, so even though it's against my political principles, I refuse to accept drug money in future. I'm now one more person who has cut off anyone using drug money.

Combine the above with the fact that the majority of people don't want any trouble at all - even when completely innocent, and so will choose not to accept money on any of the blacklists run by governments, and you end up with a situation where your money is worth the most if it's not on any of the blacklists.

People in general are lazy, stupid and only willing to fight for their political beliefs when they personally are being persecuted, so I think the idea that we'll have some happy equilibrium representing what the majority believe in will not happen.

What?

Maybe I'm reading this as overly negative, but I think you need to look at this in terms of how it can provide a foundation for experimentation and further work, rather than how it won't immediately solve every problem and will create others.

The point is that the protocol as it stands has shortcomings, and these may become problems as we scale up (in number of transactions, nodes or block size). As such, the protocol will have to evolve. Having work in place for sending and receiving some messages over UDP allows for more possibilities when considering solutions to larger network issues, and will give us a better understanding of the benefits of different approaches.

Ah, sorry, the calls to valueToBigInt should have been to Util.valueToBigInt.

Fixed a bug (sounds like the one you describe) - check pull request.

I expect your friends and family think you really a major drug dealer, and that this 'bitcoin' thing is just a way for you to avoid admitting it to them

Split the work into a 2 man process? Use BIP 38 and have the note itself contain two individually sealed parts, one for each person's information (the encrypted key and the password).

Ah, I wasn't aware of this.

Ok, fair enough, but that assumes that you are trying to fake a recent block. If you want to fake an old block, the difficulty is much lower.


If you do this, then wouldn't it be simpler not to do backwards scan in the client at all? Instead, the client provides the server with the definition and the output he wants to test, the server then does a forward or backward scan and determines whether the output is colored, constructing a proof as it goes. Then it sends the proof to the client. Maybe this was your idea all along?

Currently the algorithm finds the matching inputs for the given output and then visits each of these inputs. It is depth first because the order in which the inputs are put on and taken off of the queue is last-in, first-out. What killerstorm wants is to pre-calculate the depth of each output and store this depth with the output itself. This way, when adding the transaction inputs to the queue, you sort them in order so that the one with the smallest depth is always the last item in the queue, and thus is the next output that will be visited.



I think the plan is that the code I wrote will actually end up browser side, replacing the node specific http requests with jquery ajax or something. The idea is that the server knows nothing about colored coins or any color definitions. Instead, all it provides is transaction data so that the client can store color definitions and perform the color-matching algorithm itself. This way you do not have to trust the server.

I wrote the code with the idea that it was probably going to be cannibalized and modified later when it gets integrated into the rest of the work. It is mostly a proof of concept that the idea works and that the performance is acceptable for an end user.



A color definition is a pair of transaction hash and output index. This uniquely specifies a given output. When an address receives funds, what it actually means is that there was a transaction where the output specified that address as the receiver. The inputs of each transaction are simply the outputs of a previous transaction (or reward for mining a block). This way, you can trace all the bitcoins back to their creation, or similarly, trace all the created coins forward to where they are now.

The colored coins idea is that we simply label a given transaction output and then we can trace the location of this output forward as it gets transferred and split up between other people. By using addresses rather than outputs, you would limit the ability to use colored coins with non-standard transactions, and really, colored coins are much more interesting if you combine them with exotic transactions.

This is a monster of a task - it equates to implementing most of the functionality of an SPV node in the browser. The crypto is intimately tied to the binary representation of the transaction data, so you need to implement full parsing of the raw transaction and block header structures.

Also, without having the blockchain headers in the browser (say in local storage) and verifying them, the cryptographic proof is meaningless - you don't have verification of the block header that the transactions are linked to. So you additionally need to have a way for the server to provide a full header chain download and verification code in the browser.

Anyway, I think if this is your plan, I can do this (assuming I have the time), but it's a lot of work, so can you break it down and assign individual bounties.

If you only ever want one client, then who cares whether the source code provides good documentation or not? You'll use the software you're given because that's all there is. Your statement makes no sense.

Lol, I didn't realize you could turn it off - assumed it simply stopped displaying it as the network activity didn't change.

Turns out that only accounts for 1KB/s each up and down, so there's still some funny business going on. 5KB/s total up and down over 24 hours is pushing half a gigabyte, compare that to what is possible from a thin client
- Sync from last checkpoint in mid-February, 3200 blocks is about 260KB down (2000 headers at 81 bytes per block plus 24 bytes message header, then same but for the remaining 1200),
- 144 blocks over 24 hours which is another 15.1KB (81+24 bytes per block header)

So total down could be as little as 275KB for your first day, then 15.1KB per day after that. Compare that to half a gigabyte per day and it's quite significant if you're running it over 3g or something.

Ahh, just realized what the extra bandwidth is - MtGox ticker data.

Anyway, does anyone really care about a few KB/s?

What's the lie?

Just tried this myself, here's the results after both have synchronized
Multibit: send 2.6 - 3.2 KB/s, receive 3.6 - 5.0 KB/s
Bitcoin-qt: send 0.6 - 1.2 KB/s, receive 0.6 - 1.2 KB/s

Both have empty wallets. Surely Multibit should really only be receiving rare unsolicited 'inv' and 'addr' commands and sending nothing.

I think this is what the blockchain.info phone app does. I liked the idea when I saw it, but it looked kind of weird to me. In a similar vein to changing font size, changing the colour saturation might also work, e.g.

0.12345678

or both combined (now my favourite after clicking preview)?

0.12345678

Details?

Also, test vectors?