Вы вот этот сайт на sites.google.com, где сам черт ногу сломит, прежде чем поймет ЧТО ЭТО - вы вот это называете, пардон, серьезным проектом?

Думаю, достойно отдельного топа.

Понеслась.

Исходный документ Сатоши

Буду переводить постепенно.

I develop DIANNA chain to test DHT chain storage there.

Ah, crunches... All right Lets see where it will go.

I see the future of bitcoin chain in some sort of distributed hash table with good redunancy to avoid information drop.

So I see the main load may be put on network layer, instead of SATA bus.

http://blockchain.info/pushtx

Тут можно в HEX запилить транзакцию на отправку. А вот как получить HEX сериализованной транзакции - сложнее

Теоретически можно сделать распределенную базу цепи по принципу схожему с DHT с некоторыми допилами в сторону защиты от Sybill. Но никто пока не чешет задницу в этом направлении.

Напомни, чего я там обещал? Я еще не протрезвел после НГ  

Allright. The client with DB consisting only with block headers receives the transaction. What next he must do with it?

Store? No. It must be sure transaction is valid to store it, but he can not check its validity as he dont have full chain.
Broadcast? No. Same reason. If trx isnt valid, he will be banned as DoS source by vanilla clients.

If network will consist of huge part of such light clients - it will be paralyzed.

With the cost of security, don't you know?

If client receive bcast block/transaction from network it must check its prev outputs in full block chain to know whether its a valid transaction for futher broadcast.

If client burn old transaction - it will not be able to check new transactions for validity.

If it broadcast not valid transaction - it will be banned by vanilla clients.

So burning old block bodies makes client vulnerable to Sybill and DoS attacks, coz he unable to check what is true and what is false comming from network.

Из официального документа Сатоши:


Как известно, в блоке львиную долю места занимает тело блока.

То есть, типа не обязательно хранить тела блоков все время. Для того, чтобы стереть тело блока с диска, достаточно, чтобы выстроилась некая большая цепь над ним.

Но хидеры хранить обязательно. Однако здесь есть проблема.

Во-первых, кто то обязательно должен хранить всю цепь - хоть убей. Для разрешения угрозы форков цепи, дабы возможно было проследить историю каждой монетки вплоть до ее генерации. То есть, часть сети, обязательно должна хранить вот эту почти экспоненциально растущую базу: http://blockchain.info/ru/charts/blocks-size

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

Если на клиенте не будет полной цепи - он будет гораздо более уязвим к Sybill и DoS атакам злых анонимусов. Ну представьте себе клиента только с хидерами. Он получает новую транзакцию из сети. Как ему проверить предыдущие Ouput'ы этой транзакции, если их просто нет? А если он не может проверить, он не может знать, верна ли транзакция или нет. Но по протоколу он обязан сохранить ее. Получается, его можно просто завалить левыми транзами. А если он еще их и брокастнет, то ванильные клиенты его жестко побанят.

Другими словами, клиент только с хидерами блоков - вещь весьма стремная.

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

А что насчет фулл клиентов с полноценной базой? А Сатоши в оф документе ничего не говорил о проблемах полной базы.

А ведь они уже есть и выходят за рамки использования ванильного клиента на среднестатистическом пользовательском ПК.

Я кое что знаю о высоких нагрузках. В частности, о высоких нагрузках на базу данных. И эта история не про нехватку места, а про нехватку пропускной способности шины винта.

Пока индекс помещается в размер ОЗУ - проблем особо нет. Или беркли-бекенд его кеширует, или буфера OS. В любом случае, поиск по такому индексу не является проблемой.

Но как только индекс начинает превышать объем ОЗУ, особенно, в 2-5 раз, то все методы кеширования данных оказываются бесполезны. И тогда при поиске ключа, комп начинает лопатить очень много гигабайт данных на винте. А ведь клиенту при получении транзакции надо найти все предыдущие аутпуты, а при получении нового блока - повторить тоже самое для всех транзакций блока. Я уж молчу про процесс синхронизации.

Мое мнение - в недалеком будущем, ванильный клиент Bitcoin выйдет за рамки возможностей стационарного домашнего/офисного ПК. Главный боттлнек - пропускная способность шины SATA и скорость позиционирования головки. Твердотельные накопители конечно могут немного облегчить эту проблему, но не намного и не надолго. Если учитывать что Биткоин - это быстро растущая сеть, объем информации обещает экспоненциальный рост.

I plan to work on distributed chain database within DIANNA project. But still no programmers here ))

Lucif, you shitting ppl pants, as always. Bravo.

Неплохо. Надо это направление побрейнштормить.

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

Гарант всех записей
Записи находятся здесь

You probably shift bet deadline more far from event deadline - e.g. to summer 2016. Otherwise it is not intersting to bet. In Dec 2016 the result of this bet would be obvious.