Excellent! Are you going to implement HTTP transport (push or poll?) or TCP socket tra
I'll do HTTP, efficiency really isn't relevant to my use case, and leave the TCP implementation for the future.
Great. Keeping in mind that there might be more transports is always good idea. I don't really use IRC a lot. Do you plan to have something more than a google doc page (e.g. a homepage, wiki, reddit, ...) ?
If you don't use any IRC client, webchat inteface can do the job for you: http://webchat.freenode.net/?randomnick=0&channels=#stratum&prompt=1I already tried to install MediaWiki to my server, unfortunately I have some missing dependencies on the server and didn't find a time to fix it yet. Then I move specification from Google docs there. Homepage at stratum.bitcoin.cz will appear at some time, too. At this moment there's not a lot things to publish anyway, there's even not any server release or even installation howto :-). I'm focusing on getting it work right now... I still don't know exactly how to generate the offline TX, and haven't yet gone over your doc - sadly
Honestly, I'm not a specialist in bitcoin p2p protocol, so I'm always finding inspiration in some existing code. For creating transactions, Electrum client is good code to start for me. However if you're Java programmer, BitcoinJ should be good choice for you and I see you're already using some code from bitcoinj... |
|
|
|
You can checkout my initial skeleton of an java binding here - subject to change, of course. Excellent! Are you going to implement HTTP transport (push or poll?) or TCP socket transport? I encourage you to implement TCP socket because of lower overhead, although I understand that HTTP can be easier to implement. Btw yesterday I implemented message signing and succesfully tested HTTP Poll and Push transports, although Google document isn't updated yet (thanks to 2112 suggestions, I added Content-Length, Content-MD5 and X-Content-Sha256 headers, there's also X-Push-Url for turning HTTP Poll transport into HTTP Push). I'll try to commit all changes soon so you'll be able to test your client against working server, but I still need to cleanup the code. If you have any questions or suggestions, join #stratum channel anytime! |
|
|
|
Everything seems stable at the moment and we're getting over 1.7gh/s.
+1 ! |
|
|
|
(Some) Bitcoin lovers don't understand that for Bitcoin to succeed it can't remain just a P2P network used by hackers and computer geeks.
Don't worry, I already see there's some interest for such solution even between developers. And I'm sure that people (=users) will love solutions based on lightweight clients (and developers will be enjoying writing websites using Stratum API). |
|
|
|
Bro, I suppose you're giggling everytime you hear the word "Stratosphere" (aka Scrotosphere) or "Stratus" (aka Scrotus), right? :-) "Stratum" is normal word and it's root is widely used in related words (like stratosphere), so I don't see anything wrong with this. However some people suggested that they have negative connotation to such word, so I'm not so sure now. Edit: "stratum" is even first suggestion for synonym at http://thesaurus.com/browse/layer . I don't see anything wrong here... |
|
|
|
|
Btw I closed contest about name for this overlay network. I picked name "Stratum", which is latin word for "layer".
|
|
|
|
|
Contest is closed, I picked name "Stratum". I'm sending 2BTC to Marcus right now!
|
|
|
|
Thanks for great link, it's exactly the answer what I has been searching for. It's actually very similar to the solution which I discussed with genjix on IRC, but it's nice to see that others found same solution independently. It looks that I'll choose those conventions described on stackexchange. It is slightly complicating all the signing the stuff, because it de-facto needs custom object encoder. However it is necessary to implement only in clients which require signing of proxied calls; common clients (using only blockchain service directly on overlay server) probably won't care about signing at all. Edit: excellent, I found that "canonical JSON" is widely used term and there are some implementations in various languages already, like jsonical for pyhon ( http://pypi.python.org/pypi/jsonical/). I just need to test if those implementations are compatible, but it looks like step in good direction... |
|
|
|
|
I checked the server and found the message about losing network link for a moment. It looks like somebody pulled out network cable/restart switch. Actually it's second time when I see this type of outage, firstly it was ~month ago. Now everything works fine, sorry for the issue.
|
|
|
|
|
Looks like. Im travelling home right now,i'll look what's going on in few minutes.
|
|
|
|
I just want to emphasize again that you can have speed and convenience with a lightweight blockchain. Just see BitcoinJ, it runs even on mobile phones.
I have experience with BitcoinJ client on my android phone. Yes, it's better than downloading whole blockchain, that's without a discussion. But it's not *so* good as BitcoinSpinner client, which is lightweight. As and example, in bitcoinj I still need to wait to synchronize block headers, which is especially annoying when I'm using this wallet only time by time for face2face transactions. And lightweight clients cleanly wins in such use cases... Personally I love freedom of choice, when everybody can choose solution which fits his needs. And I see that infrastructure for lightweight and ultra-lightweight clients is still weak, so I'm trying to fix it. Then integration into existing applications will become extremely easy, because those applications won't need to care about blockchain at all, just use some internet service with standard API which will *completely* mask the complex world of bitcoin. |
|
|
|
For the usual case, you don't care that multiple messages might be equally valid. The signature is for "this message", not for "any message bearing the same content as this message".
I probably failed I expressed my worries. So I'll try again. Main benefit of JSON is that it can be serialized/deserialized in almost every language in transparent way, just obj = json_decode(ser_data). However, those json_encode/decode implementations don't care about order of variables in serialized data, because order isn't a part of json specification. So json_encode(json_decode(data)) can provide different stream than original data, which is necessary for validating json message. Thanks to this issue, you need to fiddle with serialized data directly as with text stream and remove signature-related data from this stream, instead of deserializing message, removing signature-related data, serializing it back and checking signature. As for the ID, don't leave it out of the signature unless you enjoy replay attacks. Just force the client to make it globally unique. There are already well established techniques for doing this.
As a prevention for replay attacks I'm proposing "timestamp" field. It's also the reason why I think that request should be contained inside the signature in some form. |
|
|
|
But one thing that I don't understand is why are people so in a rush to implement client-server solutions, when a p2p lightweight solution is perfectly possible, and we already have BitcoinJ to demonstrate.
Because both technologies solve different problem. Bitcoin p2p is distributed database, however I'm trying to create protocol for *services* on top of this distributed database. If you want privacy and security, you can every time use blockchain. If you need speed and convenience, use some overlay network, which masks compexity for you and provide only necessary service. It's giving freedom of choice, obviously. By the way, not all services offered by overlay must be related to blockchain and they cannot be provided in decentralized way. For example you probably want to pick some escrow service and use it's API directly or over trusted channel, not using some anonymous peer in p2p network. |
|
|
|
slush, how would the transaction mechanism work?
Creating transactions is done in few steps: 1. Choose destination address (or addresses) 2. Choose source addresses (=coin selection) 3. Calculate transaction fee 4. Sign inputs 5. Combine everything into transaction as a stream. All those steps must be addressed in bitcoinj already, because those are necessary steps for every client. Those steps are implemented also in Electrum client (python). However things can be slightly easier, because steps 2,3 and 5 can be done on server side (it's usually called super lightweight client, because it depends on server even with coin selection). BitcoinSpinner (java based android client) is doing it already. |
|
|
|
Add a "signature_algorithm" key to the response. Also, allow the request to specify a list of acceptable algorithms, like {"id": "1234", "signatures_accepted": "ecdsa: SECP256r1, SECP521r1; pkcs 1", "firstbits": "1payBTC"}
good idea As for actually calculating it, there are two ways to go. In a binary protocol/format or when the length of the signature is known in advance, it is common to construct the response using zeros to fill in the signature field, then calculate the signature based on that, then overwrite the zeros with the actual signature. In a text stream like this, I would build the response without the signature key and value, then construct a new response that includes them. Or just insert them, modern languages have no problem chopping and splicing strings, and C programmers already have lots of practice doing it the hard way.
Yes, I was thinking about this, too. Unfortunately it's getting slightly complicated, because there are also some other fields which can be changed without corrupting the signature, like message "id". It's because ID must be unique in particular session, but this signed response can be created as a response to some proxy call to backend (in the firstbits example, signature is created directly by firstbits service, but signature must be valid also as a response from overlay server to client. Another issue is that fields in json-rpc don't have strict order, so two identical and valid json-rpc may have different signature (well, 2112 must be laughing now :-) ). This is problematic for validating messages, because you need to extract fields which are not part of signed message, but not affect message payload. This leads me to conclusion that trying to sign/verify message itself can be very fragile. I also don't want to go against json-rpc specification and force such things like order of fields. Currently I don't know how to decide this issue, is there any best practice to doing this? How other text-based protocols solve such problem? |
|
|
|
However I see real issue in needed CPU time for signing. On my laptop, one signature takes around 200ms. It's low-end one, but it will take some time even on high-end servers. Any idea how to solve it?
I found that only python's ecdsa module is so slow. Author of ecdsa package did some comparsion to C++ and it was 20-30x faster. So the obvious solution is "implement python's ecdsa signatures now, optimize it with C++ speedup later". Signed messages have sense only for proxied calls or when using non-secure transport, so <5 ms per signature per message is doable in such situations. |
|
|
|
I think you have little error calculating namecoin reward.
Pool is calculating only one score for both chains, using BTC as main currency. When bitcoin block is found, pool calculate user's scores and calculate bitcoin rewards. Then it pick all namecoin blocks found during Bitcoin round and split them between users using BTC score. The overall efect for block rewards in long term is the same, however if you stop or start mining in the middle of bitcoin round, your namecoin reward can be affected significantly. |
|
|
|
Does the "blocks found" counter still work?
Yes, it works. And it's nice example that without pool mining, a lot of users won't find a block in months, even with significant hashrate. Btw some of my cards didn't find a block for months, too. |
|
|
|
Thanks slush. I urge you to be very specific about who this "somebody else" is and exactly what "level".
Somebody else = operator of overlay server. It's as simple as this. When we talk about blockchain services, the necessary trust to other party (=operator) is higher than in using full blockchain by self, but a lot lower than depending on "web wallet", because you're still the owner of your funds. In the case of other (non-blockchain) services like fetching usd/btc quotes from overlay server, it's the same like now; you still need to trust bitcoin exchange and service like bitcoincharts, which is aggregating quotes for you. Without this information, it is not possible for independent third parties to do a security analysis of your protocol.
What exactly are you missing and in which form you need such information? |
|
|
|
|
From all proposed names, I feel like Stratum is clear winner for me. I'll still wait a day, but unless somebody propose even more superior name, I'll pick "Stratum" without a public poll (you can call it 'enlightened absolutism', heh). marcus_of_augustus, can you PM me your bitcoin address?
|
|
|
|
|
Show Posts
