ok.
in case if they got mined, let me know.

yes - go ahead, send.

oh, don't be so modest.

you are certainly good enough to be a pioneer of implementing the stealth payments

That should motivate you to add testnet support there, at some point

Sorry - misunderstanding.

I wasn't sure what you meant asking what would be the easiest way to implement "this", nor who you were even talking to.
You posted it right after the post where I mentioned "Creating a GUI wrapper", so I though that "this" could be referring to implementing the GUI wrapper.

And what was your "this" actually referring to, BTW?

I would not know about Electrum, but if someone would like to make a coin-control GUI wrapper for Gocoin wallet, that is easy to implement:

1) Run tools/fetchbal to fetch unspent outputs of your wallet

2) Edit balance/unspent.txt file and leave there only the coins you are going to spend

3) Run "wallet -fee 0.001 -send addr=amount -change change_addr" to crate & sign a transaction. You can add "-useallinputs" switch, if you want to force including all the inputs (otherwise it will only use as many as you need for the amount).

4) Broadcast the raw transaction file, e.g. using this page: https://blockchain.info/pushtx

You don't need Electrum nowhere in the process.

BTW, did you know that you can use the "Pack extension..." option in chrome to create a crx file?

Having it installed from a crx, the browser does not ask you all the time whether to disable a locally loaded extension.

No I don't think there is anything wrong in my implementation.
Besides non-zero length prefixes, I have tested it quite much.

I can exchange coins via stealth addresses between DarkWallet and my s/w, including several sends in a single tx, and they never got missed.
So I guess it means that my implementation works?

I think it is more likely that Nicolas did something wrong during the first send.
We can try few more times though, if he wants, just to be sure.
I'm always open for more testing.


BTW, @dabura667, are you working on supporting non-zero length prefixes?
I'd like to test it against a different wallet as well.

Indeed.
Certainly you cannot say whether e.g. the fact that a banned peer gets un-banned after 24h - is a protocol rule, or a specific implementation.
In fact, entire domains like the "misbehaving nodes" concept or "standard transactions" are implementation specific.
Of course it is important to have it documented, because the bitcoin core handles now like 99,99% of the network, but when developing your own bitcoin node nobody can force you to follow these specific concepts and a development spec should be clear about it.
At the other hand developing your own node you definitely need to follow the p2p spec (at least for the commands you use), and most of all: the blockchain protocol - that's the very core of bitcoin, and still not quite documented.

Sorry, it's said in OP that the foundation might pay $2000/month for this project, so it made me thinking that they were driving this spec.

Anyway, I believe it is important to have it clearly distinguished where an actual protocol ends and where a specific software implementation starts.
The doc, although a nice piece of work, unfortunately mixes it all up.

To be more specific.
Lets go to the section "P2P Network / Peer Discovery" - what would I, a developer, expect to find there?
I would expect to find a technical information about how the peers discover each other in the p2p network.
But what I find is a description of what command line switches I can use when launching "Bitcoin Core" (that's a new name for me, BTW - it was always bitcond or bitcoin-qt).
Then somewhere at the end, there is finally a mention of the actual protocol, but pretty laconic and also quite useless (at least ATM), because it still requires you to go to the wiki to learn about the actual format of the payload of the addr message.
Then you have a few sections where you talk strictly about the p2p protocol... until a reader reaches the "Misbehaving Nodes", where his lecture suddenly gets switched back to bitcoind's user manual, and that's without even any indication of the fact.
I think it's pretty confusing. I mean, it doesn't confuse me (you don't need to be sorry), but it will definitely confuse people who read it to study bitcoin.

There is a huge difference between a bitcoin protocol and a specific implementation of a software, but I don't see the doc being even aware of this fact.
If you want to make this spec right, I would advise to try not mixing up these two things.
A reader should be aware all the time whether he is reading about a specific software implementation or about a protocol.
Moreover, it is also important to distinguishing the protocol's must-have hard rules (blockchain validation) and the protocol's may-have soft rules (different address types, the payment protocol, bloom filters, etc). And of course, the command line switches are neither of the two - they are the third kind, a user manual kind.

To wrap up, it is a really nice literature, you obviously put a lot of work into it and it has a potential to become a useful dev spec, but..
IMHO you should restructure it, because now it mixes up things from completely different domains, without mentioning it to the reader. That is not good for a developer's guide / reference.

if you don't want to use gitian, you'd need to rev engineer how gitian does it and then do the same:
from what I see, it uses "mingw-w64" and "g++-mingw-w64"

https://github.com/bitcoin/bitcoin/blob/master/contrib/gitian-descriptors/deps-win.yml
https://github.com/bitcoin/bitcoin/blob/master/contrib/gitian-descriptors/boost-win.yml
https://github.com/bitcoin/bitcoin/blob/master/contrib/gitian-descriptors/qt-win.yml
https://github.com/bitcoin/bitcoin/blob/master/contrib/gitian-descriptors/gitian-win.yml

OK - so it's for "applications".
Now I would have asked "what kind of applications?" if not for the fact that I already figured that you mean applications based on bitcoind's RCP API, or an API of other components that your firm is busy developing.
As an opposite to the actual (software independent) bitcoin protocol applications, as I perceive such through the proto described on the wiki.

So currently it is not a "Bitcoin Developer Reference", but rather a manual for bitcond's RPC API, right?
In such case, I have no critical comments, except maybe for the title of this doc, which I find a bit misleading, to say the least.

You ought to at least make it clear that it is a guide for a specific software API, not so much for Bitcoin as the universal bitcoin protocol.
Otherwise some more experienced devs could blame you of advertising a misleading message about what Bitcoin actually is  

I think I did check everything and really comparing both of your pages, to these two:
https://en.bitcoin.it/wiki/Protocol_specification
https://en.bitcoin.it/wiki/Script
.. I would not envy a guy who has to build a bitcoin software, basing only on your spec.

But OK, I understand that it isn't complete.

Still, if I may add, most of all you need a nice & clean table with all the network messages linking to their descriptions (with sub-tables describing the payload of each type).
And the same for the script - I don't see a table with script opcodes in your spec.
That's the two references I've used the most - nothing else matters that much.

You can have some more epic descriptions, but they should rather be there as an additional help.
So only if anyone doesn't understand what an opcode does (by its name or short desc), he clicks a link and goes there.

Fascinating lecture.
But you cannot seriously think that this is more useful for a dev than the old wiki.
Or can you?
Well, IMHO it isn't - devs need tables and short explanations, not epic descriptions.
It looks good to be released as a book, though.

Not saying that this is a bad piece - only that it is too long to read, as for dev purposes.
Bitcoin isn't that complicated, nor we seek adventures in its documentation.

If you don't mind operating the wallet from a command line, I believe Gocoin wallet would be what you're looking for.

http://www.assets-otc.com/gocoin/manual/offline-wallet

1. Build the wallet's executable and move it to your offline PC.
2. Think of a seed password that will be a key to your coins. You don't need to backup it, but don't forget it!
3. Execute "wallet -l" and enter the password twice (you do not need to store it on disk).
4. Use any of the public addresses that the wallet has output to move your coins into the cold storage.

For spending from your cold storage you do not need the full node.
1. Use tools/balio.go (or tools/fetchbal.go) to fetch a balance of the address(es) that you want to spend from.
2. Move the balance/ folder to your offline machine (where you have the wallet's executable).
3. Make a signed transaction there: wallet -send destination_address=amount_to_send

No, the previous two transaction were just broken, as far as I can check it.

The third one is fine, though - I received it with no problems and no modifications in my software.

Oh, I had though the "public key" was the one you put after OP_RETURN.

Never mind, though.

Yeah, this one is correct!

I'm sending it back in tx c85b654a97f0ed150ff76b6c2ef50b9aa4a1911d7186d815be1c8c02dfcb3a81

With 03b4e5d3cf889840c75f0dd02ebda946151bf37e56cb888c6002c2ae5288e56de7 I'd expect address mvXf4sF4C1w5KgQyasbEWxqVyqbLNtVdnY

sorry