Проверка возможности взлома приватного блокчейна
Предлагаю вознаграждение тому, кто опишет способ взлома приватного блокчейна.
Условия следующее:
Есть база данных. Пусть это будет типовая БП. Есть один владелец базы. У него есть полный доступ к базе и возможность делать любые транзакции. Владелец базы хочет, чтобы его действия стали прозрачными для некоторого контрагента, который является его поставщиком, и которого мы дальше будем называть проверяющим. С этой целью он создает журнал на основе блокчейна. Журнал содержит ИД документа, хэш документа, хэш начальный и хэш конечный. Владелец базы дает проверяющему доступ на чтение к базе и доступ на чтение к журналу. Проверяющий создает сам или получает от Владельца программу проверки. Как именно - не важно, потому что, в любом случае код проверяющей программы открыт и находится под контролем Проверяющего. Эта программа запускается регулярно и проверяет соотвествие хэш-сумм и содержимого документов, соотвествие начальных и конечных ключей, и, наконец, соотвествие последнего ключа предыдущей проверки этому же ключу для текущей проверки. Т.е. провели проверку журнала. Последний блок Х содержал ключ Y. Через некоторое время проводим проверку снова и проверяем, чтобы конечный ключ блока Х был равен Y.
Прозрачность заключается в том, что Проверяющий после каждой проверки будет получать список новых документов. И может быть уверен, что никакие старые документы не менялись и не удалялись.
Для получения вознаграждения требуется описать последовательность действий Владельца с базой и с журналом, которая приведет к тому, что эти действия будут скрыты от Проверяющего. Требуется привести доказательства того, что сам факт этих действий не будет зарегистрирован проверяющей программой.
Срок проведения данного конкурса - до 10.08.2019.
Условия следующее:
Есть база данных. Пусть это будет типовая БП. Есть один владелец базы. У него есть полный доступ к базе и возможность делать любые транзакции. Владелец базы хочет, чтобы его действия стали прозрачными для некоторого контрагента, который является его поставщиком, и которого мы дальше будем называть проверяющим. С этой целью он создает журнал на основе блокчейна. Журнал содержит ИД документа, хэш документа, хэш начальный и хэш конечный. Владелец базы дает проверяющему доступ на чтение к базе и доступ на чтение к журналу. Проверяющий создает сам или получает от Владельца программу проверки. Как именно - не важно, потому что, в любом случае код проверяющей программы открыт и находится под контролем Проверяющего. Эта программа запускается регулярно и проверяет соотвествие хэш-сумм и содержимого документов, соотвествие начальных и конечных ключей, и, наконец, соотвествие последнего ключа предыдущей проверки этому же ключу для текущей проверки. Т.е. провели проверку журнала. Последний блок Х содержал ключ Y. Через некоторое время проводим проверку снова и проверяем, чтобы конечный ключ блока Х был равен Y.
Прозрачность заключается в том, что Проверяющий после каждой проверки будет получать список новых документов. И может быть уверен, что никакие старые документы не менялись и не удалялись.
Для получения вознаграждения требуется описать последовательность действий Владельца с базой и с журналом, которая приведет к тому, что эти действия будут скрыты от Проверяющего. Требуется привести доказательства того, что сам факт этих действий не будет зарегистрирован проверяющей программой.
Срок проведения данного конкурса - до 10.08.2019.
Найденные решения
(282)
Например мне удалось найти коллизию и я поменял контрагента и адрес, так что бы в сумме хеш по алгоритму не изменился. Вы будете видеть все тот же документ, но с отличными данными, ключи совпадут. Если ваш хеш алгоритм уникален для любого состава данных, то это по сути версионирование, снимок последнего состояния. Это уже не совсем хеш.
Как поможет соль - просто нереально будет определить алгоритм хеширования по хеш-таблице, точнее, цена поиска будет стремиться к безконечности и будет не выгодна.
Например мне удалось найти коллизию и я поменял контрагента и адрес, так что бы в сумме хеш по алгоритму не изменился. Вы будете видеть все тот же документ, но с отличными данными, ключи совпадут. Если ваш хеш алгоритм уникален для любого состава данных, то это по сути версионирование, снимок последнего состояния. Это уже не совсем хеш.
Как поможет соль - просто нереально будет определить алгоритм хеширования по хеш-таблице, точнее, цена поиска будет стремиться к безконечности и будет не выгодна.
(1) ручная операция сторно документов ( или просто ручные операции) , позволит изменить движения документов ( хотя и текущим числом ) для проверочной программы это будет как новый документ , и по сути основной документ не меняется и хеши будут сходится ( ведь движения меняем в другим документом ) но данные для базы будут изменены можно например полностью сторнировать движения документов.
(1) кто помешает
1. переименовать Поставщика и получателя и получить те же документы с другими контрагентами? В Журналах(документах) только ссылки на справочники. Сами данные справочников в журнале не сохраняются.
2. обработкой поменять записи в регистрах не затрагивая сами документы. Журнал данные регистра не хранит.
1. переименовать Поставщика и получателя и получить те же документы с другими контрагентами? В Журналах(документах) только ссылки на справочники. Сами данные справочников в журнале не сохраняются.
2. обработкой поменять записи в регистрах не затрагивая сами документы. Журнал данные регистра не хранит.
Остальные ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(1)
для уточнения задания:
1. из каких данных формируется хэш?
2. что бы изменить данные в базе, не обязательно пользоваться документами, как этот вопрос закрыт?
3. почему для этих действий (проверки отношений между хоз. субъектами) они не используют акты-сверок?
4. Администратор и другие полноправные точно хорошую ЗП получают?
Или у Вас принципиально другая задача - проверить как работает Ваш алгоритм в той разбработке?
хэш-сумм и содержимого документов, соотвествие начальных и конечных ключей, и, наконец, соотвествие последнего ключа предыдущей проверки этому же ключу для текущей проверки
для уточнения задания:
1. из каких данных формируется хэш?
2. что бы изменить данные в базе, не обязательно пользоваться документами, как этот вопрос закрыт?
3. почему для этих действий (проверки отношений между хоз. субъектами) они не используют акты-сверок?
4. Администратор и другие полноправные точно хорошую ЗП получают?
Или у Вас принципиально другая задача - проверить как работает Ваш алгоритм в той разбработке?
(5)
1. Считайте, что из всех данных документа. Т.е. реквизиты, табличные части и наборы записей движений.
2. Проверяющему будет достаточно того факта, что документы не менялись.
3. Потому что акты сверок их не устраивают. Они их делали много раз и ничего не сходилось. Тогда у проверяющего возникла идея: а давайте сделаем так, что я буду видеть все, что вы вносите в базу. Тогда я возьму данные, сам их агрегирую и убежусь, что косяк на моей стороне.
4. Не знаю. Но думаю, что отсутствие ответа на этот вопрос не помешает вам принять участие в конкурсе.
1. Считайте, что из всех данных документа. Т.е. реквизиты, табличные части и наборы записей движений.
2. Проверяющему будет достаточно того факта, что документы не менялись.
3. Потому что акты сверок их не устраивают. Они их делали много раз и ничего не сходилось. Тогда у проверяющего возникла идея: а давайте сделаем так, что я буду видеть все, что вы вносите в базу. Тогда я возьму данные, сам их агрегирую и убежусь, что косяк на моей стороне.
4. Не знаю. Но думаю, что отсутствие ответа на этот вопрос не помешает вам принять участие в конкурсе.
(1)
И программа проверки. Она может всё это сделать... :) Из-за её фичи "в любом случае код проверяющей программы открыт и находится под контролем Проверяющего" это будет двойная нагрузка нп ПРоверяющего: 1. ПРоверить журнал 2.ПРоверить программу 3. ещё раз проверить журнал.
Чем версионирование встроенное не устраивает?
Журнал содержит ИД документа, хэш документа, хэш начальный и хэш конечный.
кто мешает показать Проверяющему тот Журнал, который он ДОЛЖЕН увидеть. Хеши все равно где-то рядом будут храниться (пересчитывать их по документно каждый раз - та ещё задача, хотя это вопрос архитектуры и железа). Блоки Х и У можно нарисовать такие, какие они должны быть.
И программа проверки. Она может всё это сделать... :) Из-за её фичи "в любом случае код проверяющей программы открыт и находится под контролем Проверяющего" это будет двойная нагрузка нп ПРоверяющего: 1. ПРоверить журнал 2.ПРоверить программу 3. ещё раз проверить журнал.
Чем версионирование встроенное не устраивает?
(8) Вы, видимо, и сами уже догадались, что не всякий журнал пройдет проверку. Хэш, который хранится в журнале должен соответствовать данным документа в базе. Проверка - процесс быстрый. Вычисление хэш суммы происходит на порядок быстрее, чем считывание документа.
Версионирование не создает доверия. Версионирование - это не более чем записи в таблицах, к которым у владельца есть полный доступ.
Версионирование не создает доверия. Версионирование - это не более чем записи в таблицах, к которым у владельца есть полный доступ.
(1) ручная операция сторно документов ( или просто ручные операции) , позволит изменить движения документов ( хотя и текущим числом ) для проверочной программы это будет как новый документ , и по сути основной документ не меняется и хеши будут сходится ( ведь движения меняем в другим документом ) но данные для базы будут изменены можно например полностью сторнировать движения документов.
(11) ещё раз , например есть реализация со своими проводками , далее делается документ Операция с видом движения сторно документа. Что делает операция сторно - она просто читает движения нужного документа копирует их и добавляет знак минус , но Регистратором является сама операция , а движения самого документа реализации остаются не тронутыми и хэш документа реализации не изменится
(12) думаю, что Операция вручную подхватит хэш первичного документа и занесет в журнал свой хэш, потом общий хэш журнала изменится и по-цепочке можно будет размотать и увидеть, что документ отсторнирован. я не знаю, есть ли у автора разработки такой механизм. На раз присутствует слово "блокчейн", наверное есть.
(13) как она его подхватит если в документе его нет ? Хэш вычисляется и хранится где-то отдельно , операция просто скопирует движения документа и дальше можно делать с проводками все что угодно , а первичный документ остаётся неизменным как в плане реквизитов так и в плане движений
(14) и что ? Увидит поставщик в журнале операцию (как я понимаю проводки в журнале он не видит ) я же не отрицаю что она не попадёт в журнал , просто будет считаться новым документом , но вся суть в проводках которые делает этот документ , а они изменяют данные , и журнал этого не уследит , так как хэш основного документа не будет изменен , и достаточно один раз это не заметить , тогда все последующие хэши будут ошибочными
(25)
Если я проведу платежное поручение, а потом в регистр бухгалтерии допишу проводки по этому документу,
то ничего Ваш блокчейн не увидит :).
Документ то не изменился, а вот движения изменились.
(25)
ПОиском и заменой значений после проведения пройдусь и все потеряется, а хэш и журнал останутся.
О пропустил, в (17) уже описали...
документ и его проводки это неразрывное целое
не всегда.
Если я проведу платежное поручение, а потом в регистр бухгалтерии допишу проводки по этому документу,
то ничего Ваш блокчейн не увидит :).
Документ то не изменился, а вот движения изменились.
(25)
Также, как документ и его табличные части
ПОиском и заменой значений после проведения пройдусь и все потеряется, а хэш и журнал останутся.
О пропустил, в (17) уже описали...
(25) Михаил , ещё раз по пунктам считаем что везде субконтрагент одинаковые
1) допустим есть реализация с проводками Дт 62.01 Кт 90.01.1 на 100 руб . Дата 27.07.19 Регистратор - реализация
2) 28.07.19 документ операция проводки Дт 62.01 Кт 90.01.1 на сумму 150 руб. Регистратор операция
Что получается операция не содержит никаких реквизитов для идентификации контрагента (можно понять только по движениям ) , и не понятно как будет попадать в журнал к данному контрагенту ? Если будет 1000 таких операций они все попадут в журнал
Как видите изменения проходят другим числом и другим документом т.е. сам документ реализация никак не меняется и не меняются его проводки , значит хэш тоже не меняется
1) допустим есть реализация с проводками Дт 62.01 Кт 90.01.1 на 100 руб . Дата 27.07.19 Регистратор - реализация
2) 28.07.19 документ операция проводки Дт 62.01 Кт 90.01.1 на сумму 150 руб. Регистратор операция
Что получается операция не содержит никаких реквизитов для идентификации контрагента (можно понять только по движениям ) , и не понятно как будет попадать в журнал к данному контрагенту ? Если будет 1000 таких операций они все попадут в журнал
Как видите изменения проходят другим числом и другим документом т.е. сам документ реализация никак не меняется и не меняются его проводки , значит хэш тоже не меняется
(1) а зачем эта попытка?
Ведь уже само слово "приватный" означает, что владелец "привата" может вмешиваться ввзламывать цепочки как ему будет угодно.
Хватит нас маленьких дурить, надоело пустозвонство!
От вашего оппонента из прошлой статьи(где диспут закончился предложением пари) где-то неделю назад вышла аргументированная статья, где многое было разложено по по полкам и как любят аналитики различных организаций -
были просчитанные возможные варианты и предложены пути решения.
К сожалению, ни вас в той статье не было, ни самой статьи уже нет!
Просто четкая логика редко кому нужна и девиз нашего времени - забалаболить тему и добиться манипулятивных целей
заказчика.
Отрабатываете заказы и продолжайте говорить ни о чем с теми, кто готов верить любой чуши.
Ведь уже само слово "приватный" означает, что владелец "привата" может вмешиваться в
Хватит нас маленьких дурить, надоело пустозвонство!
От вашего оппонента из прошлой статьи(где диспут закончился предложением пари) где-то неделю назад вышла аргументированная статья, где многое было разложено по по полкам и как любят аналитики различных организаций -
были просчитанные возможные варианты и предложены пути решения.
К сожалению, ни вас в той статье не было, ни самой статьи уже нет!
Просто четкая логика редко кому нужна и девиз нашего времени - забалаболить тему и добиться манипулятивных целей
заказчика.
Отрабатываете заказы и продолжайте говорить ни о чем с теми, кто готов верить любой чуши.
(1) кто помешает
1. переименовать Поставщика и получателя и получить те же документы с другими контрагентами? В Журналах(документах) только ссылки на справочники. Сами данные справочников в журнале не сохраняются.
2. обработкой поменять записи в регистрах не затрагивая сами документы. Журнал данные регистра не хранит.
1. переименовать Поставщика и получателя и получить те же документы с другими контрагентами? В Журналах(документах) только ссылки на справочники. Сами данные справочников в журнале не сохраняются.
2. обработкой поменять записи в регистрах не затрагивая сами документы. Журнал данные регистра не хранит.
(19) это называется подогнать вопрос под ответ. Читаем задание в (0):
Вот теперь ничего не будем считать, а выполнять условие задания.
Журнал содержит ИД документа, хэш документа, хэш начальный и хэш конечный. Владелец базы дает проверяющему доступ на чтение к базе и доступ на чтение к журналу.
Вот теперь ничего не будем считать, а выполнять условие задания.
(32) "Пусть это будет типовая БП"
1. "Журнал содержит ИД документа, хэш документа, хэш начальный и хэш конечный.
2. "Эта программа запускается регулярно и проверяет соотвествие хэш-сумм и содержимого документов, соотвествие начальных и конечных ключей, и, наконец, соотвествие последнего ключа предыдущей проверки этому же ключу для текущей проверки. Т.е. провели проверку журнала. Последний блок Х содержал ключ Y. Через некоторое время проводим проверку снова и проверяем, чтобы конечный ключ блока Х был равен Y. "
3. "Прозрачность заключается в том, что Проверяющий после каждой проверки будет получать список новых документов. И может быть уверен, что никакие старые документы не менялись и не удалялись. "
4. "Для получения вознаграждения требуется описать последовательность действий Владельца с базой и с журналом, которая приведет к тому, что эти действия будут скрыты от Проверяющего. Требуется привести доказательства того, что сам факт этих действий не будет зарегистрирован проверяющей программой."
Подменить данные ссылок в документе можно? Можно.
Изменить регистры не изменяя документы можно? Можно.
Каких еще доказательств нужно привезти, что факт этих действий не будут зарегистрированы проверяющим?
1. "Журнал содержит ИД документа, хэш документа, хэш начальный и хэш конечный.
2. "Эта программа запускается регулярно и проверяет соотвествие хэш-сумм и содержимого документов, соотвествие начальных и конечных ключей, и, наконец, соотвествие последнего ключа предыдущей проверки этому же ключу для текущей проверки. Т.е. провели проверку журнала. Последний блок Х содержал ключ Y. Через некоторое время проводим проверку снова и проверяем, чтобы конечный ключ блока Х был равен Y. "
3. "Прозрачность заключается в том, что Проверяющий после каждой проверки будет получать список новых документов. И может быть уверен, что никакие старые документы не менялись и не удалялись. "
4. "Для получения вознаграждения требуется описать последовательность действий Владельца с базой и с журналом, которая приведет к тому, что эти действия будут скрыты от Проверяющего. Требуется привести доказательства того, что сам факт этих действий не будет зарегистрирован проверяющей программой."
Подменить данные ссылок в документе можно? Можно.
Изменить регистры не изменяя документы можно? Можно.
Каких еще доказательств нужно привезти, что факт этих действий не будут зарегистрированы проверяющим?
(33) Подменить данные ссылок нельзя. Я понимаю, что вам немного обидно. Если бы я выложил код и в этом коде я формировал хэш документа, используя ссылки, а не наименования, то вы конечно же выполнили бы условия конкурса. Но вы поймите и меня. Я изначально сомневался в том, что люди захотят копаться в коде за столь скромное вознаграждение. Поэтому и предложил чисто мысленный эксперимент, в котором вам, как проверяющему не потребуется сильно напрягаться. Моя задача - выявить все потенциально опасные места. При подведении итогов конкурса, я учту все дельные замечания. В том числе и ваше.
(1) сделайте систему как в банке, что данные нельзя менять задним числом.
Тогда расхождений и не будет.
А если и будут, то только после изменений в базе и вычислить с какой даты, что не пошло будет легко.
Если у вас есть блокчейн, то то что вы описали уже не блокчейн.
Блокчейн это история последовательных операций.
А у вас набор хешей операций, которые могут потом изменить, это как бы уже разные вещи или вы слышали звон да не знаете где он?
Для понимания блокчейн это журнал регистрации в понятиях 1С.
Изменить его можно, но сути тогда не покажет и если начать его анализировать, то дыру можно выявить 2 метода:
1. Когда было 1, 2, 3, вы заменили на 1, 1, 3, тут мы видим, что данные изменились, но изменения нет
2. Когда как вы уже казали есть второй ЖР на дату проверки и сравнив их видим, что было изменение этот вариант вообще как 2 пальца палит контору.
Когда будет приз?
Тогда расхождений и не будет.
А если и будут, то только после изменений в базе и вычислить с какой даты, что не пошло будет легко.
Если у вас есть блокчейн, то то что вы описали уже не блокчейн.
Блокчейн это история последовательных операций.
А у вас набор хешей операций, которые могут потом изменить, это как бы уже разные вещи или вы слышали звон да не знаете где он?
Для понимания блокчейн это журнал регистрации в понятиях 1С.
Изменить его можно, но сути тогда не покажет и если начать его анализировать, то дыру можно выявить 2 метода:
1. Когда было 1, 2, 3, вы заменили на 1, 1, 3, тут мы видим, что данные изменились, но изменения нет
2. Когда как вы уже казали есть второй ЖР на дату проверки и сравнив их видим, что было изменение этот вариант вообще как 2 пальца палит контору.
Когда будет приз?
(136) Итоги конкурса будут подведены 10.08.2019. Но вы не описали схему взлома. Замена 1,2,3 на 1,1,3 - это не схема.
Опишите подробнее: что изменилось и почему эти изменения проверяющий не заметит.
Про систему в банке вы очень вовремя вспомнили. Как по-вашему должна работать такая система? Как обеспечить невозможность изменения задним числом? Можно ли это сделать без блокчейна?
Опишите подробнее: что изменилось и почему эти изменения проверяющий не заметит.
Про систему в банке вы очень вовремя вспомнили. Как по-вашему должна работать такая система? Как обеспечить невозможность изменения задним числом? Можно ли это сделать без блокчейна?
(253) Отредактировал что?
В типовой конфигурации(любой) 1С блокчейна нет, как ее ни настраивай. И опять же, как ее не настраивай, можно, например, поменять местами 10 шт. за 1 рубль на 1 шт. за 10 рублей и никто никогда не заметит.
Запрет изменения документа после проведения - это хорошо, но как вы это сделаете без блокчейна?
В типовой конфигурации(любой) 1С блокчейна нет, как ее ни настраивай. И опять же, как ее не настраивай, можно, например, поменять местами 10 шт. за 1 рубль на 1 шт. за 10 рублей и никто никогда не заметит.
Запрет изменения документа после проведения - это хорошо, но как вы это сделаете без блокчейна?
(260) если 1С будет работать как блокчейн, то сами данные в базе изменить нельзя, а вот журнал поправить можно и не стыковка пойдет по журналу, а по базе будет все красиво.
Также в технологии блокчейна есть важная особенность, что может быть построено несколько веток событий, что и делает хакер, но через 10 минут все алгоритмы делают перепроверку и хакнутый блок быстро отбраковывается. А у вас всего 2 базы. Правильная и не правильная. В итоге будет так что у вас все равно будет кто-то не прав.
И опять же возвращаемся к определению, что не до конца в теме для чего технология и как работает.
Также в технологии блокчейна есть важная особенность, что может быть построено несколько веток событий, что и делает хакер, но через 10 минут все алгоритмы делают перепроверку и хакнутый блок быстро отбраковывается. А у вас всего 2 базы. Правильная и не правильная. В итоге будет так что у вас все равно будет кто-то не прав.
И опять же возвращаемся к определению, что не до конца в теме для чего технология и как работает.
(262) тогда еще лучше. Хакер взломал базу, следов не оставил и все пошло по ...!
А ваши хеши обновил. Т.к. база не распределенная, то и сверять вам нечего и точка на этом.
Возможно бух заметит каких-то новых клиентов и что он платежку леваку отправил, но будет ли настолько внимателен он это большой вопрос!
Поэтому для проверки нужна распределенная структура как блокчейн, а у вас в третий раз повторяю уже не он.
Изначально вы сообщали что есть проверяющий, а на деле это пользователь той же базы.
Беседа с вами уже превращается в фарс!
Может пора задуматься, что грамотно поставленный вопрос это половина сделанного дела.
А у вас даже вопроса нету!
А ваши хеши обновил. Т.к. база не распределенная, то и сверять вам нечего и точка на этом.
Возможно бух заметит каких-то новых клиентов и что он платежку леваку отправил, но будет ли настолько внимателен он это большой вопрос!
Поэтому для проверки нужна распределенная структура как блокчейн, а у вас в третий раз повторяю уже не он.
Изначально вы сообщали что есть проверяющий, а на деле это пользователь той же базы.
Беседа с вами уже превращается в фарс!
Может пора задуматься, что грамотно поставленный вопрос это половина сделанного дела.
А у вас даже вопроса нету!
(268) если вопрос стоит сможет ли при таком раскладе проверяющий узнать поменял ли не подготовленный пользователь данные, то с 99% вероятности, что сможет. Т.к. обмануть любой алгоритм можно, в особенности с хешами.
А вот сможет ли проверяющий узнать что была фальсификация, когда за дело возьмется хакер, то тут вероятность 1% что сможет.
А как он это сможет сделать уже будет зависеть от вашей программы на каком алгоритме она будет работать.
Так что не стройте иллюзий))
А вот сможет ли проверяющий узнать что была фальсификация, когда за дело возьмется хакер, то тут вероятность 1% что сможет.
А как он это сможет сделать уже будет зависеть от вашей программы на каком алгоритме она будет работать.
Так что не стройте иллюзий))
(270) Программа проверки слишком проста, чтобы ее ломать. Проверяешь каждый блок на соотвествие данных в базе хэшу. Проверяешь начальный и конечный ключ. Отдельно проверяешь, чтобы конечный ключ блока N был равен сохраненному ранее значению. В ней, этой программе, символов будет едва ли не столько же, сколько в этом коротком посте. А смысл будет понятен любому школьнику. Что тут ломать?
Если бы ваша оценка в 1% была верна, то в этой теме уже было бы несколько рецептов взлома.
Если бы ваша оценка в 1% была верна, то в этой теме уже было бы несколько рецептов взлома.
(3) Да. Она заключается в том, что вы будете утверждать что ошибок у вас не нашли. Хотя их никто и не искап.
Кстати. Не в рамках Великого Конкурса, а просто вопрос со стороны. Зачем в вашей схеме эта вся имитация бурной деятельности вприсядку, если проверяющий для контроля все равно вынужден заново пречитывать содержимое всех своих документов?
Зачем ему все эти "хэши"?
Кстати. Не в рамках Великого Конкурса, а просто вопрос со стороны. Зачем в вашей схеме эта вся имитация бурной деятельности вприсядку, если проверяющий для контроля все равно вынужден заново пречитывать содержимое всех своих документов?
... запускается регулярно и проверяет соотвествие хэш-сумм и содержимого документов, соотвествие начальных и конечных ключей, и, наконец, соотвествие последнего ключа предыдущей проверки этому же ключу для...
Зачем ему все эти "хэши"?
(3)
Миша вот вам версия, споить баярошником супервизора, пока она будет дрыхнуть подменить хэши коды Махчейна путем глубинного проникновения.
Ну это я предложил исходя из вашего щедрого вознаграждения 5 ифномани.
Если предложить 30-100 ифномани - то уже можно и коньяком спаивать и яблок с мандаринами и шампанского и открытку на новый год.
Бюджеты свыше 1000 инфомани - можно даже в ресторан пригласить и даже еперный театр.
Единственная проблема - последствия возникновения сиротных блоков Махчена, результатом которых будут множество бастардных транзакций Михчейна .
У вас есть версия?
Миша вот вам версия, споить баярошником супервизора, пока она будет дрыхнуть подменить хэши коды Махчейна путем глубинного проникновения.
Ну это я предложил исходя из вашего щедрого вознаграждения 5 ифномани.
Если предложить 30-100 ифномани - то уже можно и коньяком спаивать и яблок с мандаринами и шампанского и открытку на новый год.
Бюджеты свыше 1000 инфомани - можно даже в ресторан пригласить и даже еперный театр.
Единственная проблема - последствия возникновения сиротных блоков Махчена, результатом которых будут множество бастардных транзакций Михчейна .
(37)
(75) С точки зрения чайника: но если мы не учитываем всех реквизитов, то что мешает создать в каждом документе некоторые свои реквизиты(Например, Сумма2) и не выводить их пользователю. В хэш попадают выбранные реквизиты, а в документы и отчеты выводим данные из скрытых, если они отличаются от основных?
Вопрос скорее в целях самообразования.
(75) С точки зрения чайника: но если мы не учитываем всех реквизитов, то что мешает создать в каждом документе некоторые свои реквизиты(Например, Сумма2) и не выводить их пользователю. В хэш попадают выбранные реквизиты, а в документы и отчеты выводим данные из скрытых, если они отличаются от основных?
Вопрос скорее в целях самообразования.
(105) Я - владелец базы. Вы - мой поставщик и, соотвественно, проверяющий.
Мы с вами договорились, что вы поставляете товар по предоплате, но в строго оговоренные сроки. В случае нарушения сроков, с вас удерживается небольшая пеня за каждый день просрочки. Так получается, что сроки вы действительно довольно часто нарушаете на 1-3 дня, но пеня не очень большая.
Далее, я беру и передвигаю один документ на один день в свою пользу. Какие действия с вашей стороны обеспечат гарантированное обнаружение этого?
Мы с вами договорились, что вы поставляете товар по предоплате, но в строго оговоренные сроки. В случае нарушения сроков, с вас удерживается небольшая пеня за каждый день просрочки. Так получается, что сроки вы действительно довольно часто нарушаете на 1-3 дня, но пеня не очень большая.
Далее, я беру и передвигаю один документ на один день в свою пользу. Какие действия с вашей стороны обеспечат гарантированное обнаружение этого?
(108)
А какие сейчас это обеспечивают на тысячах предприятий которые ничего не слышали про блокчейн?
Ведут учёт отгрузки и начисление пени.
Далее, я беру и передвигаю один документ на один день в свою пользу. Какие действия с вашей стороны обеспечат гарантированное обнаружение этого?
А какие сейчас это обеспечивают на тысячах предприятий которые ничего не слышали про блокчейн?
Ведут учёт отгрузки и начисление пени.
(126)Прозрачных для кого? Для меня как для поставщика ваши подсчёты пени значения не имеют. Если вас не устраивает мы берём договор, первичные документы и идём в суд. Зачем нам лишняя прокладка при чём которая находится у вас. Вы без блокчейна не сможете посчитать просрочку?
И ещё вопрос как будет работать блокчейн при исправлении документов задним числом?
И ещё вопрос как будет работать блокчейн при исправлении документов задним числом?
(127) А зачем вам суд, если у вас есть техническая прокладка? Подумайте над этим вопросом.
Приватный блокчейн может работать и с измененными документами. В этой ветке я уже описывал - как. Вкратце, вы добавляете измененный документ в конец журнала.
Для простоты, я не стал добавлять в условия схему работы с измененными документами.
Приватный блокчейн может работать и с измененными документами. В этой ветке я уже описывал - как. Вкратце, вы добавляете измененный документ в конец журнала.
Для простоты, я не стал добавлять в условия схему работы с измененными документами.
(113) Это для того что бы потом вы не изменили условия - если описать так то
1) отправляю Вам документ формирую отчет смотрю что вы его отразили у себя нужным числом и с нужными данными (совпадает с теми данными которые у меня) сохраняю отчет. Отчеты сохраняю каждый день
2) вы меняете дату документа число назад (так как вперед дату вам не выгодно меньше с меня пеней возьмете)
3) Формирую отчет смотрю документы которые еще не отгруженный - вижу что документ изменил свою дату . Вот и все
И мне не надо контролировать все документы , а только те которые еще не отгрузились
+ ещё требование заверить с вашей стороны копии моих отчетов
1) отправляю Вам документ формирую отчет смотрю что вы его отразили у себя нужным числом и с нужными данными (совпадает с теми данными которые у меня) сохраняю отчет. Отчеты сохраняю каждый день
2) вы меняете дату документа число назад (так как вперед дату вам не выгодно меньше с меня пеней возьмете)
3) Формирую отчет смотрю документы которые еще не отгруженный - вижу что документ изменил свою дату . Вот и все
И мне не надо контролировать все документы , а только те которые еще не отгрузились
+ ещё требование заверить с вашей стороны копии моих отчетов
(121) Михаил , с смотря с какой даты считается что я должен отгрузить вам товар , если момента оплаты вами , то да ок фиксируем ваши платежные поручения но тогда ещё проще в клиент банке будет видно реальную дату когда вы оплатили и на данные базы мне уже пофиг
(124) Просрочку считаю я. Мы так с вами решили. Потому что нам надоело. У нас было две базы. Моя и ваша. Я посчитал у себя. Вы посчитали у себя. Ничего не сошлось и мы две недели разбираемся - чей оператор накосячил при вводе данных в базу. По результатам нашего многолетнего сотрудничества, мы выяснили, что ваши и мои операторы косячат 50 на 50.
(128) что за новые условия на счёт того что мне надоело ? И что мои менеджеры косячат Такого не было . Плюс вы сказали что ВЫ МЕНЯЕТЕ ДАТУ документа а не мои менеджеры косячат Поэтому я и просил озвучить все условия сразу , Вы сейчас придумываете ситуацию в угоду себе . Прошу не добавлять условия в приведённый же вами пример. А он был таков - что я отгружаю товар по предоплате , часто с просрочкой вы переносите дату документа что бы мне «насолить» ( опять же вы не уточнили какого документа , далее решили что оплату) я говорю - по-фигу что вы там что-то по меняли я ориентируюсь по дате поступления денег на расчетный счёт и через клиент-банк мне легко доказать когда мне эти деньги пришли
(129)
Да не надейтесь вы - это же Михаил! Он придумает ещё сто тысяч условий, а потом будет говорить - так это ж я с самого начала подразумевал, вы все дураки, а я пророк)) Если вы думаете, что он кому-то что-то заплатит, значит вы счастливчик и ещё мало с ним общались))
Да не надейтесь вы - это же Михаил! Он придумает ещё сто тысяч условий, а потом будет говорить - так это ж я с самого начала подразумевал, вы все дураки, а я пророк)) Если вы думаете, что он кому-то что-то заплатит, значит вы счастливчик и ещё мало с ним общались))
(129) Это не новые условия. Это - вольное сочинение на тему: почему условия такие. Не обращайте внимание.
Итак. Вы полностью повернули ситуацию. Теперь вы считаете просрочку, а не я. И вы думаете - что-то изменилось?
Вы посчитали там у себя, а я вам не доверяю. Может вы ошиблись, когда данные вбивали, а может специально что-то исказили. Что делать будем?
Итак. Вы полностью повернули ситуацию. Теперь вы считаете просрочку, а не я. И вы думаете - что-то изменилось?
Вы посчитали там у себя, а я вам не доверяю. Может вы ошиблись, когда данные вбивали, а может специально что-то исказили. Что делать будем?
(134) Еще раз мне по-фигу на ваши данные , так же как и вам на мои. есть клиент банк по которому прошел платеж есть выписка банка где указана дата операции , и даже если я захочу схитрить , вы спокойно мне скажете : "Постой ка друг , вот выписка банка - деньги капнули тебе на счет такого числа, в договоре указано что после оплаты ты в течении стольких-то дней должен мне отгрузить товар, значит с этого числа и начинаем считать и мне совершено по фигу что ты занес их в свою учетную систему другим числом это твои проблемы" практически такая же фраза будет и с моей стороны если вы что то у себя поменяете в учетной системе , в банке то вы уже не сможете ничего поменять
(135) Вот мы и подошли к пониманию, зачем нужен блокчейн.
Чтобы сказать: "постой-ка, друг, вот выписка", я должен:
1. Отследить сам факт того, что косяк произошел.
2. Определить дату косяка.
3. Получить выписки банка.
4. Обработать выписки банка.
Подумайте над этим.
А раз уж начнете думать, вот вам второй пример.
Когда вы говорили про отчеты в самом начале, вы скорее всего представляли себе некоторую оборотно-сальдовую ведомость. Остаток на начало, приход, расход, остаток на конец. Теперь представьте. Вы поставщик.
1. Вы привезли мне 10 мешков какого-нибудь счастья по цене 1 руб.
2. Я ввел в систему документ поступления.
3. Вы проверили этот документ.
4. Некоторое время спустя, я изменил документ. Вместо 10 мешков по 1 руб. сделал 1 мешок по 10 руб.
5. Вы не можете каждый раз поверять абсолютно все документы, поэтому в отношении старых документов полагаетесь на отчет. Но в вашем отчете все в порядке.
6. Через некоторое время я возвращаю вам 1 мешок, а 9 оставляю себе.
Чтобы сказать: "постой-ка, друг, вот выписка", я должен:
1. Отследить сам факт того, что косяк произошел.
2. Определить дату косяка.
3. Получить выписки банка.
4. Обработать выписки банка.
Подумайте над этим.
А раз уж начнете думать, вот вам второй пример.
Когда вы говорили про отчеты в самом начале, вы скорее всего представляли себе некоторую оборотно-сальдовую ведомость. Остаток на начало, приход, расход, остаток на конец. Теперь представьте. Вы поставщик.
1. Вы привезли мне 10 мешков какого-нибудь счастья по цене 1 руб.
2. Я ввел в систему документ поступления.
3. Вы проверили этот документ.
4. Некоторое время спустя, я изменил документ. Вместо 10 мешков по 1 руб. сделал 1 мешок по 10 руб.
5. Вы не можете каждый раз поверять абсолютно все документы, поэтому в отношении старых документов полагаетесь на отчет. Но в вашем отчете все в порядке.
6. Через некоторое время я возвращаю вам 1 мешок, а 9 оставляю себе.
(138) ещё раз мне не нужен ваш журнал и ваша база , не нужно каждый день что-то проверять , мне достаточно в момент спора просто обратиться к выписки банка , а не сидеть и контролировать ваших менеджеров ,а со своими я сам разберусь
По поводу второго примера - если у вас есть 10 мешков значит я вам их отгрузил , значит на руках есть подписанная вами Товарная накладная ТОРГ - 12 - дальше спорим ?
По поводу второго примера - если у вас есть 10 мешков значит я вам их отгрузил , значит на руках есть подписанная вами Товарная накладная ТОРГ - 12 - дальше спорим ?
(140) не понял вас - подписанный вами официальный документ - уже не документ ? У меня с вами в день 1000 отгрузок ? Найти нужную мне не составит труда . Я понимаю что такое блокчейн , но вот ваш «блокчейн» я не понимаю ещё раз вам приводили пример
Пусть есть 2 идентичные базы , основная и копия основной базы , из первой базы по средством обработки переносятся данные во вторую что бы все было идентично , т.е. начальные блоки идентичные и хэши идентичные , далее первую базу вносится документ , и далее он переносится во вторую базу и там изменяется , и вторая база заменяет первую . В итоге проверяющий по хэшам не заметит ничего , а данные изменены. Далее вы утверждаете что проверяющий может смотреть данные базы и может посмотреть документ , но тогда Сёму ему верить если хеши в журнале совпадают , а данные документа нет ? Плюс вы говорите есть 1000 документов он что должен каждый тогда проверить ?
Пусть есть 2 идентичные базы , основная и копия основной базы , из первой базы по средством обработки переносятся данные во вторую что бы все было идентично , т.е. начальные блоки идентичные и хэши идентичные , далее первую базу вносится документ , и далее он переносится во вторую базу и там изменяется , и вторая база заменяет первую . В итоге проверяющий по хэшам не заметит ничего , а данные изменены. Далее вы утверждаете что проверяющий может смотреть данные базы и может посмотреть документ , но тогда Сёму ему верить если хеши в журнале совпадают , а данные документа нет ? Плюс вы говорите есть 1000 документов он что должен каждый тогда проверить ?
(144) Вадим, Мишаня предлагает вообще отказаться от подписи. Он считает что в приватном махчейне она излишняя и лишь увеличивает длину блока. Поэтому в махчейне все построено на доверии в махчейне.
В Махчейне цепочки пересчитываются подобно человеческому ДНК. Супервизор у него подобно иммунной системы хранит всю цепочку и в режиме онлайн ретранслирует по всей базе с помощью 10 в миллионной степени слойной нейронно-ректальной сети . Это революция прорыв в ректальном махчейне.
Так что если ваши блоки станут сиротные , а документы пропадут... это кара Махчейна, надо забыть и простить.
В Махчейне цепочки пересчитываются подобно человеческому ДНК. Супервизор у него подобно иммунной системы хранит всю цепочку и в режиме онлайн ретранслирует по всей базе с помощью 10 в миллионной степени слойной нейронно-ректальной сети . Это революция прорыв в ректальном махчейне.
Так что если ваши блоки станут сиротные , а документы пропадут... это кара Махчейна, надо забыть и простить.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот