Код с многочисленными препроцессорными вставками читается абсолютно ужасно, это я по опыту реальных проектов говорю. Особенно когда в погоне за оптимизацией начинают вставлять что-нибудь громоздкое и совсем нечитабельное типа ассемблерных вставок с SSE-кодом.
Заметно лучше иметь просто две версии класса с одним интерфейсом — одну «оптимизированную», другую нет, причем разнесенные по разным файлам.
Такое согласие не требуется в случаях, когда:
1) использование изображения осуществляется в государственных, общественных или иных публичных интересах;
На общественные и публичные интересы подобные действия вполне тянут.
Полагаю что потому что было несколько метрик и ни одна из них не давала хорошей классификации сама по себе
Тут возникает проблема нахождения границ: необходимо знать, какие значения метрики могут получаться для каждой из фигур. Можно проложить эти границы вручную “на глазок”, но лучше поручить это дело математически обоснованному алгоритму.
В рамках протокола — только тот, кому повезло найти nonce к очередному блоку. Т.е. очень редко (за день в мире награду получат всего ~144 человек), но зато сразу помногу.
Однако в пулах майнеров добыча одного может делиться между всеми участниками пула чтобы снизить фактор случайности и достичь более равномерного дохода
Фальшивую историю могут подсунуть в любом случае, просто нагенерить и подсунуть очень большую историю куда сложнее чем пару блоков :)
Для проверки баланса кошелька достаточно заглянуть в историю на глубину, гарантирующую наличие в кошельке нужной суммы денег (как правило — до момента когда в кошелек эту сумму перевели).
В принципе если есть доверенный источник, то можно еще взять у него баланс по всем кошелькам на выбранный момент времени, но в этом случае куда проще просто доверить этому источнику выступать в роли посредника, но это нескольоко обесценивает идею криптовалюты как сервиса, где доверять никому не надо а любую операцию можно проверить самостоятельно.
Мало ли кто что считает? У Вас своя голова на плечах есть, или Вы исключительно чужим доверяете, сортируя их по степени авторитетности?
Автор там исходит из предпосылки «attacker stopped including all broadcast transactions in blocks» причем в сильном предположении (all — как «не включать broadcast transactions вообще», см. строчку «forced to either include other people's transactions»). Это довольно существенно, так как идея, по сути, состоит в том что атакующий будет генерить пустые блоки, тогда как остальные — блоки с нетривиальным содержанием. А поскольку «пустые» блоки можно разумно просто отделить от «содержательных», то Gavin и предлагает внести соответствующее изменение в сам протокол bitcoin. Но вот только атакующему и не требуется поступать именно таким образом, исключая все транзакции из своих блоков. Атакующий может исключать лишь часть транзакций по своему усмотрению, включая в свои блоки все остальные — и тогда отличить его цепочку будет куда более нетривиально. Заметьте, что подобная правка, вдобавок, будет изменением протокола, которое еще надо чтобы все поддержали — ибо если на новый вариант перейдет только Bitcoin-Qt и его доля будет невелика, то из системы выкинет именно этого клиента, а не атакующего.
Свидетельством какой работы? По зашифровке? Так она интереса не представляет и выполняется быстро.
Для биткоина нужно чтобы
1) работу требовалось долго вычислять
2) работу можно было быстро проверить (нельзя было подсунуть нагенерированную чушь)
3) объем работы можно было бы подстраивать
4) внесение изменений в подписываемый работой блок потребовало бы переделки всей работы
A timestamp is accepted as valid if it is greater than the median timestamp of previous 11 blocks, and less than the network-adjusted time + 2 hours. «Network-adjusted time» is the median of the timestamps returned by all nodes connected to you.
В будущее уйти не получится, не переведя часы на >50% нод сети
Само существование человека владеющего >50% мощности биткоин сети сводит её ценность практически к нулю, поскольку позволяет отменять в сети любые транзакции на свое усмотрение, в частности, «оплачивая» покупки а затем возвращая «потраченные» биткоины обратно.
Описанный там способ а) не реализован на практике в реальных клиентах и б) защищает лишь от части атак
51% в общем случае победить невозможно, в лучшем случае можно увеличить стоимость этой атаки
4) Так просто тратим монету одновременно в нескольких транзакциях. Деньги в кошельке есть, но мы их одновременно переводим на другой кошелек и проводим оплату покупки.
Насколько я понимаю, основная идея в том что в рамках одной цепочки такое невозможно, а две противоречивые цепочки не могут сколь-либо долго сосуществовать за счет высокой сложности их формирования. Но было бы интересно посмотреть на детали.
1-2. Там есть какая-то стандартная сеть где можно получить список нодов к которым обращаться за цепочкой и которым рассылать транзакции?
4. Это не ответ. Как конкретно?
4а. Так почему именно 6, исходя из чего взято это число? К тому же я читал что разные клиенты используют разные числа, так что не похоже на «протокол»
5. Т.е. берем цепочку от начала, делим на куски по 2016 блоков и считаем для каждого куска difficulty, правильно? Последний кусок однозначно задает difficulty для следующего, и блок подписанный ниже расчетной сложности считается невалидным, правильно я понял идею?
7. Это не ответ, но ниже уже уточнили :)
1) Т.е. какого-то стандарта нет, цепочка скачивается разными клиентами из разных мест?
3) И долго его парсить? Вплоть до основания, все 10+ гигабайтов?
4) Это не ответ. Ну сложность, ну и что дальше?
Есть термин «законное платежное средство» aka Legal Tender. Статус валюты как ЗПС влечет за собой определенные следствия, например
* необходимость указывать цену товара в ЗПС (можно не только в ЗПС, но в ЗПС должно быть обязательно)
* при предъявлении любого ЗПС соответствующего указанной цене обменять товар на эти ЗПС
* то же самое для долговых обязательств
* любые платежи государству (налоги например) могут быть проведены только в ЗПС
Иногда вводятся более жесткие ограничения, например
* запрет на продажу товаров кроме как за ЗПС
Государство обеспечивает карательные санкции за нарушение этих требований.
Эти гарантии и ограничения в отношении ЗПС обеспечивают ценность национальных валют в объеме заметно большем, нежели «просто бумажки».
Ну это все более-менее очевидные вещи. Цепочка, хэширование, майнинг.
Интересно было бы почитать про следующие моменты:
1. Кто хранит цепочки блоков? Откуда они скачиваются?
2. Как новые блоки расходятся от инициатора транзакции майнерам (и вообще, инициатор ли транзакции туда включает и другие транзакции?)
3. Как узнать сколько в кошельке N денег?
4. Чем гарантируется что одни и те же деньги не будут потрачены дважды?
4а. и соответсвенно откуда берется «6 блоков для подтверждения транзакции»
5. Кто указывает сложность? Как все соглашаются с новой сложностью?
6. Способы обеспечения анонимности
7. Реализация защиты от того что кто-то чужой может потратить деньги из твоего кошелька
8. «Бумажные» формы биткоина — что за данные там хранятся и почему?
Заметно лучше иметь просто две версии класса с одним интерфейсом — одну «оптимизированную», другую нет, причем разнесенные по разным файлам.
На общественные и публичные интересы подобные действия вполне тянут.
Там проблема не с тернарным оператором а с классом строки.
будет падать ничуть не хуже.
Однако в пулах майнеров добыча одного может делиться между всеми участниками пула чтобы снизить фактор случайности и достичь более равномерного дохода
Для проверки баланса кошелька достаточно заглянуть в историю на глубину, гарантирующую наличие в кошельке нужной суммы денег (как правило — до момента когда в кошелек эту сумму перевели).
В принципе если есть доверенный источник, то можно еще взять у него баланс по всем кошелькам на выбранный момент времени, но в этом случае куда проще просто доверить этому источнику выступать в роли посредника, но это нескольоко обесценивает идею криптовалюты как сервиса, где доверять никому не надо а любую операцию можно проверить самостоятельно.
Автор там исходит из предпосылки «attacker stopped including all broadcast transactions in blocks» причем в сильном предположении (all — как «не включать broadcast transactions вообще», см. строчку «forced to either include other people's transactions»). Это довольно существенно, так как идея, по сути, состоит в том что атакующий будет генерить пустые блоки, тогда как остальные — блоки с нетривиальным содержанием. А поскольку «пустые» блоки можно разумно просто отделить от «содержательных», то Gavin и предлагает внести соответствующее изменение в сам протокол bitcoin. Но вот только атакующему и не требуется поступать именно таким образом, исключая все транзакции из своих блоков. Атакующий может исключать лишь часть транзакций по своему усмотрению, включая в свои блоки все остальные — и тогда отличить его цепочку будет куда более нетривиально. Заметьте, что подобная правка, вдобавок, будет изменением протокола, которое еще надо чтобы все поддержали — ибо если на новый вариант перейдет только Bitcoin-Qt и его доля будет невелика, то из системы выкинет именно этого клиента, а не атакующего.
Для биткоина нужно чтобы
1) работу требовалось долго вычислять
2) работу можно было быстро проверить (нельзя было подсунуть нагенерированную чушь)
3) объем работы можно было бы подстраивать
4) внесение изменений в подписываемый работой блок потребовало бы переделки всей работы
В будущее уйти не получится, не переведя часы на >50% нод сети
51% в общем случае победить невозможно, в лучшем случае можно увеличить стоимость этой атаки
7 — спасибо. думаю в распечатке 8 просто записаны ключи
Насколько я понимаю, основная идея в том что в рамках одной цепочки такое невозможно, а две противоречивые цепочки не могут сколь-либо долго сосуществовать за счет высокой сложности их формирования. Но было бы интересно посмотреть на детали.
4. Это не ответ. Как конкретно?
4а. Так почему именно 6, исходя из чего взято это число? К тому же я читал что разные клиенты используют разные числа, так что не похоже на «протокол»
5. Т.е. берем цепочку от начала, делим на куски по 2016 блоков и считаем для каждого куска difficulty, правильно? Последний кусок однозначно задает difficulty для следующего, и блок подписанный ниже расчетной сложности считается невалидным, правильно я понял идею?
7. Это не ответ, но ниже уже уточнили :)
Спасибо за информацию
3) И долго его парсить? Вплоть до основания, все 10+ гигабайтов?
4) Это не ответ. Ну сложность, ну и что дальше?
* необходимость указывать цену товара в ЗПС (можно не только в ЗПС, но в ЗПС должно быть обязательно)
* при предъявлении любого ЗПС соответствующего указанной цене обменять товар на эти ЗПС
* то же самое для долговых обязательств
* любые платежи государству (налоги например) могут быть проведены только в ЗПС
Иногда вводятся более жесткие ограничения, например
* запрет на продажу товаров кроме как за ЗПС
Государство обеспечивает карательные санкции за нарушение этих требований.
Эти гарантии и ограничения в отношении ЗПС обеспечивают ценность национальных валют в объеме заметно большем, нежели «просто бумажки».
Интересно было бы почитать про следующие моменты:
1. Кто хранит цепочки блоков? Откуда они скачиваются?
2. Как новые блоки расходятся от инициатора транзакции майнерам (и вообще, инициатор ли транзакции туда включает и другие транзакции?)
3. Как узнать сколько в кошельке N денег?
4. Чем гарантируется что одни и те же деньги не будут потрачены дважды?
4а. и соответсвенно откуда берется «6 блоков для подтверждения транзакции»
5. Кто указывает сложность? Как все соглашаются с новой сложностью?
6. Способы обеспечения анонимности
7. Реализация защиты от того что кто-то чужой может потратить деньги из твоего кошелька
8. «Бумажные» формы биткоина — что за данные там хранятся и почему?