It's not a secret that most of BT traffic is illegal and violates copyrights. If people will make money on such things it will give copyright holders more reasons to blame BT. It should be discussed though.

Потом доходы будут от комиссий за переводы, которые получит тот, кто сгенерит блок. Он получит комиссию со всех транзакций, прошедших с момента генерации прошлого блока. Но это будет ещё очень нескоро, и механизм комиссий пока что практически не используется.

Вот эт правильно. Не вижу проблемы с написании даже критичного к скорости софта на связке Python+Cython. Первый для гуя и других вещей, второй — для числодробилки. Лично сравнивал скорость молочения SHA256 на Це и Сайтоне, идентичны в пределах погрешности. Сайтон даже немного вперёд вырвался в отдельных итерациях, так что будем считать, что одно и то же. Для расчёта хэша взял реализацию из OpenSSL (вызывал из библиотеки), в общем, вышло ~1400 kh/sec, биткоин генерирует на той же системе порядка 2300. Но оно и понятно, я генерил в один поток, а ядер два, если параллелить, должно получиться на уровне. Опять же, хэши считались просто от чисел 0-10000000.

Я говорю «биткоины» (не «биткойны»), нормально и кратко звучит. Незачем искусственно удлинять название, тем более, когда оно иностранного происхождения в принципе.

Мне вот интересно, NewLibertyStandard переводчиком пользуется или сам пишет? Местами ошибки напоминают гуглотранслейтные, а местами ясно, что автоматически так не перевести никак. Например, «с начало».

Сейчас прочитал про CUDA-клиент, который выкупили за сумасшедшие бабки. Да, вполне вероятно. Надо б тоже собрать, хотя были проблемы с wxWidgets, что-то у них с расположением заголовков туго.

http://bitcointalk.org/index.php?topic=151.msg13550#msg13550 — поправил перевод, теперь работает гладко. В комплекте bitcoin.po и bitcoin.mo (скомпилированная версия). .mo можно кидать в locale/ru/LC_MESSAGES, проверено на Linux и Windows 7.

Эм... ты плохо читал технологию работы биткоин? Подтверждения == блоки после твоей транзакции. Чем больше блоков прошло (было принято сетью), тем достовернее транзакция. Блок создаётся раз в десять минут, в среднем по сети. Т.о., 3 блока за 10 минут — это слишком быстро, что и подтверждает рост сложности (в соседнем топике я пояснил).

Изменения есть, притом, пугающие. Смотрим на топик. 29 августа сложность была 623. Сейчас она 917.8. Рост в полтора раза менее, чем за месяц! Мне видится буйная дефляция, так как генерировать монеты становится всё менее выгодно. Например, на моём E5400 выдаётся около 2100 килохэшей. Значит, теперь мне придётся гонять машину непрерывно 917.8*2^32/2100000/3600/24 == 21.72575 суток! И получить за это всего 100 рублей? В общем, либо цена пойдёт вверх, либо ноды начнут выходить из генерации. В обоих случаях будет достигнута равновесная цена, надеюсь.

Updated russian translation. Now works fine without issues. Hope it will be included in the next version.

Hmm, now the bug is gone though I remember how it was. That's the compiled release binary, 0.3.12 as I already mentioned. I didn't use -connect. Flickering was fast from 0 to 2 (less than half second) and then there was a pause in about a second with 0 connections. So the flicker itself was almost every second (not faster). Looks like it got connrefused instantly or such. I watched logs, sorry didn't saved them but there was nothing interesting just connect and disconnect without a reason.

I measured the RES memory with htop. It updates once per second that's why I can't see the real leak speed. Now the client tries to connect after startup and flickers 0-2, too, but just 5-10 times and then establishes one connection. Then it flickers between 1 and 3 and no leaks happen. Then connection number grows up to 40 or even more, everything is stable. To reproduce this try to switch off the network connection right after the client gets IPs from IRC so it will try to connect and fail.

It's pretty random. Now you can generate some and don't have even one in 1-2 months. Who knows. It's a question of luck. Take a look at this thread. That's the guy whose luck you drain.

Sometimes a DNS address resolves to several IPs. Try nslookup google.com. Should we try them all?

Well, it may be real. I don't know if a particular node accept block if there are missing transactions in it which are certainly known by this node. If so, transactions can't be cancelled and an attacker could generate as many blocks as he wants but chain won't grow for anybody except him. But the weaknesses page states that he can. Maybe it should be discussed. Also, I'm interested in how can such powerful attacker reverse his transactions? I suppose it's already sent and other nodes got it. If there were no blocks with this transaction inside then yes, he can send another one or just don't include tx in the generated block. But who will trust such unconfirmed txs? And if he issue some blocks with his tx in first of them how can he later cancel them all? Other nodes already got this sequence. He'd regenerate that latest blocks (fork them like there was no tx) while he should continue generating valid blocks for the current branch or somebody in the rest generate first. And that false branch should grow even faster than main. It will require more and more power.

The client would always choose the longest branch if there are two with perfectly valid blocks but different txs? Am I right? What happens with txs in the shorter branch? If they're transferred what if a conflict detected (for example different number of coins sent from the same address)? Which one will client choose?

Let's do some fun math. I have E6750 CPU with 5425 BogoMips on each core. I do 2200 khash/sec so it's 2200000/(5425*2) ~= 203 hash/Mip. Now look at the difficulty; it's 712.88486455 now. So the network does 712.88486455*2^32 ~= 3061817179056 hashes per 10 minutes. Now we can estimate its power in Mips, 3061817179056/203 ~= 15082843247 Mips ~= 15 Pips. Here is a world most powerful supercomputer: http://www.top500.org/system/performance/10184 It has only 2 Pips in peak and maximum 1.7 Pips (don't really get the difference between max and peak, maybe max is an average maximum and peak is a one time performance shot). I don't remember what's the threat of the overpowering of the network but it looks like the attacker will need about 9 such computers for successful overpowering. I guess it's highly ineffective for such tasks and want to congratulate us all for participating in such a big and powerful network (although we do pretty absurd job in mathematical sense).

I have an unusual configuration: on my headless gateway there is bitcoind running and on my desktop standart bitcoin is running (both Linux OpenSuSE, gateway 11.1, desktop 11.3, bitcoin 0.3.12 both). TCP port 8333 forwarded on gateway to the desktop (so gateway client can't has incoming connections). I don't know why but when I start desktop client after gateway's one the desktop client can't connect and flickers between 0 and 2 connections for a long time. Eventually it may connect but while it can't the memory leaks badly. About 200Kb/sec (each 0-2 change). It may not be noticed if the client connects instantly but in my case it doesn't. If I start first the desktop and then the headless client (after the desktop one has connected) everything is fine and no leaks (or they are little enough). I guess there is unfreed memory in bootstrap function or somewhere in the bootstrap process.

Do you have the same problem with russian text in the main window?

Aren't those first 50 coins will be tracked and bound to the reciever address hence shown in the balance sheet? Everyone could check whether this particular 50 coins were given to anyone or are still yours. If I understand it right, balance sheet is generated from the existing chain so if at the time when you want to doublespend the balance shows these coins assigned to anyone else your transaction won't be accepted.

The idea is nice, however there may be flaws. I don't know exactly how coins are generated, are the numbers produced checked against previously generated coins? Is there a possibility to generate a coin twice if you don't have the whole chain? Anyway, something like this (snapshotting/sheets) should be implemented or we eventually get this chain grow like cancer. This will push away newcomers.

Everything in p2p is based on majority trust, so if most of clients create equal snapshots (of small size, of course), newcomers would trust it and assume the proof-of-work was done honestly. We even can delete the whole chain leaving only the snapshot after some time. If we do the sheet every 10k blocks, newcomers would download up to 9999 blocks, about 3 blocks/sec so it will take less than hour to start. Pretty acceptable I think.

Well, sounds pretty convincing. The interesting point is how many circulating coins there will be in the world after some years... We'll see.


I'm happy that you build a nice idea upon mine. There is many points to discuss so I'll answer there.

Well, it's hard to estimate the coins lost so we don't know how many of them currently circulate. Anyway, I'm just interested in _possibility_ of such reclaiming, I don't insist it should be done in the software in any way. Just in theory, can we somehow check when the particular coin was spent last time? If yes, then if (when) in future we'll have too few coins left, there will be a way to reclaim that were lost. The timestamps are stored in blocks, AFAIK, so it may be possible. The check period may be a year or so, if you didn't run your client within a year at least once, your wealth will be treated as lost. To confirm your ownership you can (for example) make a transaction to the special address that won't be counted but accepted as pong. As it will be done once a year, it won't overload the network. Will this scenario potentially work or I completely misunderstand some principles?