Ну, если верить поциенту.
поциенты в больницы, а у нас тут дискуссия и как мне кажется довольно интереснаяКогда
Topic: Проверка подписи, а не хешей блоков - page 3. (Read 414 times)
Когда
Я вам про другое говорю - есть транзакция, она одна, в ней подпись. ее выкачивает вся сеть. что отбрасывать? проверили подпись, значит она валидная. rollback не нужен.
Я не понимаю, как в вашей сети защищаться от двух таких валидных транзакций, тратящих один и тот же выход.
Ну, если верить поциенту.
поциенты в больницы, а у нас тут дискуссия и как мне кажется довольно интересная Консенсус в криптовалютах - это набор правил, на соответствие которым каждая нода проверяет блоки и отдельные транзакции. PoW в криптовалютах нужен для создания защищённого от перезаписи блокчейна. Защищённый от перезаписи блокчейн нужен для защиты от двойной траты.
POW это алгоритм консенсуса, нужен он для того, чтобы нода поняла, что именно этот блок подходит, а не какой-то другой, плюс дает возможность всем выкачать данные за те 10 минут, пока ищется нужный хеш. Да алгоритм защищает от подделки блока. А что мешает проверят не pow, а просто проверить подписи и принять блок? (другой вопрос, что блокчейн, пакует конкретные транзакции, но можно же выкачивать просто транзакции и проверять сколько влезет)
Зачем нужен PoW без блокчейна? Вы произнесли слово консенсус, но не объяснили, как он у вас реализован, что же всё-таки делать ноде С в описанной выше ситуации, чтобы не допустить двойную трату.
нода С ничего не может сделать, потому что в описанной ситуации нет алгоритма консенсуса. если вы намекаете на блокчейн, тогда его надо еще скачать ноде С с ноды А и с Ноды Б, а это уже консенсус, так можно тогда выкачивать не блоки, а просто транзакции и проверять подписи.
хорошо, тогда просто будем каждый следующий блок транзакций называть i++, разница не поменялась и пока блокчейн не нужен.
Ага. Цепочку блоков вы уже придумали, правда, блоки у вас пока ещё не связаны друг с другом криптографически. В реальных криптовалютных сетях блоки распространяются не мгновенно. И может случиться так, что какое-то время в сети могут существовать две цепочки, одну из которых придётся впоследствии отбросить.
То есть, майнящая нода A создаёт свою цепочку блоков с номерами 100, 101, 102, и майнящая нода B создаёт свою цепочку 100, 101, 102. При этом блок 100 одинаковый для обеих цепочек, а блоки 101 и 102 - разные.
Нода C, принявшая блоки 101 и 102 из этих разных цепочек должна как-то понять, какие блоки к какой цепочке относятся, а номера-то у них одинаковые. Как же без криптографической связи блоков понять где какая цепочка?
Более подробно эта ситуация описана здесь в главе Форки блокчейна.
Да, вы описали ситуацию rollback в распределенной системе, в которой определенный алгоритм определят при каких условиях будет откат цепочки или записи в журнал.
Я вам про другое говорю - есть транзакция, она одна, в ней подпись. ее выкачивает вся сеть. что отбрасывать? проверили подпись, значит она валидная. rollback не нужен.
Очевидно, поциент сам не знает ответа на свой вопрос "ноде C нужно принять решение о том, какая из этих транзакций правильная. Спросить не у кого. 51% нод не в курсе по поводу этих транзакций." применительно к блохчейну, но продолжает упорно твердить: блохчейн, потому что блохчейн, блохченом, блохчейну!!11
Консенсус в криптовалютах - это набор правил, на соответствие которым каждая нода проверяет блоки и отдельные транзакции. PoW в криптовалютах нужен для создания защищённого от перезаписи блокчейна.
Зачем нужна ещё какая-то защита от перезаписи, если и без того каждая нода проверяет блоки и отдельные транзакции ... на соответствие правилам? Делаем правило "нельзя перезаписывать транзакции". Ну, если верить поциенту.Quote
Защищённый от перезаписи блокчейн нужен для защиты от двойной траты.
И при этом - блоки постоянно перезаписываются (орфанятся), ага. Ты описал проблему двойной траты. А причем тут блокчейн? Эту проблему решает консенсус, например POW, а не блокчейн.
После того, как Вася отправил Пете, Васина нода должна достингуть консенсуса с остальными нодами. И тогда вася обломается с double spending
После того, как Вася отправил Пете, Васина нода должна достингуть консенсуса с остальными нодами. И тогда вася обломается с double spending
Консенсус в криптовалютах - это набор правил, на соответствие которым каждая нода проверяет блоки и отдельные транзакции. PoW в криптовалютах нужен для создания защищённого от перезаписи блокчейна. Защищённый от перезаписи блокчейн нужен для защиты от двойной траты.
Зачем нужен PoW без блокчейна? Вы произнесли слово консенсус, но не объяснили, как он у вас реализован, что же всё-таки делать ноде С в описанной выше ситуации, чтобы не допустить двойную трату.
хорошо, тогда просто будем каждый следующий блок транзакций называть i++, разница не поменялась и пока блокчейн не нужен.
Ага. Цепочку блоков вы уже придумали, правда, блоки у вас пока ещё не связаны друг с другом криптографически. В реальных криптовалютных сетях блоки распространяются не мгновенно. И может случиться так, что какое-то время в сети могут существовать две цепочки, одну из которых придётся впоследствии отбросить.
То есть, майнящая нода A создаёт свою цепочку блоков с номерами 100, 101, 102, и майнящая нода B создаёт свою цепочку 100, 101, 102. При этом блок 100 одинаковый для обеих цепочек, а блоки 101 и 102 - разные.
Нода C, принявшая блоки 101 и 102 из этих разных цепочек должна как-то понять, какие блоки к какой цепочке относятся, а номера-то у них одинаковые. Как же без криптографической связи блоков понять где какая цепочка?
Более подробно эта ситуация описана здесь в главе Форки блокчейна.
пока 51% нод хранит правильные данные (проверенные), это не проблема.
Вася создал транзакцию 1, в которой 10 монет отправляются Пете, Васина нода отправила эту транзакцию на ноду A.
Вася создал транзакцию 2, в которой эти же 10 монет отправляются Толику, Васина нода отправила эту транзакцию на ноду B.
Обе транзакции валидны, так как подписаны приватным ключом Васи, но тратят одни и те же 10 монет, что недопустимо.
Нода A пока ещё не знает о существовании транзакции на ноде B и наоборот. Остальные ноды пока вообще не знают о существовании этих двух транзакций.
Нода C получает обе этих транзакции: одну от ноды A, другую от ноды B. И теперь ноде C нужно принять решение о том, какая из этих транзакций правильная. Спросить не у кого. 51% нод не в курсе по поводу этих транзакций. Что делать ноде C?
После того, как Вася отправил Пете, Васина нода должна достингуть консенсуса с остальными нодами. И тогда вася обломается с double spending
нет, поскольку таймстамп может быть только временем для статистики, а не способом сортировки транзакций.
Это было место с ошибкой в рассуждении. Сейчас ты правильно написал в чем именно была эта ошибка...
хорошо, тогда просто будем каждый следующий блок транзакций называть i++, разница не поменялась и пока блокчейн не нужен.
пока 51% нод хранит правильные данные (проверенные), это не проблема.
Вася создал транзакцию 1, в которой 10 монет отправляются Пете, Васина нода отправила эту транзакцию на ноду A.
Вася создал транзакцию 2, в которой эти же 10 монет отправляются Толику, Васина нода отправила эту транзакцию на ноду B.
Обе транзакции валидны, так как подписаны приватным ключом Васи, но тратят одни и те же 10 монет, что недопустимо.
Нода A пока ещё не знает о существовании транзакции на ноде B и наоборот. Остальные ноды пока вообще не знают о существовании этих двух транзакций.
Нода C получает обе этих транзакции: одну от ноды A, другую от ноды B. И теперь ноде C нужно принять решение о том, какая из этих транзакций правильная. Спросить не у кого. 51% нод не в курсе по поводу этих транзакций. Что делать ноде C?
И что же делает биткойновая нода в подобном случае?
пока 51% нод хранит правильные данные (проверенные), это не проблема.
Вася создал транзакцию 1, в которой 10 монет отправляются Пете, Васина нода отправила эту транзакцию на ноду A.
Вася создал транзакцию 2, в которой эти же 10 монет отправляются Толику, Васина нода отправила эту транзакцию на ноду B.
Обе транзакции валидны, так как подписаны приватным ключом Васи, но тратят одни и те же 10 монет, что недопустимо.
Нода A пока ещё не знает о существовании транзакции на ноде B и наоборот. Остальные ноды пока вообще не знают о существовании этих двух транзакций.
Нода C получает обе этих транзакции: одну от ноды A, другую от ноды B. И теперь ноде C нужно принять решение о том, какая из этих транзакций правильная. Спросить не у кого. 51% нод не в курсе по поводу этих транзакций. Что делать ноде C?
Всем привет!
Какой смысл соединять блоки предыдущим хешом, когда у нас в каждой траназкции есть подпись подтверждающая эту транзакцию?
Можно же отдельно записывать транзакции с timestamp и потом проверять все транзакции на валидность просто проверкой подписи каждого сообщения. Где здесь я ошибаюсь?
Какой смысл соединять блоки предыдущим хешом, когда у нас в каждой траназкции есть подпись подтверждающая эту транзакцию?
Можно же отдельно записывать транзакции с timestamp и потом проверять все транзакции на валидность просто проверкой подписи каждого сообщения. Где здесь я ошибаюсь?
timestamp
нет, поскольку таймстамп может быть только временем для статистики, а не способом сортировки транзакций.
Это было место с ошибкой в рассуждении. Сейчас ты правильно написал в чем именно была эта ошибка...
Всем привет!
Какой смысл соединять блоки предыдущим хешом, когда у нас в каждой траназкции есть подпись подтверждающая эту транзакцию?
Можно же отдельно записывать транзакции с timestamp и потом проверять все транзакции на валидность просто проверкой подписи каждого сообщения. Где здесь я ошибаюсь?
Какой смысл соединять блоки предыдущим хешом, когда у нас в каждой траназкции есть подпись подтверждающая эту транзакцию?
Можно же отдельно записывать транзакции с timestamp и потом проверять все транзакции на валидность просто проверкой подписи каждого сообщения. Где здесь я ошибаюсь?
timestamp
нет, поскольку таймстамп может быть только временем для статистики, а не способом сортировки транзакций.
Подпись транзакции удостоверяет право владельца приватного ключа на трату средств в рамках этой транзакции.
Криптографическая связь блоков обеспечивает целостность базы данных транзакций, защиту от удаления/добавления транзакций задним числом.
Криптографическая связь блоков обеспечивает целостность базы данных транзакций, защиту от удаления/добавления транзакций задним числом.
пока 51% нод хранит правильные данные (проверенные), это не проблема.
Сколькими ключами можно пользоваться?
в каком смысле?
Подпись транзакции удостоверяет право владельца приватного ключа на трату средств в рамках этой транзакции.
Криптографическая связь блоков обеспечивает целостность базы данных транзакций, защиту от удаления/добавления транзакций задним числом.
Криптографическая связь блоков обеспечивает целостность базы данных транзакций, защиту от удаления/добавления транзакций задним числом.
Сколькими ключами можно пользоваться?
Всем привет!
Какой смысл соединять блоки предыдущим хешом, когда у нас в каждой траназкции есть подпись подтверждающая эту транзакцию?
Можно же отдельно записывать транзакции с timestamp и потом проверять все транзакции на валидность просто проверкой подписи каждого сообщения. Где здесь я ошибаюсь?
Какой смысл соединять блоки предыдущим хешом, когда у нас в каждой траназкции есть подпись подтверждающая эту транзакцию?
Можно же отдельно записывать транзакции с timestamp и потом проверять все транзакции на валидность просто проверкой подписи каждого сообщения. Где здесь я ошибаюсь?
timestamp
Таймспемп не всегда идёт
Подпись транзакции удостоверяет право владельца приватного ключа на трату средств в рамках этой транзакции.
Криптографическая связь блоков обеспечивает целостность базы данных транзакций, защиту от удаления/добавления транзакций задним числом.
Криптографическая связь блоков обеспечивает целостность базы данных транзакций, защиту от удаления/добавления транзакций задним числом.
Всем привет!
Какой смысл соединять блоки предыдущим хешом, когда у нас в каждой траназкции есть подпись подтверждающая эту транзакцию?
Можно же отдельно записывать транзакции с timestamp и потом проверять все транзакции на валидность просто проверкой подписи каждого сообщения. Где здесь я ошибаюсь?
Какой смысл соединять блоки предыдущим хешом, когда у нас в каждой траназкции есть подпись подтверждающая эту транзакцию?
Можно же отдельно записывать транзакции с timestamp и потом проверять все транзакции на валидность просто проверкой подписи каждого сообщения. Где здесь я ошибаюсь?
timestamp
Всем привет!
Какой смысл соединять блоки предыдущим хешом, когда у нас в каждой траназкции есть подпись подтверждающая эту транзакцию?
Можно же отдельно записывать транзакции с timestamp и потом проверять все транзакции на валидность просто проверкой подписи каждого сообщения. Где здесь я ошибаюсь?
Какой смысл соединять блоки предыдущим хешом, когда у нас в каждой траназкции есть подпись подтверждающая эту транзакцию?
Можно же отдельно записывать транзакции с timestamp и потом проверять все транзакции на валидность просто проверкой подписи каждого сообщения. Где здесь я ошибаюсь?
Jump to: