Topic: Новичкам сюда! - FAQ - page 318. (Read 1688108 times)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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


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

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

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

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

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

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


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

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

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

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

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

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

Ну так-то да, вычислительная мощность "50 компов" для этого должна значительно превышать мощность сети. И гарантии всё равно нет - сеть может успеть сгенерить 6-й блок, пока "50 компов" телёпаются с 5-ю.
И бесконечности тоже не получится: есть предел в 21М.

Это если так понимать вопрос.

скажем так, ответы модифицировали  этот вопрос в другой вопрос

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

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

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

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

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

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

Если я правильно понимаю, то для этого надо создать поддельную цепочку из (вроде 5 для подтверждения) блоков, для чего вычислительная мощность модифицированных клиентов должна превзойти мощность не модифицированных. В этом просто нет смысла. А запустить 50-100-1000 клиентов можно и на одной машине.

Клиент должен сначала скачать имеющиеся блоки, что он и делает при первом запуске. Плюс индексирует их. Отсюда нагрузка на винт. Потом она прекращается.
Кстати, винт программно убить практически нереально.

Да. Причём задействует только центральный процессор. Для генерации с использованием GPU нужны отдельные программы.

Да. В остальных файлах - скачанные блоки, индексы, логи и т.п. А это всё дело наживное, главное же - приватные ключи ваших транзакций в wallet.dat. В винде ищите это в Documents and Settings/%USERNAME%/AppData/bitcoin, в линухах - .bitcoin в домашнем каталоге юзера

Во-первых, можно соединиться вручную. Где-то есть список bootstrap-узлов.
Во-вторых, ведутся работы на тему bootstrap-а по DNS.

UPD: залез в исходник, уточнил. Первым делом оно пытается слазить в IRC и там опубликовать свой адрес и взять несколько чужих. Если не получилось - пользуется DNS. Если и с этим облом - есть вшитый массив айпишников. Так что в свежих версиях всё нормально с этим, насколько может быть нормально в p2p-сети.

Он не нагенерил, а скачал из сети.

Потому что такие блоки не будут приниматься остальными узлами как правильные.

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

Нет, подписываются транзакции. При передаче монет транзакция или собирается из более мелких, либо режется более крупная.

Стираться ничего не будет. Для уменьшения размера БД будет применятся Merkle Tree, нечто вроде TTH.
Подкрутить не выйдет: "накинуть койнов" можно только из какой-либо транзакции. Если транзакция не существует, не существует и койнов. Проверить же наличие заявленной транзакции элементарно.

Наверное, это настолько хитрая схема, что даже я ничего не понял. Что значит - "подтверждают"? Кто кому платит, какие коннекты и зачем контролировать - ни фига не понял. Изложите поподробнее, если ответы на предыдущие вопросы ещё не сделали его бессмысленным.

1 - он загружет всю цепочку блоков сразу после первого запуска. Ничего пока не генерируется. Посмотри какая циферка должна быть http://blockexplorer.com/q/getblockcount

Сорри, если мои вопросы слегка ламерские. Ознакомился вкратце с принципом системы, но очень много непонятного, и есть большие сомнения насчет невозможности взломать систему или ее проконтролировать

1. скачал клиента с биткойн.орг и запустил под убунтой.  Галочки "generate coins" не стояло, но он начал считать блоки (по крайней мере циферка внизу увеличивается) а так же писать что-то на диск, в результате hdd шуршит головками постоянно. Насколько я понял, для просчета блоков требуются вычислительные ресурсы, а не "дисковые". Почему же клиент шуршит винчестером? под виндой он себя так не ведет. Говнокод?
В конечном итоге я решил, что лучше выключить клиента совсем, а то убьет мне винт. Под виндой подобного эффекта не наблюдалось.

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

3. Вот все говорят что коины хранятся в файле кошельков. А где этот файл? клиент кучу логов нагенерил разных, а кошелек - это только wallet.dat? То есть, остальные файлы бэкапить необязательно?

4. я вижу слабое место в системе - для того чтобы п2п коннект состоялся, нужно знать айпи хоть одного пира в системе. Это не проблема, если клиент долго работал - тогда он знает айпишники, с которыми работал. А если человек выкачивает клиента с сайта, то там как правило нет адресов пира, и (насколько удалось понять из исходников), ему просто неуоткуда взять адрес пира, кроме как из irc канала. irc падает - и в системе не смогут появляться новые участники.

5. насколько понял, бонус в 50 бтц получает клиент, сгенеривший блок. я запустил клиента он за несколько сек нагенерил тысячи блоков, а бонуса нет Это наводит на мысль, что блоки бывают двух типов - за которые есть начисления в 50 бтц, и за которые нету. Почему я должен заниматься генерацией тех блоков, за которые не дают бтц?

6. пишут, что после каждых каждых 210 000 блоков вознаграждение уменьшается в 2 раза. Но ведь вознаграждение начисляет клиент сам себе? Значит, можно в исходниках недельку покопаться и подкрутить, чтобы начисляло за раз не 50 бтц, а больше. почему так никто не делает?

7. что будет, если два клиента посчитают один и тот же блок? Они же каждый начислят себе одни и те же бтц, и получится дублирование? Как потом определить чьи это биткойны?

8. как вообще биткоины представляются? Если они делятся до 8го знака после запятой, то это получается, что каждый 0.00000001 биткойн имеет свой айдишник, защищенный контрольной суммой? Или защищен весь кошелек? Но если суммой защищен весь кошелек, то

9. если транзакции валидность моих кошельков хранятся на компах у клиентов, то ведь получается, что со временем данных будет все больше и больше, а поскольку местона винчестере не резиновое, данные будут периодически стираться, и может возникнуть ситуация (если долго не пользовал систему), что все данные про меня будут забыты? И что в этом случае будет? Или система не даст воспользоваться кошельком, или можно будет подкрутить свой кошелек и накинуть ему еще чуток коинов

10. можно ведь создать сеть, например из 50 компов, на которые "эмулируют" клиентов, и занимаются лишь тем, что подтверждают, что клиент ААА имеет БББ коинов. коннекты клиента БББ можно сделать контролируемыми, чтобы коннектился только в ААА и к тому, которому хочет проплатить. И все! Имеем бесконечный кошелек.

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

Спасибо, попробую.

А сколько подтверждающих блоков требует получатель? Хотя, теоретически, может так получиться, что за целый час не будет найдено ни одного блока и никакая комиссия не поможет. А реально, не думаю, что транзакция с комиссией, например, 1 BTC пройдёт быстрее, чем такая же, но с комиссией 0.05 BTC, например. То есть, есть какой-то верхний предел, выше которого увеличение комиссии практически не придаёт ускорения. Тут ещё многое зависит от размера транзакции в байтах.

Сумма комиссии не зависит от суммы перевода.
Комиссии в 1 битцент на данный момент вполне достаточно.

это тоже не дает гарантии. Вот скажите сколько процентов нужно для ГАРАНТИРОВАННОЙ доставки 100 биткоинов в течении хотя бы часа

Для ускорения транзакции можно заплатить добровольную комиссию.