Новичкам сюда! - FAQ

[m0Ray]

Итак, подписывается каждая транзакция. "Когда пользователь А передаёт некоторую сумму пользователю Б, публичный ключ меняется на публичный ключ пользователя Б и подписывается приватным ключом пользователя А" <- из википедии

Угу, это я написал, но это не совсем точно.

берем где-нибудь 100коинов. Хоть на бирже.
берем два самых дешевых vds-сервера а разных датацентрах. (подальше друг от друга)
на одном vds запускаем клиента. Клиент выкачивает блоки, и создает базу ip-адресов нодов. Дальше мы этому клиенту кидаем 100коинов, ждем завершения транзакции, и закрываем его.

дальше мы берем базу данных узлов и делим ее пополам на 2 равные части, по кол-ву строк. Пофайлово мы создаем на 2м vds копию клиента, и кошелька с первого vds. Но теперь мы на первый vds кидаем одну половинку базы, а на второй - другую. Получается, что на каждом vds своя база узлов. Ставим права на файл 0444 (ну то есть от записи его защищаем) на обоих серверах.

Получается, что мы как бы "разрезали" всю p2p сеть на 2 части.

Не совсем понятен смысл этого "финта ушами". Вы не "разрезали" сеть, а всего лишь сделали так, что ваши VDS точно не соединены между собой ровно через один узел. Другие-то узлы между собой по-прежнему соединены.

на одном из vds генерируем новый "your bitcoin address". Я так понял, когда такое делаешь, то коины не пропадают, а ключи становятся другими.

Вот с этого места начинается интересное. Ключи-то другими не становятся, просто создаётся новая пара ключей, с которой можно проводить транзакции. Ранее проведённая транзакция как была подписана старым ключом, так и осталась.

и потом с обоих клиентов на наш счет одновременно отправляем разное количество биткоинов, но более 50коинов с каждого клиента.

Пока сумма новых транзакций, ссылающихся на старую, не превышает 100, они будут валидны и упакуются в блок. Упаковщик-то это проверяет. Как только этот блок будет решён, о нём быстро узнают все остальные узлы.

Если я правильно понял принцип, обе транзакции должны быть валидны, а на нашем счету окажется более 100 коинов. Профит!

Выясняется, что не совсем правильно.

[1713429469]

1713429469

[1713429469]

1713429469

[chabapok]

получается, что новый адрес можно не генерить.

Пока сумма новых транзакций, ссылающихся на старую, не превышает 100, они будут валидны и упакуются в блок. Упаковщик-то это проверяет.

упаковка в блок происходит на узлах. А мы сделали "финт ушами" (тот самый, смысл которого вам не был понятен), благодаря которому упаковщик на каждом узле увидит только 1 транзакцию, а не 2. а 1 транзакция сама по себе валидна.

[m0Ray]

Пока сумма новых транзакций, ссылающихся на старую, не превышает 100, они будут валидны и упакуются в блок. Упаковщик-то это проверяет.

упаковка в блок происходит на узлах. А мы сделали "финт ушами" (тот самый, смысл которого вам не был понятен), благодаря которому упаковщик на каждом узле увидит только 1 транзакцию, а не 2. а 1 транзакция сама по себе валидна.

Во-первых, транзакции тоже расползаются по сети, как и блоки, узлы обмениваются этой информацией.
Во-вторых, если блок с одной транзакцией упакуется, он так же расползётся по сети и будет свидетельством того, что часть денег потрачена. Два блока параллельно существовать не могут, как мы уже выяснили.

[chabapok]

Во-первых, транзакции тоже расползаются по сети, как и блоки, узлы обмениваются этой информацией.

если у нас было 2 равноправные условно-валидные (без учета соседа) транзакции, то в общем случае их скорость распространения по сети одинакова.

Во-вторых, если блок с одной транзакцией упакуется, он так же расползётся по сети и будет свидетельством того, что часть денег потрачена.

Значит делаем 1000 таких попыток в автоматическом режиме. Кто-то какая-то транзакция упакуется в блок и дальше не заапрувится, а какая-то прокатит.

Два блока параллельно существовать не могут, как мы уже выяснили.

ээ. То есть может и не могут, но это выяснили только вы, а мне пока это не очевидно. %)


кто принимает решение валидно/не_валидно? узел, который упаковывает транзакцию в блок? и что у нас получится:

а) чаcть узлов будут знать только о транзакции с VDS1
б) часть узлов будут знать только о транзакции с VDS2
в) часть узлов будет знать только о обеих транзакциях.

при помощи "финта ушами" мы понизили вероятность узла оказаться в группе в). Узлы из группы в не заапрувят обе или какую-то одну транзакцию. А вот узлы из групп а) и б) - пропустят их. Они упакуются в блок, а значит станут валидными

p.s. мой клиент скачал блоки и действително нагрузка на винчестер стала меньше, но вот тут http://blockexplorer.com/q/getblockcount написано, что известно 124328 блоков, а мой клиент скачал только 122797 и приступил к рассчетам. Означает ли это, что он считает 122798 блок, который где-то уже посчитан? то есть получается, что комп трудится над задачей, которя уже решена (и стало быть при ее решении не начислится 50 бтц)?

[m0Ray]

Во-первых, транзакции тоже расползаются по сети, как и блоки, узлы обмениваются этой информацией.

если у нас было 2 равноправные условно-валидные (без учета соседа) транзакции, то в общем случае их скорость распространения по сети одинакова.

Но достаточно велика. Впрочем, это не важно.

Во-вторых, если блок с одной транзакцией упакуется, он так же расползётся по сети и будет свидетельством того, что часть денег потрачена.

Значит делаем 1000 таких попыток в автоматическом режиме. Кто-то какая-то транзакция упакуется в блок и дальше не заапрувится, а какая-то прокатит.

Два блока параллельно существовать не могут, как мы уже выяснили.

ээ. То есть может и не могут, но это выяснили только вы, а мне пока это не очевидно. %)


кто принимает решение валидно/не_валидно? узел, который упаковывает транзакцию в блок? и что у нас получится:

а) чаcть узлов будут знать только о транзакции с VDS1
б) часть узлов будут знать только о транзакции с VDS2
в) часть узлов будет знать только о обеих транзакциях.

при помощи "финта ушами" мы понизили вероятность узла оказаться в группе в). Узлы из группы в не заапрувят обе или какую-то одну транзакцию. А вот узлы из групп а) и б) - пропустят их. Они упакуются в блок, а значит станут валидными

Обе они в один блок не упакуются, потому что какая-то из них приводит к перерасходу средств. Если, например, транзакция с VDS1 упакуется в блок N, транзакция с VDS2 в блок N+1 не пройдёт, потому что блок N известен упаковщику. Если же он будет упаковщику неизвестен, значит, он считает только ещё блок N, причём ветку, которая, вероятно будет отсечена. Или же отсечена будет ветка, в которую попала транзакция с VDS1, и тогда останется только та, что с VDS2. Повторяю: цепочка блоков не ветвится, у одного блока может быть только один предшественник.

p.s. мой клиент скачал блоки и действително нагрузка на винчестер стала меньше, но вот тут http://blockexplorer.com/q/getblockcount написано, что известно 124328 блоков, а мой клиент скачал только 122797 и приступил к рассчетам. Означает ли это, что он считает 122798 блок, который где-то уже посчитан? то есть получается, что комп трудится над задачей, которя уже решена (и стало быть при ее решении не начислится 50 бтц)?

Не факт что решена. Но когда она решается, сеть об этом достаточно быстро узнаёт. Разбег может составлять несколько секунд,  а при среднем времени счёта блока в 10 минут это малосущественно.

[chabapok]

Не факт что решена. Но когда она решается, сеть об этом достаточно быстро узнаёт. Разбег может составлять несколько секунд,  а при среднем времени счёта блока в 10 минут это малосущественно.

Примерно ясно. Спасибо за ответы. Щас я напишу тогда что понял, и если не правильно, то меня, надеюсь, поправят

1. Транзакция упаковывается в блок. Только в 1 блок. Так?

2.Каждый блок считается на основе предыдущего блока и на основе нескольких случайных транзакций и требует фиксированного количества операций хеширования, и использует для рассчетов фиксированное кол-во транзакций. Так?

3.каждый блок имеет индекс, который определяет как далеко этот блок отстоит от самого первого "материнского" блока. Так?

4. Необязательно, чтобы блоки с одинаковыми индексами были одинаковы, но если клиенту приходит по сети блок с индексом N, то клиент имеет возможность довольно быстро проверить  Является ли изветсный N-1 блок источником для пришедшего N-го блока, и в случае если нет, выкачать правильный блок и рекурсивно выполнить эту проверку снова. Так?

5. в краткосрочной перспективе получается, что возможно существование двух разных блоков с одинаковыми индексами, то есть двум узлам, которые их сгенерили будет начислено 50 бтц, но когда произойдет отброс какой-то из веток, то 50бтц у одного из узлов заберут, потому что блок оказался не в главной ветке. можно успеть эти 50 бтц перевести куда-нибудь, тогда эта транзакция обязатенльно попадет в главную ветку, но если ты (или софт) не успел это сделать - ССЗБ, и 50 коинов будут утеряны. Так?

6 когда клиент считает блок N, то для рассчетов используется
- предыдущий блок
- несколько транзакций упорядоченный случайным образом
- собственный адрес

и поскольку кол-во хешей для рассчется блока фиксированно, то время его рассчета тоже фиксированно, и поэтому если твой комп считает блок меньше 10 минут, то даже пытаться считать блоки нет смысла, потому что ты просто не успеешь посчитать блок N прежде, чем где-то в сети посчитают N+1 блок, который при отсечении веток будет иметь больший приоритет. Так?

[JohnSmith]

а) чаcть узлов будут знать только о транзакции с VDS1
б) часть узлов будут знать только о транзакции с VDS2
в) часть узлов будет знать только о обеих транзакциях.

А и Б не сработает, т.к. узлы А узнают от узлов Б и наоборот.
Наверное такое возможно при физическом разделении узлов, например если у провайдера отвалится внешка то узлы продолжат контактировать внутри сети и строит свои цепочки блоков, но внешние узлы будут строить цепочки быстрее и когда узлы снова объединяться левые ветки из "локалки" будут отброшены. А вот обмануть внутренние узлы наверное можно, продав им в этот момент бтс, например.

[LZ]

Если потратить 50 BTC из ветки, которая будет отсечена,
после отсечения любые трансакции с применением этих
50 BTC не будут валидными, так как для всех узлов эти
50 BTC уже не будут существовать. По этому серьезные
проекты вроде Mt.Gox ждут целых 6 блоков (это ~1 час).

JohnSmith, свои узлы всегда можно обмануть, так как это свои узлы.

[chabapok]

По этому серьезные проекты вроде Mt.Gox ждут целых 6 блоков (это ~1 час).

хех, так получается, что когда генерация коинов прекрастится (2033год), то получается, что прекратится майнинг и генерация блоков. то есть блоки генерировать будут, но не так быстро и платно. И получится, что во-первых транзакции с ожиданием 6 блоков станут очедь долгими, а во-вторых,

еще получается вот такая штука:
комиссия 0.01коин за ускорение транзакции и сама транзакция - это как бы получается что 2 разных транзакции, которые независимы. То есть может возникнуть такая ситуация, что комиссия 0.01 снялась, а сама транзакция не прошла.

[Yurock]

Куда же делись русские доки по биткоину?

[aistto]

Куда же делись русские доки по биткоину?

А они когда-нибудь были?

[chabapok]

нашел с большим трудом английские
читаю
местами тоже бестолковые, а кое-где нормальные
вопросов отпала.

но если доки хорошо пойдут - будет еще 1 идея как обмануть систему. %)

[Vort]

...то есть блоки генерировать будут, но не так быстро и платно...

система балансируется таким образом, чтобы блоки генерировались со скоростью ~ 1 блок в 10 минут

[chabapok]

да, это я уже понял, что если время генерации большое - постепенно увеличивается минимальный порог разрешенного хеша

а вот как может быть такое: http://blockexplorer.com/block/00000000000233334b157d901714baf59e5b9236227b2878844e52244da4195e я пока не понял.
то есть понятно, что 50 коинов расписали по разным кошелькам. но почему? Ответ, который напрашивается - так проще было подобрать nonce.

второй ответ - это кошельки майнеров в пуле, но если так, то хреновый это майнер.
"правильный" майнер должен
1. игнорировать все транзикции кроме генерации 50 бтц, потому, что чем больше транзакций, тем меньше хешей в секунду выполняется.
2. ставить текущее unixtime на 1:40 больше реального, чтобы у блок выглядел более поздним и чтобы у него было больше вероятности оказаться в main-ветке

оба пункта для системы вцелом плохи, но для отдельного майнера выгодны

[checker]

Русские доки упали после хаброэффекта. Отчасти это моя вина.Ну не ожидал я такого роста посещаемости сайта на pentium3 ... теперь вот никак реанимировать не можем... доступ к пеньку сильно ограничен.

[Arceny]

Русские доки упали после хаброэффекта. Отчасти это моя вина.Ну не ожидал я такого роста посещаемости сайта на pentium3 ... теперь вот никак реанимировать не можем... доступ к пеньку сильно ограничен.

Хотя бы сделайте бекап, и потом на какую нить vds... нафик пенек!

[Yurock]

Может, закинуть тексты сюда? https://ru.bitcoin.it/

[aistto]

Может, закинуть тексты сюда? https://ru.bitcoin.it/

Хотя бы в файлообменник какой-нить закиньте

[m0Ray]

Не факт что решена. Но когда она решается, сеть об этом достаточно быстро узнаёт. Разбег может составлять несколько секунд,  а при среднем времени счёта блока в 10 минут это малосущественно.

Примерно ясно. Спасибо за ответы. Щас я напишу тогда что понял, и если не правильно, то меня, надеюсь, поправят

1. Транзакция упаковывается в блок. Только в 1 блок. Так?

Да.

2.Каждый блок считается на основе предыдущего блока и на основе нескольких случайных транзакций и требует фиксированного количества операций хеширования, и использует для рассчетов фиксированное кол-во транзакций. Так?

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

3.каждый блок имеет индекс, который определяет как далеко этот блок отстоит от самого первого "материнского" блока. Так?

Да.

4. Необязательно, чтобы блоки с одинаковыми индексами были одинаковы, но если клиенту приходит по сети блок с индексом N, то клиент имеет возможность довольно быстро проверить  Является ли изветсный N-1 блок источником для пришедшего N-го блока, и в случае если нет, выкачать правильный блок и рекурсивно выполнить эту проверку снова. Так?

Да.

5. в краткосрочной перспективе получается, что возможно существование двух разных блоков с одинаковыми индексами, то есть двум узлам, которые их сгенерили будет начислено 50 бтц, но когда произойдет отброс какой-то из веток, то 50бтц у одного из узлов заберут, потому что блок оказался не в главной ветке. можно успеть эти 50 бтц перевести куда-нибудь, тогда эта транзакция обязатенльно попадет в главную ветку, но если ты (или софт) не успел это сделать - ССЗБ, и 50 коинов будут утеряны. Так?

Нет.  В случае генерации конкурирующих блоков никто никому ничего не добавляет и не забирает. Сгенерировавший блок первой транзакцией прописывает себе 50BTC. Если этот блок оказывается недействительным, сгенерировавший просто не сможет в транзакции перевода сослаться на валидную транзакцию генерации, потому что этого блока не будет в цепочке.

6 когда клиент считает блок N, то для рассчетов используется
- предыдущий блок
- несколько транзакций упорядоченный случайным образом
- собственный адрес

Да.

и поскольку кол-во хешей для рассчется блока фиксированно, то время его рассчета тоже фиксированно, и поэтому если твой комп считает блок меньше 10 минут, то даже пытаться считать блоки нет смысла, потому что ты просто не успеешь посчитать блок N прежде, чем где-то в сети посчитают N+1 блок, который при отсечении веток будет иметь больший приоритет. Так?

Нет, см. выше. Даже самый слабый комп теоретически может решить блок раньше всей сети. Вопрос в вероятности такого события.
Генерацию блока можно сравнить с лотереей, а вычислительную мощность в мегахэшах - с количеством билетов у тебя в руках.

[rage911]

хехе, я вот тут смотрю на вашу беседу со стороны и понимаю что ничего не понимаю из сказаного : ) Какие-то подозрительные фразы и нездравые суммы мелькают вроде 50..100 бтсов )). Вы на выделеных серверах чтоли майните? Гуру, научите меня своему кунг-фу ) Есть ли вообще смысл майнить с 1 компа? Если на выделеных майните - буду рад подробностям. Ну и если не влом - запостите плз ссылки на факи что на ваш взгляд наиболее понятные и содержательные, можно даже те что на английском.