Мое текущее понимание того, как это работает, полученный из https://en.bitcoin.it/wiki/Transactions, https://en.bitcoin.it/wiki/Script и глядя на сделки в blockexplorer, заключается в следующем. Это, вероятно, легче думать о Bitcoins хранятся на выходах транзакций, каждая из которых имеет значение и связанный с ним Bitcoin адрес (хэш открытого ключа). Можно получить в этих Bitcoins, указав полный открытый ключ для адреса и подписи для сделки. Так как эта подпись может быть создана только с помощью закрытого ключа для этого адреса, только "владелец" по этому адресу можно получить в этих Bitcoins. Каждая транзакция затем говорит "брать * все * Bitcoins, которые были в TxOut Н_1 Тх t_1, N_2 из T_2, ..., [здесь все правильных открытых ключей и подпись] и создать холдинг TxOut в B_1 BTC по адресу a_1, a_2 BTC по адресу A_2, ...",

Там никогда "частичные остатки" хранить при заданном выходе транзакции. Вот почему, когда вы отправляете небольшое количество БТД кому-то, то сделка на самом деле имеет TxIn с большим количеством BTC, и два TxOut, одной с BTC для получателя отправки и один с "изменение" отправлены обратно к вам (по другому адресу, который никогда не показывает в графическом интерфейсе клиента). Смотрите, например, эта сделка: http://blockexplorer.com/tx/56faebec0694f42c201b0afbd2327dc823b8298b3aa4bb3313bab3e2fe026f44.  С другой стороны, может быть много невостребованной TxOut-й в блоке цепи, принадлежащей одному и тому же адрес, так что это не так, что с учетом последней сделки по определенному адресу, вы можете восстановить общее количество BTC, которое может быть отправлено с этого адреса ,


Вы должны знать, сделку с невостребованным TxOut лет по адресу, который вы отсылаетесь. Вам не нужно хранить всю blockchain, хотя в настоящее время, вы должны быть загружены и проанализирована blockchain, начиная с того времени, когда адрес отправителя первым был никакого Bitcoins. Например, BitcoinJ (библиотека Java) содержит список адресов, которые принадлежат вам. Всякий раз, когда он получает новый блок на конце основной цепи, он сканирует его для операций с любым из ваших адресов в TxIn-й или TxOut, и сохраняет локальную копию этих операций. Он игнорирует все остальное в блоке. В будущем, по-видимому будет путь либо (а) с просьбой доверенной службы или несколько ваших коллег для всех последних операций с участием данного адреса [возможно, путем сопоставления с образцом, чтобы избежать раскрытия этих третьих сторон, что ты адрес владельца], или (б) с просьбой ваших коллег только вперед части блоков, которые имеют отношение к вам. Вы можете проверить, что транзакция была включена в блок цепи, если вы знаете его Merkle ветвь.


Любой TxOut может быть погашен только в TxIn одной транзакции. Это правило получает силу, если сделка включена в блок по шахтеру. Узлы отказываются принимать блоки с сделок, нарушающих это правило, так, например, блоки от злонамеренного шахтера, которые включают двойной тратит от одного TxOut не будет распространяться через сеть.

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

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


Блок метки времени все 32-разрядные UTC UNIX времена, которые "Сеть скорректированных", То есть, клиент получает от своих сверстников (в сообщении версии) их относительный какое время они думают, что это, и вычисляет смещение от местного времени к каждому из "вглядываться" раз. Медиана смещения затем используется для преобразования местного времени к сети времени. Это только синхронизирует клиентов примерно, но достаточно, чтобы получить расчет трудности в основном правильно, что это все, что метки времени даже используются. Как это работает в том, что блок будет принят узлом, только если его метка больше, чем средняя временная метка из предшествующих 11 блоков (так что вы не можете добавлять блоков с отметкой времени, что это слишком низко, и попытаться снизить сложность на следующем Retarget), и если метка не дальше, чем 2 часа в будущее (так что метка время не слишком высока, и вы усложняете на следующем перенастроить). Перенаправляет случаются каждые 2016 блоков (около двух недель), где я думаю, ваши 0 и 2015 ограничения как.


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


Надеюсь, что помог!