Проверка возможности взлома приватного блокчейна
Предлагаю вознаграждение тому, кто опишет способ взлома приватного блокчейна.
Условия следующее:
Есть база данных. Пусть это будет типовая БП. Есть один владелец базы. У него есть полный доступ к базе и возможность делать любые транзакции. Владелец базы хочет, чтобы его действия стали прозрачными для некоторого контрагента, который является его поставщиком, и которого мы дальше будем называть проверяющим. С этой целью он создает журнал на основе блокчейна. Журнал содержит ИД документа, хэш документа, хэш начальный и хэш конечный. Владелец базы дает проверяющему доступ на чтение к базе и доступ на чтение к журналу. Проверяющий создает сам или получает от Владельца программу проверки. Как именно - не важно, потому что, в любом случае код проверяющей программы открыт и находится под контролем Проверяющего. Эта программа запускается регулярно и проверяет соотвествие хэш-сумм и содержимого документов, соотвествие начальных и конечных ключей, и, наконец, соотвествие последнего ключа предыдущей проверки этому же ключу для текущей проверки. Т.е. провели проверку журнала. Последний блок Х содержал ключ Y. Через некоторое время проводим проверку снова и проверяем, чтобы конечный ключ блока Х был равен Y.
Прозрачность заключается в том, что Проверяющий после каждой проверки будет получать список новых документов. И может быть уверен, что никакие старые документы не менялись и не удалялись.
Для получения вознаграждения требуется описать последовательность действий Владельца с базой и с журналом, которая приведет к тому, что эти действия будут скрыты от Проверяющего. Требуется привести доказательства того, что сам факт этих действий не будет зарегистрирован проверяющей программой.
Срок проведения данного конкурса - до 10.08.2019.
Условия следующее:
Есть база данных. Пусть это будет типовая БП. Есть один владелец базы. У него есть полный доступ к базе и возможность делать любые транзакции. Владелец базы хочет, чтобы его действия стали прозрачными для некоторого контрагента, который является его поставщиком, и которого мы дальше будем называть проверяющим. С этой целью он создает журнал на основе блокчейна. Журнал содержит ИД документа, хэш документа, хэш начальный и хэш конечный. Владелец базы дает проверяющему доступ на чтение к базе и доступ на чтение к журналу. Проверяющий создает сам или получает от Владельца программу проверки. Как именно - не важно, потому что, в любом случае код проверяющей программы открыт и находится под контролем Проверяющего. Эта программа запускается регулярно и проверяет соотвествие хэш-сумм и содержимого документов, соотвествие начальных и конечных ключей, и, наконец, соотвествие последнего ключа предыдущей проверки этому же ключу для текущей проверки. Т.е. провели проверку журнала. Последний блок Х содержал ключ Y. Через некоторое время проводим проверку снова и проверяем, чтобы конечный ключ блока Х был равен Y.
Прозрачность заключается в том, что Проверяющий после каждой проверки будет получать список новых документов. И может быть уверен, что никакие старые документы не менялись и не удалялись.
Для получения вознаграждения требуется описать последовательность действий Владельца с базой и с журналом, которая приведет к тому, что эти действия будут скрыты от Проверяющего. Требуется привести доказательства того, что сам факт этих действий не будет зарегистрирован проверяющей программой.
Срок проведения данного конкурса - до 10.08.2019.
Найденные решения
(282)
Например мне удалось найти коллизию и я поменял контрагента и адрес, так что бы в сумме хеш по алгоритму не изменился. Вы будете видеть все тот же документ, но с отличными данными, ключи совпадут. Если ваш хеш алгоритм уникален для любого состава данных, то это по сути версионирование, снимок последнего состояния. Это уже не совсем хеш.
Как поможет соль - просто нереально будет определить алгоритм хеширования по хеш-таблице, точнее, цена поиска будет стремиться к безконечности и будет не выгодна.
Например мне удалось найти коллизию и я поменял контрагента и адрес, так что бы в сумме хеш по алгоритму не изменился. Вы будете видеть все тот же документ, но с отличными данными, ключи совпадут. Если ваш хеш алгоритм уникален для любого состава данных, то это по сути версионирование, снимок последнего состояния. Это уже не совсем хеш.
Как поможет соль - просто нереально будет определить алгоритм хеширования по хеш-таблице, точнее, цена поиска будет стремиться к безконечности и будет не выгодна.
(1) ручная операция сторно документов ( или просто ручные операции) , позволит изменить движения документов ( хотя и текущим числом ) для проверочной программы это будет как новый документ , и по сути основной документ не меняется и хеши будут сходится ( ведь движения меняем в другим документом ) но данные для базы будут изменены можно например полностью сторнировать движения документов.
(1) кто помешает
1. переименовать Поставщика и получателя и получить те же документы с другими контрагентами? В Журналах(документах) только ссылки на справочники. Сами данные справочников в журнале не сохраняются.
2. обработкой поменять записи в регистрах не затрагивая сами документы. Журнал данные регистра не хранит.
1. переименовать Поставщика и получателя и получить те же документы с другими контрагентами? В Журналах(документах) только ссылки на справочники. Сами данные справочников в журнале не сохраняются.
2. обработкой поменять записи в регистрах не затрагивая сами документы. Журнал данные регистра не хранит.
Остальные ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(134)
Если не договоримся то пойдём в суд.
Вот вам и ответ:
Когда ваша техническая прокладка будет обязательна к исполнению так же как и решение суда тогда можно говорить об этом. А пока это только в ваших фантазиях.
У нас 30 менеджеров ежедневно управляют закупками и отгрузками трём сотням контрагентов, там всегда что то правят задним числом. Вот это вы упростили.
Что делать будем?
Если не договоримся то пойдём в суд.
Вот вам и ответ:
А зачем вам суд
если у вас есть техническая прокладка?
Когда ваша техническая прокладка будет обязательна к исполнению так же как и решение суда тогда можно говорить об этом. А пока это только в ваших фантазиях.
Для простоты, я не стал добавлять в условия схему работы с измененными документами.
У нас 30 менеджеров ежедневно управляют закупками и отгрузками трём сотням контрагентов, там всегда что то правят задним числом. Вот это вы упростили.
(156) Вы придумали схему с подменой журнала. А я вам отвечаю, что проверка каждый раз фиксирует последний ключ. И на следующей итерации будет выявлена подмена журнала. Вы дадите мне формально правильный журнал. В нем все блоки будут соотвествовать друг-другу и данным базы. Но этот журнал будет другим ровно с того места, где вы внесли свои изменения и до самого конца. И я это обнаружу.
(157) смотрите еще раз, в двух базах (первая - основная , вторая клон первой - копия ) данные одинаковые ,на момент моей операции хеши одинаковые , при внесении нового документа в базу что я делаю - сначала вношу документ во вторую базу(копию) с уже измененными(неверными ) данными и заменяю ей первую (основную)
(158) Продумывая схему с двумя базами, вы сами себя путаете.
Заменяя одну базу на другую, вы должны заменить и журнал. Поэтому такая замена ничего вам не даст.
У вас есть База1 и Журнал1, а также База2 и Журнал2. Вы не можете заменить База1 на База2, не променяв Журнал1 на Журнал2. Но замена журнала будет обнаружена.
Заменяя одну базу на другую, вы должны заменить и журнал. Поэтому такая замена ничего вам не даст.
У вас есть База1 и Журнал1, а также База2 и Журнал2. Вы не можете заменить База1 на База2, не променяв Журнал1 на Журнал2. Но замена журнала будет обнаружена.
(159) Да идет замена базы 1 на базу 2 а так же журнала 1 на журнал 2 Я не понимаю как будет обнаружена замена если были заменены и журнал. И журнал соответствует базе полностью какие хэши будут отличатся ? Все блоки включая последние в двух базах одинаковые , а вот новый блок (новый документ) будет для каждой базы свой , но это же новый блок значит он попадет клиенту как новый документ и попадет из второй базы где он неправильный
(161) Вот смотрите я беру вашу базу файл 1cv8.1cd и копирую его в сторону и пока ничего не меняю
вопрос сейчас Журнал 1 = Журнал 2 ?
Если я заменю базы заметит ли это проверяющий ? Что то у него изменится будет ли он видеть такую замену ? Еще раз - файл я только скопировал и ничего не менял
вопрос сейчас Журнал 1 = Журнал 2 ?
Если я заменю базы заметит ли это проверяющий ? Что то у него изменится будет ли он видеть такую замену ? Еще раз - файл я только скопировал и ничего не менял
(168) вопрос в том , как вы докажите проверяющему что документ внесён вами правильно. Т.е. как вы сами и сказали что нужен контроль , что бы не внесли некорректные данные - вопрос а нужен ли мне как проверяющему такой Геморой , а если я один раз случайно забуду такую проверку или у меня действительно большой объём документов ?
(169) Эта тема была создана для того, чтобы выяснить: есть ли способ внести незаметные изменения в приватный блокчейн.
Давайте обсуждать его.
Поймите меня. Я в принципе не против обсуждать вопрос: а нужен ли вообще приватный блокчейн. И я вам рассказал - почему я считаю, что нужен. Вы не поняли. Я еще раз рассказал. Вы снова не поняли. Мы с вами ходим по кругу. И все в стороне от основного вопроса.
Давайте обсуждать его.
Поймите меня. Я в принципе не против обсуждать вопрос: а нужен ли вообще приватный блокчейн. И я вам рассказал - почему я считаю, что нужен. Вы не поняли. Я еще раз рассказал. Вы снова не поняли. Мы с вами ходим по кругу. И все в стороне от основного вопроса.
(170)
Так опубликуйте ваш блокчейн в виде сервиса и создайте статью где нибудь на хабре. Там умельцев много, они вам помогут, теоретизировать вы можете тут долго.
Вот Дуров разместил код, предложили вознаграждение, кому то даже 10К баксов выплатили.
есть ли способ внести незаметные изменения в приватный блокчейн.
Так опубликуйте ваш блокчейн в виде сервиса и создайте статью где нибудь на хабре. Там умельцев много, они вам помогут, теоретизировать вы можете тут долго.
Вот Дуров разместил код, предложили вознаграждение, кому то даже 10К баксов выплатили.
(164) Каждый новый документ, конечно, проверяется. Блокчейн не для того, чтобы не проверять документы совсем. Это - невозможно. Блокчейн для того, чтобы проверять их один раз.
Без блокчейна вам требуется проверять каждый раз все документы от начала и до конца. С блокчейном вы проверяете только те документы, которые появились в базе с момента последней проверки. А все прочие вам проверять не надо. Вы их уже когда-то проверяли и с тех пор они не менялись. Блокчейн вам это гарантирует.
Без блокчейна вам требуется проверять каждый раз все документы от начала и до конца. С блокчейном вы проверяете только те документы, которые появились в базе с момента последней проверки. А все прочие вам проверять не надо. Вы их уже когда-то проверяли и с тех пор они не менялись. Блокчейн вам это гарантирует.
Ну допустим так
1) раз вы написали журнал то у вас есть возможность изменить код незаметно для владельца , значит вы можете ему вернуть любой хэш ( например предварительно рассчитанный в другой базе ) и настраиваете журнал так что бы он при вводе нового документа возвращал сформированный вами заранее хеш ( т.е. проверяющий видит нужные данные , но хеш вы вернули другой)
Далее меняете последний документ пользователя таким образом что бы он соотвественно тому хешу что вы передали пользователю ) при очередной проверке все сойдётся , по условию в примере журнал находится у вас и проверяющий имеет только доступ на чтение к этому журналу. Раз он не видит ошибок в журнале значит он не полезет проверять сам документ. Если вы скажите что у него есть доступ на чтение к данным , то я возражу вашими же словами из (166) или вы опять предлагаете каждый день проверяющему лезть вашу базу и формировать ваши или свои отчеты что бы проверить что ничего не изменилось )
1) раз вы написали журнал то у вас есть возможность изменить код незаметно для владельца , значит вы можете ему вернуть любой хэш ( например предварительно рассчитанный в другой базе ) и настраиваете журнал так что бы он при вводе нового документа возвращал сформированный вами заранее хеш ( т.е. проверяющий видит нужные данные , но хеш вы вернули другой)
Далее меняете последний документ пользователя таким образом что бы он соотвественно тому хешу что вы передали пользователю ) при очередной проверке все сойдётся , по условию в примере журнал находится у вас и проверяющий имеет только доступ на чтение к этому журналу. Раз он не видит ошибок в журнале значит он не полезет проверять сам документ. Если вы скажите что у него есть доступ на чтение к данным , то я возражу вашими же словами из (166) или вы опять предлагаете каждый день проверяющему лезть вашу базу и формировать ваши или свои отчеты что бы проверить что ничего не изменилось )
(224) ну и где это в условии ?
Там написано что имеет только доступ на чтение , и как вы себе этот представляете ? Я должен каждый раз проверять вашу обработку ? Что бы вы не внесли в один прекрасный день изменения ? И как я должен это делать ?
С этой целью он создает журнал на основе блокчейна. Журнал содержит ИД документа, хэш документа, хэш начальный и хэш конечный. Владелец базы дает проверяющему доступ на чтение к базе и доступ на чтение к журналу
Там написано что имеет только доступ на чтение , и как вы себе этот представляете ? Я должен каждый раз проверять вашу обработку ? Что бы вы не внесли в один прекрасный день изменения ? И как я должен это делать ?
(238) Если вы измените код программы, которая генерит журнал, тогда этот код перестанет соотвествовать коду проверяющей программы.
У владельца программа создающая журнал. А у проверяющего программа, которая его проверяет. Чтобы ваша схема заработала надо найти способ изменить код обеих программ.
У владельца программа создающая журнал. А у проверяющего программа, которая его проверяет. Чтобы ваша схема заработала надо найти способ изменить код обеих программ.
(240) До восстановления кода в его исходном состоянии, программа проверки ничего не заметит.
Я не рассматриваю это как реальную схему взлома. Хотя бы потому, что если в компании не налажен контроль за тем, что там у них запускается, то такой компании вообще уже ничто не поможет.
Но формально вы правы.
Я не рассматриваю это как реальную схему взлома. Хотя бы потому, что если в компании не налажен контроль за тем, что там у них запускается, то такой компании вообще уже ничто не поможет.
Но формально вы правы.
(241) Ну не будет же каждый раз менеджер ( а допустим это девушка ) лезть в конфигуратор и проверять свою (или вашу ) обработку на факт изменения. Просто смысл отпадает в вашем блокчейне , ели проверяющий должен многое контролировать.
Я считаю что привёл рабочий пример взлома, который имеет место быть , вы сами это только что подтвердили. А рассматриваете ли вы лично это вариант или нет мне все равно. Если даже у больших компаний бывает что сотрудники по какой-то причине сливают данные ( те же базы данных клиентов )
Я считаю что привёл рабочий пример взлома, который имеет место быть , вы сами это только что подтвердили. А рассматриваете ли вы лично это вариант или нет мне все равно. Если даже у больших компаний бывает что сотрудники по какой-то причине сливают данные ( те же базы данных клиентов )
(245) навеяло
Возвращается Чапаев из командировки в Англию. Одет весь с иголочки, в лимузине, на руках перстни с бриллиантами. Полный багажник денег. Носильщики выносят кучу чемоданов.
Петька его удивленно спрашивает:
- Василий Иванович, откуда у тебя все это?
- Да так, Петька, в карты выиграл.
- Как это?
- Захожу я в клуб. Там все сидят, выпивают, в карты играют. Присмотрелся - в очко режутся! Сел я за столик, взял карты. У меня - 18. А мой соперник-англичанин говорит - 20. Я ему: "Покажи!" А он - мне: "Мы, джентльмены, верим на слово". Вот тут-то мне как поперло, как поперло...
Петька его удивленно спрашивает:
- Василий Иванович, откуда у тебя все это?
- Да так, Петька, в карты выиграл.
- Как это?
- Захожу я в клуб. Там все сидят, выпивают, в карты играют. Присмотрелся - в очко режутся! Сел я за столик, взял карты. У меня - 18. А мой соперник-англичанин говорит - 20. Я ему: "Покажи!" А он - мне: "Мы, джентльмены, верим на слово". Вот тут-то мне как поперло, как поперло...
(108) снова общие фразы. Какие данные хранятся в журнале? Точно по графам. К каким данным есть доступ у проверяющего? Точно.
Журнал у проверяющего не хранится. Иначе смысл всего этого "блокчейна".
Как проверяющий докажет, что были изменения, если даже увидит расхождение?
Журнал у проверяющего не хранится. Иначе смысл всего этого "блокчейна".
Как проверяющий докажет, что были изменения, если даже увидит расхождение?
(111) Какие данные хранятся в журнале, я написал в условии. Точно по графам. У проверяющего есть доступ на чтение к базе, ко всей. Проверяющий может хранить журнал, а может и не хранить. Это - его личное дело. И это никак не влияет на работоспособность схемы. Проверяющему не надо ничего доказывать, достаточно того, что он увидит.
(115) Откатили цепочку с документами. Переделали документы. Перестроили цепочку. С виду все хорошо. Если проверяющий не хранит у себя копию журнала, то как он поймет, что были изменения? Если поймет, то как докажет, что были изменения?
(115)
Вы их уже несколько раз пересматривали. Хотелось бы точно знать конкретные значения. Хотя бы на примере.
(115)
Какие данные хранятся в журнале, я написал в условии
Вы их уже несколько раз пересматривали. Хотелось бы точно знать конкретные значения. Хотя бы на примере.
(98)
При всем уважении, я абсолютно перестал понимать что у кого есть и чего нет. Изначально про то, что проверяющий будет писать свои отчеты ничего не было. Более того мы обсудили, что доступа к коду у проверяющего нет.
Ведь есть стандартные отчеты - проверяющий во время создания документа смотрит-все нормально - сходится. Потом мы меняем скрытые реквизиты, данные в документе и отчете меняются, по журналу ничего подозрительного нет - проверяющий по умолчанию верит.
В блокчейне я понимаю чуть менее чем ничего, но почему мой вариант невозможен? Понятно, что если он залезет в код он все увидит, но все таки, по условию у него доступа нет.
При всем уважении, я абсолютно перестал понимать что у кого есть и чего нет. Изначально про то, что проверяющий будет писать свои отчеты ничего не было. Более того мы обсудили, что доступа к коду у проверяющего нет.
Ведь есть стандартные отчеты - проверяющий во время создания документа смотрит-все нормально - сходится. Потом мы меняем скрытые реквизиты, данные в документе и отчете меняются, по журналу ничего подозрительного нет - проверяющий по умолчанию верит.
В блокчейне я понимаю чуть менее чем ничего, но почему мой вариант невозможен? Понятно, что если он залезет в код он все увидит, но все таки, по условию у него доступа нет.
(143) Потому что есть данные, а есть интерпретация данных. И нас интересует в данном случае задача достоверности данных.
Есть и другая задача. Как добиться одинаковой интерпретации данных одной и другой стороной. Но она тривиальна и мы ее здесь не рассматриваем.
Есть и другая задача. Как добиться одинаковой интерпретации данных одной и другой стороной. Но она тривиальна и мы ее здесь не рассматриваем.
Миша опять ты вело-поезд городишь? Блокчейн без подписи?
Раз минуту/день/месяц/ или в каждую операцию Проверяющий подписывает цепь Приватным ключом.
Далее видно на каком блоке кто подписал цепочку. Без подписей кому твоя цепочка нужна?
Если вы так ненавидите классический блокчейн от Сатоши с RSA эцп и PoW - можете использовать любой ректальный подход к блокчену, к примеру:
Сделай цепочку штрихкодов, и каждый день делай наколку их контрольного хеша на правой ягодице Супервизора .
Задница Супервизора будет как доказательство доли или PoS (proof of Stake), а первая запись будет первым ректально-генезисным блоком без ЭЦП
Думаю такой подход сработает - при условии приватности носителя (приватного носителя Супервизора).
Так же можете ввести в эксплуатацию сканер крипто-кода с нейроно -ректальной сетью с 7 нанометрами внутри. Заказать можно в Bitmain.
Когда ваш ректо-блокчейн разрастется и некуда будет вписывать ваши блоки - сделаете ХардФорк со сменой носителя с более емким задом или переход на классический блокчейн с подписью Шнора.
Только учтите что данный вайтпепер к щиткоину с ректальным подходом к блокчейну принадлежит мне. ;-) m@g 2019
Раз минуту/день/месяц/ или в каждую операцию Проверяющий подписывает цепь Приватным ключом.
Далее видно на каком блоке кто подписал цепочку. Без подписей кому твоя цепочка нужна?
Если вы так ненавидите классический блокчейн от Сатоши с RSA эцп и PoW - можете использовать любой ректальный подход к блокчену, к примеру:
Сделай цепочку штрихкодов, и каждый день делай наколку их контрольного хеша на правой ягодице Супервизора .
Задница Супервизора будет как доказательство доли или PoS (proof of Stake), а первая запись будет первым ректально-генезисным блоком без ЭЦП
Думаю такой подход сработает - при условии приватности носителя (приватного носителя Супервизора).
Так же можете ввести в эксплуатацию сканер крипто-кода с нейроно -ректальной сетью с 7 нанометрами внутри. Заказать можно в Bitmain.
Когда ваш ректо-блокчейн разрастется и некуда будет вписывать ваши блоки - сделаете ХардФорк со сменой носителя с более емким задом или переход на классический блокчейн с подписью Шнора.
Только учтите что данный вайтпепер к щиткоину с ректальным подходом к блокчейну принадлежит мне. ;-) m@g 2019
3. Потому что акты сверок их не устраивают. Они их делали много раз и ничего не сходилось. Тогда у проверяющего возникла идея: а давайте сделаем так, что я буду видеть все, что вы вносите в базу. Тогда я возьму данные, сам их агрегирую и убежусь, что косяк на моей стороне.
проблема актов сверок решается одним грамотным бухгалтером и умением пользоваться датой запрета редактирования
но нет, лучше создадим решение, от которого нормальный владелец бизнеса придет в ужас (ага, давайте запустим к себе в базу 10 000 контрагентов, пусть смотрят что хотят), назовем модным словом "блокчейн" и народ схавает, а то что заявленную задачу этот псевдоблокчейн не решает ни кого не волнует
Как то был у Дмитрий Потапенко, он мне сказал что бизнес в России не готов признавать частные блокчейны.
Так как цель каждого предпринимателя - уход от налогов. Сама по себе излишняя прозрачность даст дополнительные инструменты для налоговых преследований и в приватность шифрования он не верит.
А Сам по себе Биткоин - был признан для упрощения возможности ухода от излишнего бремени государственной повинности и оброка.
Так что говорит идите со своими частными блокчейнами далеко и поздорову. Ваши говорит дорогие услуги по 1С они и так если тянут... а если еще и блокчены внедрите - то будет полный абзац - идеи ваши лукавые и имя вам "Легион".
Так как цель каждого предпринимателя - уход от налогов. Сама по себе излишняя прозрачность даст дополнительные инструменты для налоговых преследований и в приватность шифрования он не верит.
А Сам по себе Биткоин - был признан для упрощения возможности ухода от излишнего бремени государственной повинности и оброка.
Так что говорит идите со своими частными блокчейнами далеко и поздорову. Ваши говорит дорогие услуги по 1С они и так если тянут... а если еще и блокчены внедрите - то будет полный абзац - идеи ваши лукавые и имя вам "Легион".
(45) Я наемный программист, программирую исключительно за деньги.
Безвозмездно работаю только на различные учреждения типа школы для детей-инвалидов итп.
И иногда по настроению выкладываю некоторые обработки в массы.
И вообще уязвмости чего. Ваш проект фуфельный, я вам свою рецензию уже не раз озвучивал.
Безвозмездно работаю только на различные учреждения типа школы для детей-инвалидов итп.
И иногда по настроению выкладываю некоторые обработки в массы.
И вообще уязвмости чего. Ваш проект фуфельный, я вам свою рецензию уже не раз озвучивал.
(48) От вас ничего особенного не требуется. Просто поразмышлять на некую тему, а потом написать пост. Собственно вы это и так делаете в изрядном количестве, бесплатно, и без особого смысла. А тут вы принесете определенную пользу и получите скромное вознаграждение. Соглашайтесь )))
(49)
И вы думаете что я напишу положительную рецензию на ваш код за 5 шейкелей?
Любой программист который понимает принцип блокчейна скажет вам то же самое что и я.
Так что идите:
1. Для начала изучите что такое SegWit(Segregated Witness).
2. Изучите что такое Agrigated Witness или подпись Шнора.
3. Чем отличается от принципа RSA
4. Может быть и вы облагоразумитесь. Одним понимающим программистом больше уже достижение для экосистемы.
Если нет - то дураков с говн*кодом и без вас хватает.
ю тему, а потом написать пост. Собственно вы это и так делаете в изрядном количестве, бесплатно, и без особого смысла. А тут вы принесете определенную пользу и получите скромное вознаграждение. Соглашайтесь
И вы думаете что я напишу положительную рецензию на ваш код за 5 шейкелей?
Любой программист который понимает принцип блокчейна скажет вам то же самое что и я.
Так что идите:
1. Для начала изучите что такое SegWit(Segregated Witness).
2. Изучите что такое Agrigated Witness или подпись Шнора.
3. Чем отличается от принципа RSA
4. Может быть и вы облагоразумитесь. Одним понимающим программистом больше уже достижение для экосистемы.
Если нет - то дураков с говн*кодом и без вас хватает.
(51) Так я же тебе по русски говорю: фигня это все твое творчество.
По твоему проверяющий должен будет на каждом этапе получения документов хранить хеш-сумму предыдущего блока данных.
В какой то момент проверяющий обнаружит что Остатки или Сумма остатков не соответствует действительности. или Вася скажет не я делал эти документы.
И как вы будите проверять все ваши блоки?
В итоге проверяющий скажет что за херню вы тут нагородили? Где методика проверки остатков? или инструмент перерасчета цепи блокчейна?
Их просто нету так как вы
1. собираетесь хешировать неструктурированные блоки (в структурных блоках содержится ИД транзакции, хеш пред блока, Отправитель, получатель, сумма траты и подпись). А вы собираетесь кусок с данными документов 1С записхивать в блоки.. это деже не блоки -это кусок данных
2. Ваши блоки не содержат подписи траты
3. Ваши блоки не заверены Майнером или Супервизором с Подписью
Итого - как вся эта мутатень или неструктурированный кусок хэш данных.
Или вы тут хотите протокол передачи данных изобрести? (В сеть подается пакет - а назад возвращается контрольная сумма)
TCP/IP уже давно придуман без вашего участия. Только причем тут блок-чейн?
Так что я пас - Намотайте свои цепи себе на шею или куда угодно. Вас не возможно переубедить...
Вы и ваши убеждения есть ошибка консенсуса.
По твоему проверяющий должен будет на каждом этапе получения документов хранить хеш-сумму предыдущего блока данных.
В какой то момент проверяющий обнаружит что Остатки или Сумма остатков не соответствует действительности. или Вася скажет не я делал эти документы.
И как вы будите проверять все ваши блоки?
В итоге проверяющий скажет что за херню вы тут нагородили? Где методика проверки остатков? или инструмент перерасчета цепи блокчейна?
Их просто нету так как вы
1. собираетесь хешировать неструктурированные блоки (в структурных блоках содержится ИД транзакции, хеш пред блока, Отправитель, получатель, сумма траты и подпись). А вы собираетесь кусок с данными документов 1С записхивать в блоки.. это деже не блоки -это кусок данных
2. Ваши блоки не содержат подписи траты
3. Ваши блоки не заверены Майнером или Супервизором с Подписью
Итого - как вся эта мутатень или неструктурированный кусок хэш данных.
Или вы тут хотите протокол передачи данных изобрести? (В сеть подается пакет - а назад возвращается контрольная сумма)
TCP/IP уже давно придуман без вашего участия. Только причем тут блок-чейн?
Так что я пас - Намотайте свои цепи себе на шею или куда угодно. Вас не возможно переубедить...
Вы и ваши убеждения есть ошибка консенсуса.
(52) Убедить или разубедить кого-то. Вопрос вообще так не ставится. Эта ветка сделана для поиска уязвимостей. Если вы видите такие, то опишите. Пока вы говорите не понятно.
Какие, конкретно, действия владельца приведут к тому, что проверяющий пропустит факт изменения данных?
Какие, конкретно, действия владельца приведут к тому, что проверяющий пропустит факт изменения данных?
(53)
Вася изменит документ дветысячилохматого года и вся ваша цепочка станет сиротной. Как вы потом дальше будите все восстанавливать?
И весь ваш обмен встанет. наглухо. Будите бегать искать копии чтобы выйти в конрольный хеш.. а не сможете
Какие, конкретно, действия владельца приведут к тому, что проверяющий пропустит факт изменения данных?
Вася изменит документ дветысячилохматого года и вся ваша цепочка станет сиротной. Как вы потом дальше будите все восстанавливать?
И весь ваш обмен встанет. наглухо. Будите бегать искать копии чтобы выйти в конрольный хеш.. а не сможете
(58) Еще раз. Изменение документа приводит к тому, что проверка зафиксирует расхождение хэша и данных документа. Но, эта же проверка увидит, что документ помечен, как измененный и будет ожидать его появления далее в цепочке. Цепочку перестраивать не надо. Достаточно просто помечать измененные документы.
Но мы с вами удаляемся от темы. Я не ставил вопрос: как организовать контроль изменяющихся "задним числом" документов. Считайте что такие изменения запрещены. Любые изменения оформляются новым документом.
Но мы с вами удаляемся от темы. Я не ставил вопрос: как организовать контроль изменяющихся "задним числом" документов. Считайте что такие изменения запрещены. Любые изменения оформляются новым документом.
(60) Я достаточно четко их сформулировал. Этот кусок дискуссии, как я уже сказал, лежит несколько в стороне.
Смотрите. Человек мне говорит: а я возьму и поменяю старый документ, что вы тогда делать будете?
Но вопрос так не стоял. Я не спрашивал, что мне делать в случае изменения старого документа.
Я спрашивал - возможно ли сделать такое изменение незаметным.
Смотрите. Человек мне говорит: а я возьму и поменяю старый документ, что вы тогда делать будете?
Но вопрос так не стоял. Я не спрашивал, что мне делать в случае изменения старого документа.
Я спрашивал - возможно ли сделать такое изменение незаметным.
1. В исходном посте нет ничего про движения.
2. Фиксируется любое изменение документа, или только меняющее движения, или только изменение, меняющее количественный/суммовой итог в документе для конкретного контрагента?
3. При снятии копий базы и журнала, остановки исходной базы, и запуске копий без изменений всё нормально?
2. Фиксируется любое изменение документа, или только меняющее движения, или только изменение, меняющее количественный/суммовой итог в документе для конкретного контрагента?
3. При снятии копий базы и журнала, остановки исходной базы, и запуске копий без изменений всё нормально?
(72) 1. С движениями есть над чем подумать. Видимо, проще всего будет просто игнорировать их. Собственно для проверки они не так уж важны. Сама тема с движениями - полезная, как я уже это признал.
2. А это принципиально? Можно строить хэш на основе абсолютно всех реквизитов. Можно предоставить пользователю возможность определять - какие реквизиты значимые, а какие нет.
3. Это как? Ведем две базы? Одну показываем проверяющему, а вторую не показываем? А кому мы ее тогда показываем? Самим себе? А смысл?
2. А это принципиально? Можно строить хэш на основе абсолютно всех реквизитов. Можно предоставить пользователю возможность определять - какие реквизиты значимые, а какие нет.
3. Это как? Ведем две базы? Одну показываем проверяющему, а вторую не показываем? А кому мы ее тогда показываем? Самим себе? А смысл?
(75) 1. Если движения не нужны, тогда упоминание в условиях "Типовой БП" бессмысленно
2. Это принципиально для постановки задачи, так как непонятно, что же мы на самом деле защищаем от изменения.
3. Это просто уточняющий вопрос - мы контролируем, что работаем с одной конкретной базой, или база в любой момент может быть замещена другой, аналогичной на некоторый момент времени.
2. Это принципиально для постановки задачи, так как непонятно, что же мы на самом деле защищаем от изменения.
3. Это просто уточняющий вопрос - мы контролируем, что работаем с одной конкретной базой, или база в любой момент может быть замещена другой, аналогичной на некоторый момент времени.
(77) 1. Можно контролировать содержание документов и не контролировать их интерпретацию.
2. Не принципиально. Если вы докажете, что есть лазейка, позволяющая владельцу изменить данные незаметно, это будет означать, что защитить нельзя ничего. Ни документ целиком, ни какую-либо его часть.
3. Если вы откатили базу назад, скажем, на один день, то эта операция аналогична удалению документов за один день.
2. Не принципиально. Если вы докажете, что есть лазейка, позволяющая владельцу изменить данные незаметно, это будет означать, что защитить нельзя ничего. Ни документ целиком, ни какую-либо его часть.
3. Если вы откатили базу назад, скажем, на один день, то эта операция аналогична удалению документов за один день.
(94) Для проверяющего все правильно, если хэши соответствуют данным в базе и предыдущий хэш не менялся. Если между двумя проверками пройдут описанные вами манипуляции и блоки в журнал будут дописаны правильно, то проверяющий не увидит ничего необычного. Да, для него все будет правильно. Вы это хотели услышать?
(60)
Так он сам не знает чего хочет получить.
Хочет чтоб за 5 шейкелей ему написали гениальную идею, а потом он мечтает разбогатm и рассказывать всем недалеким - какой он крутой блокчейн программист
Михаил, неужели так трудно с первого раза чётко и недвусмысленно сформулировать условия, чтобы их не приходилось нудно и мучительно уточнять?
Так он сам не знает чего хочет получить.
Хочет чтоб за 5 шейкелей ему написали гениальную идею, а потом он мечтает разбогатm и рассказывать всем недалеким - какой он крутой блокчейн программист
(59)
Когда новый реквизит в документ добавите? удалите? измените? Реквизиты клиента поменяются? Или замените любую структуру метаданных ваша цепочка так же пойдет в мусорный ящик так как конрольный хеш поменяется. Про обновления молчу вообще
Так это надо тысячи попиков прочитать на биткоинталке и тогда возможно начнете понимать. Хотя сомневаюсь.
Любые изменения оформляются новым документом.
Когда новый реквизит в документ добавите? удалите? измените? Реквизиты клиента поменяются? Или замените любую структуру метаданных ваша цепочка так же пойдет в мусорный ящик так как конрольный хеш поменяется. Про обновления молчу вообще
Если вы видите такие, то опишите. Пока вы говорите не понятно.
Так это надо тысячи попиков прочитать на биткоинталке и тогда возможно начнете понимать. Хотя сомневаюсь.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот