Well I thought about that one but I have to swap both of them that is incoming and outgoing to make sense.

Hi all, I am a bit confused here:
According to the spec and main.cpp the version message should be first me and then you:
(line 2364)
        int64 nTime;
        CAddress addrMe;
        CAddress addrFrom;
        uint64 nNonce = 1;

but from what I see over the network it is more the otherway around, as net.h would suggest too:
line 743
    void PushVersion()
    {
        /// when NTP implemented, change to just nTime = GetAdjustedTime()
        int64 nTime = (fInbound ? GetAdjustedTime() : GetTime());
        CAddress addrYou = (fUseProxy ? CAddress("0.0.0.0") : addr);
        CAddress addrMe = (fUseProxy ? CAddress("0.0.0.0") : addrLocalHost);
        RAND_bytes((unsigned char*)&nLocalHostNonce, sizeof(nLocalHostNonce));
        PushMessage("version", VERSION, nLocalServices, nTime, addrYou, addrMe,
                    nLocalHostNonce, std::string(pszSubVer), nBestHeight);
    }

As I am not proficient in cpp, I don't really know now what is going on.
Could someone shed a bit more light on this please?

Thanks,

Martin

Seriously though, how is a mugger going to get bitcoins off your android if you dont' tell him the password? This will take a very sophisticated mugger.
[/quote]

Never underestimate the persuasive power of a baseball bat :-)

Am I missing the point or do I not understand your question?
What do you actually mean by filling the void? As I interpret it as: All fiat currencies have gone to smithereens and people lost all value in it and need to start again from scratch, perhaps by using bitcoin? Yes of course in that scenario bitcoin can fill the void, as can seashells, garden peas and whatever else you can convince other people to accept for trading.

In any other scenario, it would be the same question as; Can pesos fill the void in a bank run?

I sincerely hope that the amount of transactions in the block is a factor in defining the longest chain, but I don't know.

As far as I can read the code (I am sure that Sam will refactor the code ones he is happy with the functionality, so it is easier to read/maintain/extend for mere mortals  ), this is aimed to be a full implementation of the reference c++ bitcoin implementation.

So in other words, where you used to run the bitcoin client downloaded from bitcoin.org, you can alternatively use his python one instead.

Good to see I am not the only one working on a Python implementation, a little bit of competition is a good thing :-)

Cheers Sam, good work!

Bitcoin; Trusted by more paranoids than any other currency.

Bitcoin; You don't have to trust me, just that 1+1=2.

Bitcoin; Don't bother if your happy not to own your money.

Bitcoin; When was the last time you where happy with your bank?

Bitcoin; When was the last time you where happy with your governments financial ruling?

You might want to consider looking for a technet subscription, in 'non-developed' countries MS usually throws it in free if you ask them nicely and say that you are a starting developer on 'their' platform. With that subscription you can pretty much download every piece of mainstream software that MS has ever produced and get 10 official full commercial usable product keys, per product version. Though after three years or so they probably going to require payments, for renewed subscriptions (your keys will continue to work).

Hmmm, me thinking about those nfc enabled smartphones ...

At the moment I am just parsing wireshark dumps for my protocol decoder, so I would be very interested in this too!
I can get a bit of a wiggle on with my python  stuff so you can at the protocol level decode it (well assuming I did it right), for decoding I more or imitated the look of a raw representation of blockexplorer. I am about 2 weeks away before I can release anything decent but I should be able to put something halfway working on within a couple of days, if anybody is interested.

I have a couple of goals set:
- Split out the protocol in a pure daemon part (which does the communication and storing of the blocks/transactions) possibly with an optional SQL back-end.
- Have everything PEP-8 and Python 3 compliant.
- Have unit tests  with a 100% coverage.
- Be able to have a local "blockexplorer" that does not depend on the c++ client but instead uses the code of the above daemon.
- Create a 'thin' CLI client that interacts with the daemon (in essence this will just hold the private keys and have some UI code).
- The same as above but a GUI client.

For me when coding, the most important part is readability and maintainability, this is also the reason why I am at try number 3  because the other tries, although successfully parsing the tcpdump of an interaction, was not readable enough. So ultimately I want my implementation to be working 'pseudo code'. As I have particular strong feelings on how the Protocol Specification should be written, I think that I am not the appropriate person to contribute to that page.

As the approach I am taking is painstakingly slow, I wouldn't hold my breath, though I do intend to release the source under the new revised BSD license.
And I am sure that when I at least have reached my 4th goal, I can be persuaded to (help) create a RFC with the intention to submit an Internet Draft to the IETF.

While I am quietly in my limited spare time building a python implementation of the bitcoin protocol I am increasingly charmed about the ingenuity of the protocol itself.
Sure in the beginning I had of a lot of things* that I found strange but what is even stranger is that I am continuously discovering that the choices made might not be pretty, or particular easy but they share one common trait so far; the alternatives have far worse implications**.

So I would like to take my hat off and say three cheers to everybody that is working, designing and building the protocol, the software and community!

Thank you, it is truly appreciated!

<sub>* )
1 The constant byteswapping. Well once (:-)) you have it subclassed  you hardly notice it anymore.
2 Only ~21 million BTC available? Yeah but it is easy enough to increase the divisibility
3 What about lost coins, can we not have a system in place where forgotten coins are available for reminig? Neat, but this ultimately leads for regular users to a dependency on an external service provider, which opens a whole other can of worms.
4 The use of secp256k1, Well ones you look into it, it is kinda neat and there is not a clear and obvious advantage to other curves or public key algorithm, so this falls in the category why not.
5 The lack of a python implementation. Well, I am working on it, so that one is my fault for not moving my behind faster :-)

** )
My opinion, thus the validity of the made statements are not universal.</sub>

Sent, enjoy!
[/quote]

Thanks!

12zhTAZg4R6DuV3TJpXTDE98ayFn9YL5qH

Most appreciated as I am not on exchanges and my laptop is a bit slow in mining :-)

Hi,

Thanks for the snippet it is greatly appreciated!


Yes, that is correct, as you already figured out bitcoin only sends the xy position of the curve, however for openssl also needs to know which curve is used and of course what type of public key it is, since this is all DER encoded I opted for recreating the DER package. As you can see I used the same key to check if it works. Although in my code I only have a dependency on openssl directly (via subprocess) and thus do away with m2crypto or any other crypto wrapper, I do have a new dependency on pyasn1 http://sourceforge.net/projects/pyasn1/ though.

The relevant part of my code:

 they are not round just look like it because they have an indefinitely amount of corners.

Hi,

The problem is an organizational one, if you don't trust the exchange in holding the money, the only logical alternative is that a user must make a manual effort to verify the transaction before it is processed. This more or less defeats the purpose of an exchange service that gets its added value because it can act on behalf of the user and large amount of transactions are automatically processed. Otherwise you end up with an ebay for bitcoins.

But perhaps I misunderstood your paper or exchanges in general.

Cheers,

Martin

I would also recommend that option but question if the FBI is the appropriate authority, if the business you are running is done on US soil and the suspicious activity comes from US soil too, then yes FBI would be the most appropriate agency to contact although you should that via the local police. It is their job to elevate it to national, thus federal, level.

If either party is foreign, well things get a whole lot more complicated, to the level that it might be best just to report to the police and most likely never be heard of again.

It might be an idea to have this whole fiasco recorded, signed by a notary and publicized on a prominent accessible part on your site.

Although a whole lot of people carry the sentiment that this could have been prevented, this hindsight is of course 20/20. Security as a goal can not be achieved, though it is a path that should be followed. A common rule of thumb is that the effectiveness of countermeasures can be roughly divided in 75% organizational, 15% structural and 10 % electronically. Meaning that switching to an alternative OS with a more robust database and scripting language might seem the right thing to do, it is more effective to make rules that prevent or at least monitor suspicious activity.

I wish you all the best and strength to carry on, this mishap is naturally a lesson learned, but not as much as some on this forum make it sound. From where I stand this should not affect you on a personal level at all. It goes more in the oh-f* category, you already demonstrated you have a plan for contingency and are open to what is going to happen. The only thing that remains is doing that and rest is water under the bridge.

Believe me this is less of a screw up than when I accidentally shut down a banks main transaction mainframe (it was the end of the day and I typed shutdown -P now in my laptop terminal, which was actually an ssh session over to a box that was serial console attached to that SUN machine).

Luckily for me that bank had a hot fail over instance in another country, though waiting another 10 unpaid hours to verify the machine came up cleanly is synced and took over master role is not something I would like to do again :-).

As the wallet is only needed when sending an transaction it is perfectly alright to encrypt it and prompt the user for a password to when needed.

*ahem* (FreeBSD user) ducks for cover, waiting for an OpenBSD user to reply.. :-)