Yeah, but in this case anyone can trivially replicate the transaction already anyway. It's just a race to see who gets it mined first. Heck, I'd do it myself, but sebicas was pretty clever for figuring it out so I think he deserves the BTC a lot more than I do.

As I said, get it to a miner who will mine it. According to the wiki Eligius will, so use -addnode=173.242.112.53 or post the raw hex for your transaction here and I'm sure someone will be able to forward it for you.


Doesn't look like it. The scriptPubKey consists of a single OP_TRUE opcode, while the createrawtransaction command only allows you to specify outputs as valid addresses, or nothing at all. The latter would leave scriptPubKey totally empty.

If you look at blockchain.info's network propagation page for that non-standard spend right now it shows %13 propagation (326 nodes) even though though the transaction has been on the network for over an hour. I tried connecting to some of the nodes myself:


Looks like none of them are the standard Satoshi client, which sets subver to "/Satoshi:0.7.1/" or similar. Any idea what these nodes might be? There sure are a lot of them... there isn't anything special about the IP's, just the usual mix of various DSL/Cable providers and hosting companies.

Looks like that person screwed up though, see tx af32bb06f12f2ae5fdb7face7cd272be67c923e86b7a66a76ded02d954c2f94d Same idea, but an earlier attempt with the wrong endian and hence unspendable.

The one with the correct endian has been spent by tx 09f691b2263260e71f363d1db51ff3100d285956a40cc0e4f8c8c2c4a80559b1 Curiously I'm seeing it as unconfirmed right now, which implies that either that Blockchain.info has a server ignoring the IsStandard check or it does in fact pass. For a scriptSig input, as opposed to a scriptPubKey output the actual check is AreInputsStandard, although looking at that code I don't see how it could have passed the test. The transaction also hasn't propagated to any of my Bitcoin nodes, which implies the former explanation.

EDIT: oops, didn't see you saying you sent that TX... you might also want to try re-sending it directly to Eligius, who accept non-standard TX's for mining. See the wiki page Free transaction relay policy. I think you can trigger that resend by re-running sendrawtransaction

That block has another interesting set of transactions; e1a1a0242d46fb515a3aaaef713104832384a0f30a4fcdfefb982d1c06e56860 is one example. p2pool includes a zero-valued output in every one of their coinbase transactions that just pushes the hash of the current share in the p2pool sharechain to the stack. While zero-valued those outputs are spendable as they are evaluated to true. Looks like this person has gone off and found every (?) such p2pool output and spent it. With pruning that's actually kind-of a public service by reducing the tx-out set...


They'd also make good examples for the wiki.

Exactly. Not to mention differences in compiler bugs, and even potentially CPU bugs, especially with the growing trend of putting dedicated crypto hardware in general-purpose CPUs.

For instance imagine if one day there was a "fast-path" that used a special-purpose SHA256 block available in, say, certain x86 CPU's, and there existed a specific bit-sequence that would cause that specific SHA256 block to produce an erroneous output.

FWIW at the hardware level things like repeated sequences of certain bits are often the cause of erroneous behavior. Now imagine some engineer doing, say, a worst-case power analysis of a high-performance SHA256 hashing unit "there's no way a SHA256 hash will ever have the first 65 bits set to zero"...

...so tell those organizations not to use Bitcoin.

Chain-splitting bugs are inherent to the design of Bitcoin and any other crypto-currency based on the same principles. We just have to live with it and figure out how to deal with the problem, by necessity the hard way.

Given that we are in truly uncharted territory taking a cautious approach makes a lot of sense to me. Bitcoin's only existed as a valuable entity for about two years now, and the use of alternative implementations has been pretty small. Why rush?

Mike's thought about Bitcoin being like avionics software is very prescient in my opinion. I work in electronics design and it's routine for companies that make complex parts, such as ICs, that get used for critical applications to "freeze" whole production lines. They'll give you a formal, documented, change notice for something as simple as changing the type of paint used to put the part-number markings on the chips. The industry has learned the hard way that extremely subtle changes can make things not work, essentially because the reason why these parts work in the first place isn't anywhere near as well understood as the engineers wished it was. When it comes to chain-splitting frankly I think Bitcoin is squarely in that territory. Equally plenty of big organizations just live with these problems; we didn't ditch avionics just because it was hard to always make parts repeatably, but we did stop changing paint formulations unless we really, really had too.

Alt-implementations are a good way to explore this problem, but that's just it: explore. Don't start using them seriously until we've done a whole lot more of that exploration. I suspect we're going to find that even just differences with different installations of the Satoshi client prove problematic enough, and god help us if attackers start trying to introduce changes into system libraries like openssl as a way to attack the Bitcoin software.

I'll see if I can get a chance to take a look at it. pynode is a really good candidate for Cython as you've written it essentially just like a C program anyway. Basically I'd just have to add static type declarations to the performance critical stuff, and add declarations so performance-critical class instances are backed by staticly-laid-out C structs rather than dictionaries. Once you've done that what Cython emits is pretty much straight-forward C code. With some care performance should be pretty similar to the Satoshi client.

Don't get your hopes up though; I work at a startup. I'm also still plodding away on that coinbase time-stamping project I mentioned awhile back, although rather slowly right now due to my job being busy.

Heck, I initially started writing OpenTimestamps in Cython, before I realized I was being an idiot: merkle tree timestamping is embarrassingly scalable...

Targeting C and the Python C API is a very appropriate choice for Cython. The Python C API is very good and easy to write for. The code that Cython produces is also very readable, so you can get a good understanding of what's going on by reading it. If Cython compiled directly to assembly understanding what's going on under the hood would be far more difficult.

The other thing to keep in mind is that one of the big use-cases for Cython is to interface existing C-code to Python, especially for writing wrappers around C libraries. You can basically write C-code with Python syntax if you want, including calling C API's directly: http://docs.cython.org/src/userguide/external_C_code.html Again, if Cython compiled to assembly debugging such extension modules would be far more difficult.

Have you looked into using ''.join() or StringIO/FileIO rather than building up strings with simple concatenation? Python is a lot better at avoiding the n^2 naive immutable string concatenation slowdown than it used to be - the r += foo for instance is handled as an append in place most of the time - but given that the serialization code in pynode is creating strings with code spread out over multiple functions and modules you may be defeating that optimization. In particular I took a quick look at the 2.7 internals and while I may be misunderstanding things it seems that if a string is created in a different module the resize-in-place optimization is disabled for some reason.


My other suggestion would be to look into using Cython. Roughly speaking it's a Python compiler, however really you have to write Cython code rather than pure-Python to get the benefits. The compiler outputs C-code targeting the Python C API. If you know what you're doing this can be every bit as fast as pure C-code while still being written in Python. In addition regular Python code can use a Cython-compiled module just like any other pure-Python module so interoperability isn't a problem. Even just writing part of Pynode in Cython would be perfectly practical. Windows is well supported BTW; the SciPy scientific python project uses Cython extensively.

In addition while the syntax is pretty ugly Cython even supports a decorator-based way of writing Cython. Thus when a Cython install isn't available you can use the provided pure-Python stub module that simply ignores the decorators allowing you to run your code without Cython available. I haven't used this feature myself - as I say the syntax is ugly - but I hear in some cases it can be quite useful.

The web+ prefix is meant to designate that a website has registered that protocol handler; Bitcoin isn't a website. The origin of this limitation is probably security concerns, for instance registering protocol handlers for protocols that have no reason at all to go to a website. Note how chrome has a few exceptions like mailto: for where it is agreed that websites should be able to register protocol handlers. Chrome can eventually add bitcoin: to this list if the chrome developers think it is a good idea. In addition it looks like Firefox does not have this limitation.

My objection to this sort of explanation is that while it is technically correct, it gives absolutely no insight into why any of this is happening; what's the point of all this bundling and bow-tying anyway? Or who is resetting that combination lock and adding and removing digits from it? You have to convince people that Bitcoin is legit and secure, and in doing that communicating why things are done is much more important than communicating exactly what is being done.

Saying that mining is voting on the order that transactions happen lets you very easily explain why determining transaction order is a problem in the first place, especially when you make analogies to overdrafted cheques, as well as how the problem is solved. In addition it's an explanation that sounds natural and fair; bringing groups to consensus through democratic voting, rather than imposing a central authority, is an explanation that resonates with people.

Sure it's unfortunate that some people start thinking they can swing votes and what not, but again, explain that the voting mechanism is purely about the order of recent transactions and nothing else. (in addition you can also explain that to change a block in the past, you have to have enough computing power to outvote the sum of every subsequent vote) If you want to change something else you'll have to convince a super-majority of the people using Bitcoin to change all at once, and just like, say, replacing the constitution doing that is very difficult, even for changes everyone thinks are reasonable. (I said super-majority for a reason: in practice if a super-majority change, the minority will update their clients as well in practice)

On the main testnet it actually hadn't been; gmaxwell suggested getting some hashing power together to make testnet3 reach the halving point before mainnet, but no-one actually did it. I'm sure plenty of people ran their own tests by modifying the client in various ways, however it's not just the client that matters but also the whole infrastructure including things like mining pool software. In any case, as far as I know nothing broke.

You can-not enforce without force. You choose to value transactions by the strength of the proof of work, but nothing is forcing you to do so other than a consensus.


I disagree with you quite strongly on this one. The thing is there are two separate, but related, issues here: transaction validity and transaction order.

Consider for instance the Iraqi dinar. I'm oversimplifying, but essentially after the fall of the Iraqi Government during the second gulf war there wasn't any force backing the dinar in the way fiat currencies usually are. However the dinar retained its value. Essentially a group of people had a consensus to follow a certain set of rules about the dinar, namely that pieces of paper that looked a certain way were accepted to have value. Even banking survived somewhat, thus in addition there was another set of rules that transactions following accepted accounting principles could be considered to be equivalent to those pieces of paper. This situation lasted until the coalition forces imposed their own will, essentially shifting this consensus to allow an additional rule: the coallition forces are allowed to make more dinars.

Of course all of this happened by consensus purely out of trust that the consensus would continue for however long you wanted to hold dinars.

Bitcoin is of course also a consensus, specifically that transactions that follow rules that the Satoshi client audits should be considered valuable. The thing is it is not miners who enforce those rules. The consensus enforces those rules, simply because the consensus is that any transaction that doesn't follow those rules is considered worthless. It'd be theoretically possible, albeit totally impractical, for someone to decide to accept a transaction after carefully checking the whole blockchain by hand to determine if the rules were being followed. Bitcoin clients simply automate this process.

If you could somehow trust people not to double-spend you would not need mining. However we can't trust people, just like we can't (blindly) trust people not to write checks that will bounce. Thus Bitcoin has an additional rule where we consider a transaction invalid if a transaction spending the same coins exists and has a stronger proof of work. If we could somehow timestamp transactions directly, and in addition have some mechanism to be absolutely sure that everyone has an up-to-date knowledge of every transaction made, again we wouldn't need mining.(1)

Miners of course choose what transactions to include in their blocks, and that part of mining I don't (strongly) consider to be voting. Where the voting comes into play is which block they decide to use as the previous block for their block creation attempts. Sure the outcome of any individual block is discretized in a way that no normal voting system would be - only one lucky miner will solve the proof of work - but after repeated blocks the outcome is effectively a vote proportioned by hashing power. This is particularly evident with cases like non-standard transactions and new types of transactions, and we speak of a "majority" and a "super-majority" of miners for a very good reason.

There are strong parallels in how governments work: you have the law, which enforces how politics and voting is conducting, and then you have the votes themselves, which decides who gets into power. It's just that in Bitcoin takes the "first-past-the-post" effect to the extreme, so much so that changing the rules is exceptionally difficult.


Anyway, more to the point, we're talking about how to explain Bitcoin to non-technical people. Analogies are never perfect, and yes, the analogy that mining is voting certainly has flaws. However I strongly think that using the analogy of voting to explain what mining is, and laws to explain what the transaction rules are, makes far more sense to people and gives them a much better mental model of how Bitcoin works than starting with a much more technical explanation that immediately jumps into the proof-of-work and enforcement. After all, saying that solving a difficult math problem somehow enforces something just doesn't make sense to most people. Saying that you solve that math problem to prove that your vote should be counted does. Your explanation is more technically correct, but the vast majority of people have a good intuition for what voting is, and no intuition at all for what a proof of work is.

1) As a thought experiment, consider what would happen if every Bitcoin client had a magical radio that could broadcast a signal so powerful that every other Bitcoin radio was guaranteed to receive it, and at the same time, everyone had access to one or more radio receivers in secret locations that they used to ensure they weren't just receiving a faked, directional, radio transmission. If everyone could leave their client running 24x7, and everyone had access to a secure time source, you could replace mining with simply the assurance that you would always know what transaction was valid simply because you were guaranteed to see the valid one first. Equally you would know you could spend your coins because everyone else could do the same verification as well. (bootstrapping your client does of course pose problems with this scheme)

Mining is really simple: it's voting. Yes, when you look up close it looks like solving puzzles for a reward, but if you step back and look at the effect over long periods of time fundamentally it's about the majority of participants voting on what order transactions take, and that vote is done according to computing power people dedicate to solving those puzzles.

I also find that if you explain Bitcoin in terms of voting it makes a lot more sense to people. In particular I've found that it makes intuitive sense to people that if there isn't a central authority imposing consensus, a voting system allows consensus to still arise. It also makes it clear that solving those puzzles isn't meant to provide any sort of "useful service", rather it's just how you prove how much computing power you control so you're vote is counted correctly.

We also need to keep in mind that anything that sounds at all like promoting an investment could get the foundation in a heck of a lot of trouble should regulators decide to push the issue. The press release completely overlooked the technical side of the block reward dropping; it's something that fundamentally was untested, both technologically and socially, and the fact that the reward drop went by without incident shows that Bitcoin has a certain level of technical maturity. Make a press release about "Satoshi's plan being successfully executed through code" or something; don't bring economics and visions of growth and profits into it. And ideally just keep a simple fact-based PR release stating the obvious: the price drop happened and nothing went wrong. If you want to talk price, talk about how the fact that it didn't change much shows that people have faith in the usability and stability of the technology and sociology underlying the system - that is the sort of thing I want to see the foundation working on. Not wading into economic arguments about deflation in press releases like this.

There's nothing wrong with Bitcoin being boring you know.

FWIW while I've never tried doing it QEMU can apparently emulate the big-endian PowerPC architecture. Here is one guys notes about getting it working from two years ago, specifically to test endian issues.

You're cynicism is a good thing... but don't think even hiring "professionals" magically makes the problems go away. How do you evaluate if someone is a professional? How do you deal with the inevitable conflicts when their idea of "done" doesn't match your idea? What are clear terms anyway? These are all things you'll be much more qualified to answer after you've had some experience being that developer being paid and seen the process first hand from start to finish.

Keep in mind too, that if people forget about a project and disappear, that may be an indication you're doing something wrong too.


Not at all. You do the first x%, prove that you know what you're doing and are on the right path, and then you can ask the community for the other y%. I'm saying the x% you've done too date is far too low to be taken seriously. You'll also find that after you've done one round of this, x+y << 100%


Security isn't a feature, it's a process. The analogy isn't that your house under construction doesn't have a roof, it's that people are noticing the walls being put up are crooked and the roof won't be supported when it is added. You're saying you'll straighten up the walls later, which may be true, but why weren't they straight in the first place? What's your process do make sure they are straight when you're done?

Frankly I think figuring out how to test cbitcoin properly is the most interesting and challenging part of the whole project. It's very good that you're beginning to do this, your scriptCases.txt in the test/ subdir as well as the other unit tests, but I don't seem to be the only one who is unconvinced about the depth you're going into. In particular I don't see any information on how your test suite can be used to validate the Satoshi client. Doing that is an essential validation that your test suite is itself correct. Similarly rejecting invalid transactions is a case that must be done correctly.

As a suggestion: a good project would be some sort of node behavior logger that wrapped around bitcoind and collected every transaction received, valid and invalid, as well as the state of the node when the transaction was received. (state being essentially what transactions the node has already received) If you can replay that log for your own software, including the invalid transactions, and you wind up with the same end-state at the Satoshi client you'll be a lot closer to where you need to be.

What I just described isn't that simple... but if you can implemented that, and understand where what I suggested oversimplifies the problem, I think you'll be far closer to understanding the problem enough to be able to effectively push cbitcoin ahead.

Those are the flaws that have been found; who knows what flaws are still there.

Network splits are a big danger and the Bitcoin software is mostly unique in having that problem. Because it's unique people don't have prior experience dealing with the problem, so the process of learning about network splits is going to be painful as alternate implementations become more popular. I'd rather see that process happen in a slow, controlled manner than happen quickly and accidentally. You know the build system that itself isn't what worries me, it's that such a build system is a sign that other software engineering considerations haven't been considered carefully.

cbitcoin could make for an excellent test case for the type of compatibility tests that Gavin has worked a bit before. (as could pynode) The development of it could help drive testing those tests and learning how to apply them. Instead I get the impression of a rush to get some big grand project out the door.

The code may be open, but open code only helps if you are knowledgeable enough to both understand the code, and understand the potential problems. Frankly Bitcoin is complex, and subtle, enough that even most experienced developers don't have much hope of doing that without a big investment of time. Thus if cbitcoin has flaws it will be used anyway, although hopefully used less if the developers who do understand the issues vocally complain on the forums. Obviously that's exactly what has happened.

The market is only efficient if information is widely spread. Unfortunately information about what bitcoin software is secure doesn't appear to meet that criteria very well.

I'll make another point: what's your prior experience with working with others? Part of what you're asking money for is to have the option to hire people to do some of the work for you, and in addition you're also asking for help with the codebase. I haven't done much management myself, but I have done just enough to know it's surprisingly difficult. Do you even have experience even just contributing to an open-source project, or working as a programmer in a large group? The people skills of setting expectations, negotiating technical compromises and so on are surprisingly hard to learn or do right without experience, well, doing just that. Frankly you're going to waste peoples' donations and time if you haven't had experience doing this before; at least have solid experience working in a group on software. It doesn't have to be fancy - some web-programming for a website is fine - but it has to be real and it has to be in a group.

Myself I'd feel better even if you were able to say you worked as a shift manager at a fast-food resturant; seriously, even that kind of experience would make a big difference to your success with hiring others on the project or with working with other volunteer contributors. Right now I just get the impression you manage to come off the wrong way with others in the community.


I'm 27 now, and I remember my projects ten years ago that I thought were going to change the world... and they didn't. Do the right web searches and you can probably still find some emails on the Freenet project development lists among others that I now find kinda embarrassing to say the least.

I've got this timestamping project I'm working on right now. It's not as far along as your library, 2500 lines vs. 9800, but still, you notice how probably no-one here actually knows the name of it? I might think it's going to change the world, but I don't want to waste people's time on a project that doesn't really exist yet. There's nothing wrong with eventually asking for donations and asking for help, but get something concrete first that's actually getting used in the real world to do a real task, then start thinking about where you're going to go next. You're also not going to really understand how your software should be architectured until you're at that point.

Myself I've set the goal that my timestamping thing needs to be able to create and validate timestamps, and a user should be able to do that out of the box. It doesn't have to be pretty or nicely documented, but it has to do something real and useful. I know I'm not really going to understand if my idea even makes any sense until I'm at that point. For instance for you, you're not going to know if, say, writing it in C makes any sense until you try integrating cbitcoin with a real-world C application using it. You also won't know if you're library interface makes sense until someone else tries to integrate *their* application with your library; IE, the point where they'll decide "yeah, lets send some money to this guy and improve it" Speaking of, the discussion on the forums about the license for cbitcoin is a good example: you'll understand better what sort of licensing works for people when people actually want to use your library for a real-world application.

Making a big deal about the project before that point is just going to make people think it's a bunch of vaporware, and people are also going to think I'm wasting a lot of other peoples time on the forums. I'm definitely not at the point where I can ask others for money to further the development effort. Posting occasional status updates and progress reports is fine, but just like me you're a long way away from going further than that.

tl;dr: In open-source useful working code speaks louder than anything else.


jgarzik and others have raised very good points on why his failure does have the potential to do a lot of harm to others. Splitting the network with incompatible implementations is a very real risk and does have the potential to harm everyone in the community. In addition bad PR from software failures affects us all.

Besides, I want to see Matthew become an open source contributor, and much of being an effective open source contributor has nothing to do with technical skills.