|
Thats perfect news, Kiv. Thank you very much!
|
|
|
|
I have read the discussion about separating target/difficulty and work data. I have to say I think this was a mistake as it opens possibilities for abuse. I think something about these issues should go in the docs. Otherwise someone is going to create a naive implementation with some nasty issues.
Well, after discussion with Kano I slightly changed my mind. As I described few posts ago, with slightly modified meaning of "set difficulty" message, everything should be fixed. Instead of meaning "stop sending lower difficulty shares than X immediately", set_difficulty should mean "all next jobs are using difficulty X". This still keeps the concept of separated difficulty message from the job itself, it doesn't require sending both messages together, fixes the problem of roundtrips (sending some bad-diff shares by the client because of latency) etc. It also gives the possibility to choose if pool wants to change difficulty in aggressive or in lazy way; by just sending "set difficulty" message without new job with clean_jobs=True, clients will slowly adopt higher difficulty as miners will start using new jobs, but pool can enforce higher difficulty with immediate effect by sending clean_jobs=True, as it is now. This change in protocol is also backward compatible, because pools using current meaning of set_difficulty don't need to change anything, they just *may* stop sending clean_jobs job, if they want. Because of this, it is win-win solution for me. I described this already, but the idea didn't get any significant attention yet. Is it ok to pipeline commands to the client? That is, send the difficulty change and new work (2 RPC calls) in quick succession without waiting for a reply to the first.
Yes, commands (notifications) can be pipelined. set_difficulty() and notify() don't expect any response from the client. Just sending one packet with both commands serialized is possible. |
|
|
|
Díky ziskovosti se z toho totiž staly závody ve zvyšování výkonu. Lidé začali kupovat grafické karty, stavět rigy s obrovskou spotřebou, obrovským výpočetním výkonem a tohle je prostě dle mého velká chyba systému jako celku a nikdy jej z toho důvodu nebudu považovat za efektivní.
Z pohledu systemu je zvysovani vykonu rozhodne vyhodne a nejedna se o nejakou chybu. Nezapominej, ze to hashovani tady neni jen pro srandu kralikum, ale vyssi difficulty a distribuovanost celkoveho hashrate zabezpecuje bitcoin pred mnoha typy utoku. Skokem bitcoin slozitosti do desitek nebo stovek milionu budou profitovat vsichni v podobe radove mensi sance prevzeti bitcoinu utocniky (vladami, botnetem, ...). Muzeme se dal bavit o netechnickych aspektech tezeni jako je ekologie a principech jako trvaly rozvoj, ale i zde je ASIC cesta dobrym smerem. |
|
|
|
|
Pletes si pojem "efektivita" s "penize zadarmo". Nove technologie samozrejme efektivitu zvysuji, ale nikdo negarantuje zadny vynos z bitcoinu. Pokud se ti zda, ze investice do noveho hardware bude finance nevyhodna - neinvestuj. Snizis tim slozitost pro ostatni, kteri jsou schopni lepe optimalizovat naklady nebo podstoupit vetsi risk.
|
|
|
|
...protože mineři budou tlačeni k investicím do nového HW....
Ja myslim, ze se na to divas uplne spatne. Bitcoin mining je free market a nikdo neni do niceho tlaceny. Vse je na dobrovolne bazi. A inovace tady jsou, protoze je o ne zajem. Fakt, ze za x GHash/s bylo pred rokem y BTC denne je naprosto irelevantni. Trh automaticky tlaci efektivitu vzhuru, naklady dolu, hashrate nahoru a zisk opet dolu. Pokud bude existovat optimum, kdy se s vykonem 10 THash/s vytezi za den 1 BTC, pak proti tomu nelze nic namitat, protoze to bude optimum dane technologiemi dostupnymi v te dobe. |
|
|
|
Maniac479. it looks like driver related issues, maybe even problem with your hardware. I tried 50miner before and it seemed to give me slightly lower speeds than GUIminer
Lower speed in 50miner is probably caused by lower aggressivity of the miner, which may lead to a bit higher stability. Try different GPU drivers or downclock your card... |
|
|
|
|
BFL neni jedina firma, ktera se o ASIC snazi, i kdyz osobne si myslim, ze je jedna z nejperspektivnejsich. Po urcitou dobu mozna bude existovat nejaka disbalance na trhu, ale verim, ze prijde vice vyrobcu a ze se tedy trh relativne rychle srovna.
A proc BFL ty krabicky hodla prodavat? Ja si myslim, ze ve chvili, kdy by se emise bitcoinu monopolizovala by doslo k radikalni ztrate duvery. Jinymi slovy - BFL muze teoreticky vytezit milion bitcoinu, ty by ale velmi rychle ztracely hodnotu kvuli panice na trzich. Naopak nabidnout produkt, po kterem je velka poptavka, je mnohem jistejsi forma vydelku.
Na rozdil od dost rozsireneho nazoru, ASIC neni pro Bitcoin zadny problem, ale naopak obrovskym krokem vpred. Zatimco dnes mohou efektivne tezit pouze lide se specializovanym hardwarem, ktery musi provozovat ne specialnich prostorech (zkuste si provozovat vetsi FPGA miner v obyvaku) a zaroven maji nehorazne ucty za elektrinu, s nastupem ASICu bude moci mit hashrate v radech gigahashu doslova kazdy jen diky malemu gadgetu pripojenemu k notebooku. Soucasna cena za ASIC je samozrejme relativne vysoka, ale to je opet jen o nabidce a poptavce. Jakmile tech firem bude vice, cena pujde raketove dolu. Fakticky je totiz vyrobni cena toho jednoho cipu v jednotkach dolaru. ASICy jsou zaroven krokem z pohledu bezpecnosti. Zatimco dnes je jeste stale mozne s investici v radech stovek tisicu dolaru nebo jednotek milionu prevzit hashrate cele site, za rok nebo dva to uz pravdepodobne mozne nebude, prave kvuli masove dostupnosti ASIC mineru.
ASICy jsou zaroven ultimatni reseni efektivity. Strach, ze nekdo za rok vyvine dalsi 10-100x rychlejsi cip je neopravneny, stejne jako se nestava, ze by AMD nebo Intel kazdy rok vyvijeli 100x rychlejsi procesory. Ty cipy navrzene BFL jsou uz velmi blizko soucasnym technologickym limitum, na rozdil od (doposud pouzivanych) GPU a FPGA, ktere jsou z pohledu bitcoin tezeni vyrazne suboptimalni.
Nezapomenu si rypnout: Tezeni neni "statem zajistena investice". Tezeni tady vubec neni proto, aby bylo ziskove, ale aby probihaly bitcoinove transakce. Zisk je jen urcita motivace, ale diky principu dokonale konkurence bude ten zisk v dlouhem obdobi konvergovat k nule. Nikdo nezaruci, ze se vubec nekdy ty asicy za tisice dolaru zaplati. Ale to je riziko podnikani. Vysoky risk - vysoky zisk.
|
|
|
|
I would like to propose the convention that if the wallet sees a field in a protocol buffer that it does not recognise, if that field is 0, false or "" (depending on the type of the field), the wallet can safely ignore the field. I'm affraid that there's no safe solution how to handle forward compatibility by the wallet. I think that if there will be some incompatible messages in the future, clients should ask for wallet version (part of Features message) and then pick appropriate set of messages. This may turn into the mess when wallet developers won't be sane enough, but I'm also affraid of wallet which will try to recover from some messages which it doesn't fully understand... As it stands, nanopb currently doesn't allow this (it skips all fields it doesn't recognise). But I'm sure it's possible to modify the runtime decoder to follow this convention.
Forking protocol buffer standard? No way, at least not for me :-). I see the approach slush has taken is to include a "Features" message which enumerates a wallet's features. I think a features list is somewhat open to interpretation.
I'm affraid of "partial support" of some features. Once you support OTP/PIN messages or not. I'm writing test suite which should cover 100 % of device use cases, so I believe this test suite will help developers to be sure all "features" are well implemented. For example, what happens if a wallet only supports a subset of feature X? Does it report that it supports feature X or not?
It should not report support for some feature which is not fully implemented. As I said, we're handling with valuable information and we should not try to recover from unexpected state by heuristic or some guessing. |
|
|
|
You would think "Phoenix" would be a word you could use, but it didn't fly, and neither did "Firebird", and then even "Firefox" took licensing agreements because a EU trademark turned up later. The Diamond "Viper" video card name had to be licensed from a car alarm company. A EU or US name has a trademark infringement if it can be put in a category (numbered above) where there is a previous trade use.
Are trademarks valid also for categories which are out of business for trademark holder? I mean - can Disney really protect "piglet" for some electronic gadget? Btw Honda Firebird is also motorbike and Dodge Viper is a car. I'm not affraid that Disney will go over us with USB gadget (as far as we won't misuse Disney's piglet images). |
|
|
|
In a round-about way... please just don't make this specific to hardware supporting USB.
As far as Jim and Alan will be open to implement support for Pigeon transport, there's no limitation in protocol itself. |
|
|
|
|
Isn't "piglet" casual english word?
Btw I don't see "Bitcoin hardware wallets" in the list ;-).
|
|
|
|
|
We don't plan this, as device itself isn't full bitcoin client and it cannot check transaction validity. For now we're focused more on making secure wallet than on mobile payments.
|
|
|
|
|
Bounty is still open, although we slowly inclines to the "Piglet". There's no hurry in closing the bounty, but as far as there won't be a better proposal, we'll choose this.
If we'll choose "Piglet", I'm also going to pay for "Oink", because I'm quite sure I'll use such lovely name for something related :-D.
|
|
|
|
|
I just added the chapter "How to encode protobuf message into the stream?"
|
|
|
|
I would suggest starting with a message protocol that would be workable over a simple RS232-like serial line. Start with the assumption that basic error detection and recovery will be needed, so the protocol isn't restricted to media that has it built in. Then worry about adding abstractions to it like chunking. USB-CDC and bluetooth can both abstract a serial line "out of the box". If you invent a protocol that's centered around USB-HID, then nobody who wants to extend that protocol to work over TCP/IP or radio waves or named pipes or tin can telephones or light sensors vs flashing boxes on a screen or any of the other useful ways to move data is going to want to deal with implementing "USB-HID" contingencies where they aren't needed.
Firstly, don't forget that we're not inventing new internet, but just specialized protocol for talking with quite a dumb device. Secondly, protocol itself (PB) isn't specific for some particular transport. And integrity checking should be a part of the transport itself, not the part of application protocol built on top of it. Shortly said, it is possible to use the same protocol as described above over TCP without any modification. |
|
|
|
Timeout
Strictly speaking, device itself is just a state machine. I don't think defining some timeout is required. Computer can reset the device at any time by sending "Initialize" message, as I defined above. From computer perspective, some "Ok, nothing happened" is completely implementation dependent and we don't need to specify this. Confirmation dialog can be opened for unlimited time and nothing wrong happen... In 'Standard message flow, first paragraph' you mention that the computer initiates the conversation but with the PIN and OTP the device sends the PinRequest / OTPRequest. Do these occur as responses to the GetEntropy computer request only ?
PinRequest and OtpRequest can basically appear as a response for any sensitive call. GetEntropy was just an one example. I personally implement Pin/Otp handling in bitkeylib (python) independently to the call itself. When device respond with PinRequest or OtpRequest, library simply ask user for input. C: GetEntropy()
D: Entropy(entropy)
or
C: GetEntropy()
D: OtpRequest()
C: OtpAck(otp)
D: Entropy(entropy)
or
C: GetEntropy()
D: OtpRequest()
C: OtpAck(otp)
D: PinRequest()
C: PinAck(pin)
D: Entropy(entropy)
also, is it valid to have the PinRequest/PinAck before the OtpRequest/OtpAck ?
Yes, all these combinations can happen. Although asking for Otp before Pin make sense, it makes guessing/bruteforcing of the pin almost impossible, because very attempt requires unique OTP... Does the bytestream for USB have guaranteed integrity ? IE is it necessary to have a checksum for each of the 64 byte message or is that taken care of in the transport protocol ? If required we could simply have 1 checksum byte = XOR(payload bytes) i.e.
USB HID is very simple protocol and yes, it guarantee the order and integrity. So no need for adding it manually. Also, you state that the PB message is chunked into 64 byte packets. When they are 'dechunked' how do you know the boundaries of the packets to stitch them back together to recreate the PB messages? Do you need "this protobuf message is chunked over X packets' at the beginning of the PB message.
You're right, I completely forgot to describe "magic character" and "message size" while encoding PB message into the stream. I'll complete the documentation above now. I am just thinking of how to make the 'chunking' and 'dechunking' as simple and unambigous as possible. Ideally you want it a dumb transport layer that understands nothing of what is in the messages.
That's exactly how I defined it. There are three layers: 1. Transport - it just transport bytes from one side to another. I want to have only one transport based on USB HID in the specs, but technically it is possible to use serial port or system sockets as well. As I said, I'm already testing the protocol using named pipes. Part of transport specification is (for example) that one byte defining message length (report id in term of HID). 2. Stream encoding/decoding. It contains magic character + PB message length, to make decoding of the stream as easy as possible. I'll complete the docs above. 3. Payload encoding/decoding. I proposed Protocol Buffers, which seems to be pretty good choice for our needs. Whole messaging stack doesn't need to understand transferred messages themselves, so everything is very flexible. |
|
|
|
Tak tedy vítej. Jak se díváš na obrovský pokrok v adopci aka wordpress?
Já to vidím jako perfektní zprávu, myslím že bitcoin půjde v ceně nahoru. Už jenom kvůli tomu že fiat jde dolů.
Mtgox po oznameni WP okamzite zareagoval rustem, coz znamena, ze lidi si obecne mysli, ze to je pozitivni zprava. Ja taky :-). Pod tim oznamenim jsem cetl nekolik prispevku typu "ani jsem nevedel, ze neco takoveho existuje". A prave takova pomala adopce je ten nejlepsi zpusob, jakym by mel bitcoin jit - lide mohou cist o bitcoinu i v jinem svetle, nez ze lze "vydelavat zadarmo" (mining) nebo "zase nekoho okradli" (hackovani). |
|
|
|
Man I can't wait to buy one of these. Any ideas about the price yet?
I don't like false promises and there're still so many open questions. Price is driven mostly by cost of casing and count of devices built in one round/series. Although we can guess the price of casings pretty soon, we still don't have any estimation for size of the market. Price per device for 100 devices can be many times higher than for 10000 devices... |
|
|
|
Want crazy talk? How about Bluetooth?
No way because of battery... Edit: However HID over Bluetooth is still possible, so even if we will standardize HID device, some future wallet devices can use Bluetooth and still have compatible protocol. |
|
|
|
|
Show Posts
