Предлагаю вознаграждение тому, кто опишет способ взлома приватного блокчейна.
Условия следующее:
Есть база данных. Пусть это будет типовая БП. Есть один владелец базы. У него есть полный доступ к базе и возможность делать любые транзакции. Владелец базы хочет, чтобы его действия стали прозрачными для некоторого контрагента, который является его поставщиком, и которого мы дальше будем называть проверяющим. С этой целью он создает журнал на основе блокчейна. Журнал содержит ИД документа, хэш документа, хэш начальный и хэш конечный. Владелец базы дает проверяющему доступ на чтение к базе и доступ на чтение к журналу. Проверяющий создает сам или получает от Владельца программу проверки. Как именно - не важно, потому что, в любом случае код проверяющей программы открыт и находится под контролем Проверяющего. Эта программа запускается регулярно и проверяет соотвествие хэш-сумм и содержимого документов, соотвествие начальных и конечных ключей, и, наконец, соотвествие последнего ключа предыдущей проверки этому же ключу для текущей проверки. Т.е. провели проверку журнала. Последний блок Х содержал ключ Y. Через некоторое время проводим проверку снова и проверяем, чтобы конечный ключ блока Х был равен Y.
Прозрачность заключается в том, что Проверяющий после каждой проверки будет получать список новых документов. И может быть уверен, что никакие старые документы не менялись и не удалялись.
Для получения вознаграждения требуется описать последовательность действий Владельца с базой и с журналом, которая приведет к тому, что эти действия будут скрыты от Проверяющего. Требуется привести доказательства того, что сам факт этих действий не будет зарегистрирован проверяющей программой.
Срок проведения данного конкурса - до 10.08.2019.
---
Например мне удалось найти коллизию и я поменял контрагента и адрес, так что бы в сумме хеш по алгоритму не изменился. Вы будете видеть все тот же документ, но с отличными данными, ключи совпадут. Если ваш хеш алгоритм уникален для любого состава данных, то это по сути версионирование, снимок последнего состояния. Это уже не совсем хеш.
Как поможет соль - просто нереально будет определить алгоритм хеширования по хеш-таблице, точнее, цена поиска будет стремиться к безконечности и будет не выгодна.
---
ручная операция сторно документов ( или просто ручные операции) , позволит изменить движения документов ( хотя и текущим числом ) для проверочной программы это будет как новый документ , и по сути основной документ не меняется и хеши будут сходится ( ведь движения меняем в другим документом ) но данные для базы будут изменены можно например полностью сторнировать движения документов.
---
кто помешает
1. переименовать Поставщика и получателя и получить те же документы с другими контрагентами? В Журналах(документах) только ссылки на справочники. Сами данные справочников в журнале не сохраняются.
2. обработкой поменять записи в регистрах не затрагивая сами документы. Журнал данные регистра не хранит.
---
хэш-сумм и содержимого документов, соотвествие начальных и конечных ключей, и, наконец, соотвествие последнего ключа предыдущей проверки этому же ключу для текущей проверки
для уточнения задания:
1. из каких данных формируется хэш?
2. что бы изменить данные в базе, не обязательно пользоваться документами, как этот вопрос закрыт?
3. почему для этих действий (проверки отношений между хоз. субъектами) они не используют акты-сверок?
4. Администратор и другие полноправные точно хорошую ЗП получают?

Или у Вас принципиально другая задача - проверить как работает Ваш алгоритм в той разбработке?
---
1. Считайте, что из всех данных документа. Т.е. реквизиты, табличные части и наборы записей движений.
2. Проверяющему будет достаточно того факта, что документы не менялись.
3. Потому что акты сверок их не устраивают. Они их делали много раз и ничего не сходилось. Тогда у проверяющего возникла идея: а давайте сделаем так, что я буду видеть все, что вы вносите в базу. Тогда я возьму данные, сам их агрегирую и убежусь, что косяк на моей стороне.
4. Не знаю. Но думаю, что отсутствие ответа на этот вопрос не помешает вам принять участие в конкурсе.
---
Журнал содержит ИД документа, хэш документа, хэш начальный и хэш конечный. кто мешает показать Проверяющему тот Журнал, который он ДОЛЖЕН увидеть. Хеши все равно где-то рядом будут храниться (пересчитывать их по документно каждый раз - та ещё задача, хотя это вопрос архитектуры и железа). Блоки Х и У можно нарисовать такие, какие они должны быть.
И программа проверки. Она может всё это сделать... :) Из-за её фичи "в любом случае код проверяющей программы открыт и находится под контролем Проверяющего" это будет двойная нагрузка нп ПРоверяющего: 1. ПРоверить журнал 2.ПРоверить программу 3. ещё раз проверить журнал.
Чем версионирование встроенное не устраивает?
---
Вы, видимо, и сами уже догадались, что не всякий журнал пройдет проверку. Хэш, который хранится в журнале должен соответствовать данным документа в базе. Проверка - процесс быстрый. Вычисление хэш суммы происходит на порядок быстрее, чем считывание документа.
Версионирование не создает доверия. Версионирование - это не более чем записи в таблицах, к которым у владельца есть полный доступ.
---
ручная операция сторно документов ( или просто ручные операции) , позволит изменить движения документов ( хотя и текущим числом ) для проверочной программы это будет как новый документ , и по сути основной документ не меняется и хеши будут сходится ( ведь движения меняем в другим документом ) но данные для базы будут изменены можно например полностью сторнировать движения документов.
---
Движения документов включаются в хэш.
---
ещё раз , например есть реализация со своими проводками , далее делается документ Операция с видом движения сторно документа. Что делает операция сторно - она просто читает движения нужного документа копирует их и добавляет знак минус , но Регистратором является сама операция , а движения самого документа реализации остаются не тронутыми и хэш документа реализации не изменится
---
думаю, что Операция вручную подхватит хэш первичного документа и занесет в журнал свой хэш, потом общий хэш журнала изменится и по-цепочке можно будет размотать и увидеть, что документ отсторнирован. я не знаю, есть ли у автора разработки такой механизм. На раз присутствует слово "блокчейн", наверное есть.
---
занесет в журнал свой хэш (построенный на основе своего хэша и хэша первичного документа)
---
как она его подхватит если в документе его нет ? Хэш вычисляется и хранится где-то отдельно , операция просто скопирует движения документа и дальше можно делать с проводками все что угодно , а первичный документ остаётся неизменным как в плане реквизитов так и в плане движений
---
Операция тоже включается в журнал.
---
и что ? Увидит поставщик в журнале операцию (как я понимаю проводки в журнале он не видит ) я же не отрицаю что она не попадёт в журнал , просто будет считаться новым документом , но вся суть в проводках которые делает этот документ , а они изменяют данные , и журнал этого не уследит , так как хэш основного документа не будет изменен , и достаточно один раз это не заметить , тогда все последующие хэши будут ошибочными
---
Проверяющий "видит" проводки в журнале. Если вы измените проводки какого-либо документа, то вам потребуется изменить хэш этого документа. Просто считайте, что документ и его проводки это неразрывное целое. Также, как документ и его табличные части.
---
документ и его проводки это неразрывное целое не всегда.
Если я проведу платежное поручение, а потом в регистр бухгалтерии допишу проводки по этому документу,
то ничего Ваш блокчейн не увидит :).
Документ то не изменился, а вот движения изменились.

(25) Также, как документ и его табличные части
ПОиском и заменой значений после проведения пройдусь и все потеряется, а хэш и журнал останутся.

О пропустил, в (17) уже описали...
---
Вы, видимо, ещё с Михаилом дела не имели)) Не надейтесь, он вам ничего не заплатит, даже если вам дадут нобелевскую премию по точнейшему доказательству провальности его поделки))
---
Михаил , ещё раз по пунктам считаем что везде субконтрагент одинаковые
1) допустим есть реализация с проводками Дт 62.01 Кт 90.01.1 на 100 руб . Дата 27.07.19 Регистратор - реализация

2) 28.07.19 документ операция проводки Дт 62.01 Кт 90.01.1 на сумму 150 руб. Регистратор операция

Что получается операция не содержит никаких реквизитов для идентификации контрагента (можно понять только по движениям ) , и не понятно как будет попадать в журнал к данному контрагенту ? Если будет 1000 таких операций они все попадут в журнал

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

А так на любое возражение можно сказать что это предусмотрено и менять условия в угоду себе
---
Он так всегда и делает))
---
а зачем эта попытка?

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

Хватит нас маленьких дурить, надоело пустозвонство!

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

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

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

Статья на месте:
Часть 1:
https://infostart.ru/public/1097521/

Часть 2:
https://infostart.ru/public/1097525/

Михаил там тоже побывал, выступил в своей обычной манере))
---
кто помешает
1. переименовать Поставщика и получателя и получить те же документы с другими контрагентами? В Журналах(документах) только ссылки на справочники. Сами данные справочников в журнале не сохраняются.
2. обработкой поменять записи в регистрах не затрагивая сами документы. Журнал данные регистра не хранит.
---
1. Переименование справочников - оригинальный ход. Будем считать, что в хэш попадают не ИД, а наименования.
2. Хэш содержит данные движений.
---
это называется подогнать вопрос под ответ. Читаем задание в (0):
Журнал содержит ИД документа, хэш документа, хэш начальный и хэш конечный. Владелец базы дает проверяющему доступ на чтение к базе и доступ на чтение к журналу.
Вот теперь ничего не будем считать, а выполнять условие задания.
---
И? Где противоречие условию?
---
"Будем считать, что в хэш попадают не ИД, а наименования." это не изменение условия задания?
В общем то и так было ясно...
---
Что конкретно изменилось?
---
- Спорим, что ты меня не сможешь ударить?
- Спорим. (хук слева)
- Нет. это не так. Ты в другом городе должен быть.
занавес...
---
С удовольствием с вами посмеялся. Что конкретно изменилось в моем условии?
---
"Пусть это будет типовая БП"
1. "Журнал содержит ИД документа, хэш документа, хэш начальный и хэш конечный.
2. "Эта программа запускается регулярно и проверяет соотвествие хэш-сумм и содержимого документов, соотвествие начальных и конечных ключей, и, наконец, соотвествие последнего ключа предыдущей проверки этому же ключу для текущей проверки. Т.е. провели проверку журнала. Последний блок Х содержал ключ Y. Через некоторое время проводим проверку снова и проверяем, чтобы конечный ключ блока Х был равен Y. "
3. "Прозрачность заключается в том, что Проверяющий после каждой проверки будет получать список новых документов. И может быть уверен, что никакие старые документы не менялись и не удалялись. "
4. "Для получения вознаграждения требуется описать последовательность действий Владельца с базой и с журналом, которая приведет к тому, что эти действия будут скрыты от Проверяющего. Требуется привести доказательства того, что сам факт этих действий не будет зарегистрирован проверяющей программой."

Подменить данные ссылок в документе можно? Можно.
Изменить регистры не изменяя документы можно? Можно.
Каких еще доказательств нужно привезти, что факт этих действий не будут зарегистрированы проверяющим?
---
Подменить данные ссылок нельзя. Я понимаю, что вам немного обидно. Если бы я выложил код и в этом коде я формировал хэш документа, используя ссылки, а не наименования, то вы конечно же выполнили бы условия конкурса. Но вы поймите и меня. Я изначально сомневался в том, что люди захотят копаться в коде за столь скромное вознаграждение. Поэтому и предложил чисто мысленный эксперимент, в котором вам, как проверяющему не потребуется сильно напрягаться. Моя задача - выявить все потенциально опасные места. При подведении итогов конкурса, я учту все дельные замечания. В том числе и ваше.
---
Если бы я выложил код Вот с этого и нужно было начинать. Выкладывайте код.
---
Полный код приватного блокчейна выкладывать пока рано. Могу выложить код получения хэша документа.
---
сделайте систему как в банке, что данные нельзя менять задним числом.
Тогда расхождений и не будет.
А если и будут, то только после изменений в базе и вычислить с какой даты, что не пошло будет легко.
Если у вас есть блокчейн, то то что вы описали уже не блокчейн.
Блокчейн это история последовательных операций.
А у вас набор хешей операций, которые могут потом изменить, это как бы уже разные вещи или вы слышали звон да не знаете где он?
Для понимания блокчейн это журнал регистрации в понятиях 1С.
Изменить его можно, но сути тогда не покажет и если начать его анализировать, то дыру можно выявить 2 метода:
1. Когда было 1, 2, 3, вы заменили на 1, 1, 3, тут мы видим, что данные изменились, но изменения нет
2. Когда как вы уже казали есть второй ЖР на дату проверки и сравнив их видим, что было изменение этот вариант вообще как 2 пальца палит контору.
Когда будет приз?
---
Итоги конкурса будут подведены 10.08.2019. Но вы не описали схему взлома. Замена 1,2,3 на 1,1,3 - это не схема.
Опишите подробнее: что изменилось и почему эти изменения проверяющий не заметит.
Про систему в банке вы очень вовремя вспомнили. Как по-вашему должна работать такая система? Как обеспечить невозможность изменения задним числом? Можно ли это сделать без блокчейна?
---
любой редактор файла отредактировал и все.
Запрет редактирования документа после проведения. Для последующего изменения документа создается следующий.
Тут вообще блочейн не нужен т.к. 1С это уже блокчейн если ее настроить.
---
Отредактировал что?
В типовой конфигурации(любой) 1С блокчейна нет, как ее ни настраивай. И опять же, как ее не настраивай, можно, например, поменять местами 10 шт. за 1 рубль на 1 шт. за 10 рублей и никто никогда не заметит.
Запрет изменения документа после проведения - это хорошо, но как вы это сделаете без блокчейна?
---
вы похоже плохо читали что я вам написал.
И путаете блокчейн и хеширование.
---
Я все читаю внимаельно. Даже откровенный бред. Вы можете сами убедиться, просмотрев эту ветку.
И я ничего не путаю. Опишите внятно, что изменит владелец. И почему проверяющий этого не заметит.
---
если 1С будет работать как блокчейн, то сами данные в базе изменить нельзя, а вот журнал поправить можно и не стыковка пойдет по журналу, а по базе будет все красиво.
Также в технологии блокчейна есть важная особенность, что может быть построено несколько веток событий, что и делает хакер, но через 10 минут все алгоритмы делают перепроверку и хакнутый блок быстро отбраковывается. А у вас всего 2 базы. Правильная и не правильная. В итоге будет так что у вас все равно будет кто-то не прав.
И опять же возвращаемся к определению, что не до конца в теме для чего технология и как работает.
---
База одна.
---
тогда еще лучше. Хакер взломал базу, следов не оставил и все пошло по ...!
А ваши хеши обновил. Т.к. база не распределенная, то и сверять вам нечего и точка на этом.
Возможно бух заметит каких-то новых клиентов и что он платежку леваку отправил, но будет ли настолько внимателен он это большой вопрос!
Поэтому для проверки нужна распределенная структура как блокчейн, а у вас в третий раз повторяю уже не он.
Изначально вы сообщали что есть проверяющий, а на деле это пользователь той же базы.
Беседа с вами уже превращается в фарс!
Может пора задуматься, что грамотно поставленный вопрос это половина сделанного дела.
А у вас даже вопроса нету!
---
У проверяющего есть программа проверки. Прочитайте внимательно в условиях, как она работает. Подмена журнала обнаруживается.
---
как связаны программа проверки и база одна. Вы либо что-то путаете либо не понимаете о чем говорите.
Можете не привязываться к понятиям 1С.
---
Я все описал в условиях. База одна. Она в полном распоряжении владельца.
У проверяющего доступ к базе на чтение и программа проверки. Проверки базы и журнала, если мы решили хранить их отдельно, или просто базы. Что непонятно?
---
если вопрос стоит сможет ли при таком раскладе проверяющий узнать поменял ли не подготовленный пользователь данные, то с 99% вероятности, что сможет. Т.к. обмануть любой алгоритм можно, в особенности с хешами.
А вот сможет ли проверяющий узнать что была фальсификация, когда за дело возьмется хакер, то тут вероятность 1% что сможет.
А как он это сможет сделать уже будет зависеть от вашей программы на каком алгоритме она будет работать.
Так что не стройте иллюзий))
---
Программа проверки слишком проста, чтобы ее ломать. Проверяешь каждый блок на соотвествие данных в базе хэшу. Проверяешь начальный и конечный ключ. Отдельно проверяешь, чтобы конечный ключ блока N был равен сохраненному ранее значению. В ней, этой программе, символов будет едва ли не столько же, сколько в этом коротком посте. А смысл будет понятен любому школьнику. Что тут ломать?
Если бы ваша оценка в 1% была верна, то в этой теме уже было бы несколько рецептов взлома.
---
вы сами написали алгоритм взлома. Что еще тут добавить?
---
В каком месте?
---
Вопрос был если пользователь не будет сохранять последний хеш блока и при пересчете всей цепочки начиная с генезис блока , программа проверки ничего не заметит , т.е. обязательным условием становит хранения последнего блока на компьютере проверяющего
---
Проверяющий берет бумажку и переписывает последний хэш или сохраняет к себе на компьютер , далее при следующей проверке достает бумажку (или файл ) и сверяет с журналом - это так задумано у Михаила )))
---
а по поводу справочников такая же песня как и с документами, запрет редактирования после создания.
Тогда 1С приблизится к технологии блокчейна.
---
Предлагаю вознаграждение тому, кто опишет способ взлома приватного блокчейна.

За стартмани?))) Серьезно?)))
---
Вполне. А что вас смущает?
---
УК РФ Статья 272 Неправомерный доступ к махчейну.

В соседней теме кстати 9 Инфомани разыгрывается только за описания своего видения к блокчейну. И никакого криминала.
1 инфомани из 10 уже выплачен за нахождение орфографической опечатки.
---
Дайте-ка я догадаюсь, что вы будете утверждать по свою разработку, если на вас просто не обратят внимания и пройдут мимо...
---
У вас есть версия?
---
Да. Она заключается в том, что вы будете утверждать что ошибок у вас не нашли. Хотя их никто и не искап.

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

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

Зачем ему все эти "хэши"?
---
А как вы представляете себе проверку? Открыл документ в базе, достал бумажную копию и проверяешь?
Хэши для того и нужны, чтобы проверка шла в автоматическом режиме.
---
У вас есть версия?
Миша вот вам версия, споить баярошником супервизора, пока она будет дрыхнуть подменить хэши коды Махчейна путем глубинного проникновения.
Ну это я предложил исходя из вашего щедрого вознаграждения 5 ифномани.
Если предложить 30-100 ифномани - то уже можно и коньяком спаивать и яблок с мандаринами и шампанского и открытку на новый год.
Бюджеты свыше 1000 инфомани - можно даже в ресторан пригласить и даже еперный театр.

Единственная проблема - последствия возникновения сиротных блоков Махчена, результатом которых будут множество бастардных транзакций Михчейна .
---
Понятно. Еще есть?
---
Есть-ли доступ к коду базы у проверяющего?
---
Считайте что нет.
---
(75) С точки зрения чайника: но если мы не учитываем всех реквизитов, то что мешает создать в каждом документе некоторые свои реквизиты(Например, Сумма2) и не выводить их пользователю. В хэш попадают выбранные реквизиты, а в документы и отчеты выводим данные из скрытых, если они отличаются от основных?
Вопрос скорее в целях самообразования.
---
А проверяющий не будет смотреть на эти отчеты. Он разработает свои, на основе только того, что он видит. Остальное для него просто не будет существовать.
---
ну это детский сад какой-то . зачем тогда нужен ваш журнал если проверяющий видит документы + должен писать свои отчёты для проверки.
---
Это уже детали. У проверющего может быть готовый отчет. Возможно и то, что этот отчет ему предоставит владелец. Тут важно, что с момента представления этот отчет будет находится под контролем проверяющего.
---
еще раз смысл вашего журнала если у проверяющего будет отчет и он каждый день может его формировать и сохранять у себя ?
---
Т.е. зачем блокчейн? Затем, что без блокчейна можно внести изменение задним числом и проверяющий его не заметит.
---
как отчет он формирует каждый день и сравнивает если у него операций не было то и отчет не долен поменяться , если была то он знает какие цифры он должен получить при формировании отчета
---
Да и какие цифры вы будете сравнивать?
---
какие будет показывать отчет
---
Я - владелец базы. Вы - мой поставщик и, соотвественно, проверяющий.
Мы с вами договорились, что вы поставляете товар по предоплате, но в строго оговоренные сроки. В случае нарушения сроков, с вас удерживается небольшая пеня за каждый день просрочки. Так получается, что сроки вы действительно довольно часто нарушаете на 1-3 дня, но пеня не очень большая.
Далее, я беру и передвигаю один документ на один день в свою пользу. Какие действия с вашей стороны обеспечат гарантированное обнаружение этого?
---
Далее, я беру и передвигаю один документ на один день в свою пользу. Какие действия с вашей стороны обеспечат гарантированное обнаружение этого?
А какие сейчас это обеспечивают на тысячах предприятий которые ничего не слышали про блокчейн?
Ведут учёт отгрузки и начисление пени.
---
Те, кто хотят вести учет, как сейчас, пусть ведут, как сейчас)))
---
Тогда зачем им костыли в виде вашего сомнительного блокчейна?

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

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

Документы подписаны с вашей стороны или еще нет ?
---
Да, какая разница? Дырка в защите либо есть, либо ее нет. Если вы знаете способ гарантированного обнаружения изменений, то он должен работать при любых условиях. Иначе, он не годится. Как разберетесь с этим, я вам еще пример подкину.
---
Это для того что бы потом вы не изменили условия - если описать так то

1) отправляю Вам документ формирую отчет смотрю что вы его отразили у себя нужным числом и с нужными данными (совпадает с теми данными которые у меня) сохраняю отчет. Отчеты сохраняю каждый день

2) вы меняете дату документа число назад (так как вперед дату вам не выгодно меньше с меня пеней возьмете)

3) Формирую отчет смотрю документы которые еще не отгруженный - вижу что документ изменил свою дату . Вот и все

И мне не надо контролировать все документы , а только те которые еще не отгрузились

+ ещё требование заверить с вашей стороны копии моих отчетов
---
Дату какого документа я меняю назад? Платежного? И кто кому, тогда его отправляет?
---
Михаил , с смотря с какой даты считается что я должен отгрузить вам товар , если момента оплаты вами , то да ок фиксируем ваши платежные поручения но тогда ещё проще в клиент банке будет видно реальную дату когда вы оплатили и на данные базы мне уже пофиг
---
Прекрасно и что вы будете делать? Каждый день сверять даты документов в клиент-банке и в базе? За какой период?
---
нет , даже проверять не буду , буду смотреть фактическую дату поступления денег на свой расчетный счёт и считать просрочку именно с этой даты ,
---
Просрочку считаю я. Мы так с вами решили. Потому что нам надоело. У нас было две базы. Моя и ваша. Я посчитал у себя. Вы посчитали у себя. Ничего не сошлось и мы две недели разбираемся - чей оператор накосячил при вводе данных в базу. По результатам нашего многолетнего сотрудничества, мы выяснили, что ваши и мои операторы косячат 50 на 50.
---
что за новые условия на счёт того что мне надоело ? И что мои менеджеры косячат Такого не было . Плюс вы сказали что ВЫ МЕНЯЕТЕ ДАТУ документа а не мои менеджеры косячат Поэтому я и просил озвучить все условия сразу , Вы сейчас придумываете ситуацию в угоду себе . Прошу не добавлять условия в приведённый же вами пример. А он был таков - что я отгружаю товар по предоплате , часто с просрочкой вы переносите дату документа что бы мне «насолить» ( опять же вы не уточнили какого документа , далее решили что оплату) я говорю - по-фигу что вы там что-то по меняли я ориентируюсь по дате поступления денег на расчетный счёт и через клиент-банк мне легко доказать когда мне эти деньги пришли
---
Да не надейтесь вы - это же Михаил! Он придумает ещё сто тысяч условий, а потом будет говорить - так это ж я с самого начала подразумевал, вы все дураки, а я пророк)) Если вы думаете, что он кому-то что-то заплатит, значит вы счастливчик и ещё мало с ним общались))
---
Это не новые условия. Это - вольное сочинение на тему: почему условия такие. Не обращайте внимание.
Итак. Вы полностью повернули ситуацию. Теперь вы считаете просрочку, а не я. И вы думаете - что-то изменилось?
Вы посчитали там у себя, а я вам не доверяю. Может вы ошиблись, когда данные вбивали, а может специально что-то исказили. Что делать будем?
---
Еще раз мне по-фигу на ваши данные , так же как и вам на мои. есть клиент банк по которому прошел платеж есть выписка банка где указана дата операции , и даже если я захочу схитрить , вы спокойно мне скажете : "Постой ка друг , вот выписка банка - деньги капнули тебе на счет такого числа, в договоре указано что после оплаты ты в течении стольких-то дней должен мне отгрузить товар, значит с этого числа и начинаем считать и мне совершено по фигу что ты занес их в свою учетную систему другим числом это твои проблемы" практически такая же фраза будет и с моей стороны если вы что то у себя поменяете в учетной системе , в банке то вы уже не сможете ничего поменять
---
Вот мы и подошли к пониманию, зачем нужен блокчейн.
Чтобы сказать: "постой-ка, друг, вот выписка", я должен:
1. Отследить сам факт того, что косяк произошел.
2. Определить дату косяка.
3. Получить выписки банка.
4. Обработать выписки банка.
Подумайте над этим.
А раз уж начнете думать, вот вам второй пример.
Когда вы говорили про отчеты в самом начале, вы скорее всего представляли себе некоторую оборотно-сальдовую ведомость. Остаток на начало, приход, расход, остаток на конец. Теперь представьте. Вы поставщик.
1. Вы привезли мне 10 мешков какого-нибудь счастья по цене 1 руб.
2. Я ввел в систему документ поступления.
3. Вы проверили этот документ.
4. Некоторое время спустя, я изменил документ. Вместо 10 мешков по 1 руб. сделал 1 мешок по 10 руб.
5. Вы не можете каждый раз поверять абсолютно все документы, поэтому в отношении старых документов полагаетесь на отчет. Но в вашем отчете все в порядке.
6. Через некоторое время я возвращаю вам 1 мешок, а 9 оставляю себе.
---
ещё раз мне не нужен ваш журнал и ваша база , не нужно каждый день что-то проверять , мне достаточно в момент спора просто обратиться к выписки банка , а не сидеть и контролировать ваших менеджеров ,а со своими я сам разберусь

По поводу второго примера - если у вас есть 10 мешков значит я вам их отгрузил , значит на руках есть подписанная вами Товарная накладная ТОРГ - 12 - дальше спорим ?
---
Мы вобще-то не спорим. Вы спросили -зачем нужен блокчейн, я ответил.
Если вы не понимаете, что у вас на руках несколько тысяч подписанных ТОРГ12, то продолжайте не понимать.
---
не понял вас - подписанный вами официальный документ - уже не документ ? У меня с вами в день 1000 отгрузок ? Найти нужную мне не составит труда . Я понимаю что такое блокчейн , но вот ваш «блокчейн» я не понимаю ещё раз вам приводили пример

Пусть есть 2 идентичные базы , основная и копия основной базы , из первой базы по средством обработки переносятся данные во вторую что бы все было идентично , т.е. начальные блоки идентичные и хэши идентичные , далее первую базу вносится документ , и далее он переносится во вторую базу и там изменяется , и вторая база заменяет первую . В итоге проверяющий по хэшам не заметит ничего , а данные изменены. Далее вы утверждаете что проверяющий может смотреть данные базы и может посмотреть документ , но тогда Сёму ему верить если хеши в журнале совпадают , а данные документа нет ? Плюс вы говорите есть 1000 документов он что должен каждый тогда проверить ?
---
Вадим, Мишаня предлагает вообще отказаться от подписи. Он считает что в приватном махчейне она излишняя и лишь увеличивает длину блока. Поэтому в махчейне все построено на доверии в махчейне.

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

Так что если ваши блоки станут сиротные , а документы пропадут... это кара Махчейна, надо забыть и простить.