rPman
Legendary
Offline
Activity: 1120
Merit: 1069
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 01, 2014, 06:35:07 AM |
|
Какой тут жуткий оффтоп. В тему куби/буби/..-board, я облизываюсь на это - http://www.parallella.org/board/ ( shop), они пишут что 64-процессорный сопроцессор у них заработал (но кажется недостаточно средств чтобы платы на его основе клепать, а как хотелось бы). А наличие FPGA-модуля, зарождают надежду на нормальное развитие софта в этом направлении.
|
|
|
|
Balthazar (OP)
Legendary
Offline
Activity: 3108
Merit: 1359
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 01, 2014, 09:05:29 AM Last edit: August 01, 2014, 09:16:34 AM by Balthazar |
|
Для совместимости с BTC в репозиторий была добавлена реализация RPC функции createmultisig, по назначению она аналогична addmultisigaddress, но не добавляет созданный адрес в кошелек. Мова, как опциональный , вполне годно. А работы о внедрению механизма какого-нибудь по анонимизации платежей больше не ведутся?
В процессе: https://bitcointalk.org/index.php?topic=114712.msg7758020#msg7758020Код черновой реализации алгоритма генерации ключей можно посмотреть здесь: https://github.com/CryptoManiac/novacoin/commit/952b469fe40e71ed14752b28641aa0cb62c8d741Однако, для полноценного его использования потребуется добавление поддержки нового опкода в скриптовую машину. Это необходимо из-за того, что отправителю известно созданное им секретное значение r, что делает возможную реализацию на базе текущего набора доступных операций уязвимой к отмене такого перевода отправителем, если он не потрачен, а это не есть хорошо. Нужна инструкция, которая не будет принимать сгенерированные с использованием r подписи в качестве корректных, тогда эксплуатация данной технологии будет безопасной. Оптимальная реализация опкода в данный момент в разработке. ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif) Похоже что найдено решение, не требующее добавления новых опкодов. Так что в грядущих апдейтах таки появится поддержка одноразовых ключей. ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif)
|
|
|
|
Dimanoid
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 01, 2014, 09:11:03 AM |
|
И всё же вернусь к теме комиссии за перевод. Хотелось бы понять, за что в этот раз сняли 0,003NVC, если блок меньше 2-х килобайт. Вот транзакция. P.S. Возможно, причина - что один из входов "молодой"? Но в этом случае вроде только совсем без комиссии нельзя отправить?
|
NVC: 5GRZSmMP6byiSsZXyJs9FomCo7cCF2ds7MSLFx15rnNygdKTdMCVms5d97ZFFc6PR7BfVqsXCTCSYtW HjHaHig6Q5RLbjv65q6d
|
|
|
Balthazar (OP)
Legendary
Offline
Activity: 3108
Merit: 1359
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 01, 2014, 09:35:10 AM |
|
Тут всё просто. Во-первых, при подсчете комиссии размер всегда округляется до килобайтов в большую сторону, то есть 1.001КБ, 1.3КБ или 2КБ это одно и то же для сети. Во-вторых, если приоритет транзакции ниже среднего, то добавляются дополнительные 0.001 nvc комиссии и соответствующая надпись в форме coincontrol подсвечивается красным. Возможно, в этом дело, можно посчитать.
|
|
|
|
Dimanoid
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 01, 2014, 09:43:20 AM Last edit: August 01, 2014, 10:00:06 AM by Dimanoid |
|
Тут даже не в размере комиссии дело (она в любом случае теперь меньше!) Просто не так удобно стало управлять входами. Клиент рассчитывает комиссию 0,002 - я её выставляю. Пытаюсь отправить - не уходит, всплывает окно о нехватке средств. А когда 0,003 выставляю - в клиенте пишет, что будет 0,001NVС сдача. В общем, сбивает с толку, сколько нужно выставить.
P.S. А как узнать о низком приоритете транзакции? В управлении входами красных надписей не было! (есть скриншот).
|
NVC: 5GRZSmMP6byiSsZXyJs9FomCo7cCF2ds7MSLFx15rnNygdKTdMCVms5d97ZFFc6PR7BfVqsXCTCSYtW HjHaHig6Q5RLbjv65q6d
|
|
|
aclon
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 01, 2014, 11:56:15 AM |
|
значит нужна фича автоматического расчёта суммы транзакции, чтобы сдача была определённой величины (например нулевая) т.е. вводить значение сдачи
|
|
|
|
icreator
Legendary
Offline
Activity: 1554
Merit: 1008
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 01, 2014, 11:56:39 AM |
|
может в АПИ сразу сделать расчет величины комиссии по данной рав-транзакции?
get_tax_raw(rawtx)
|
Erachain Blockchain is fully ready for use Digital Ecosystem based on blockchain technology for business and government with low transaction costs, identification and built-in functions. +Decentralized exchange of tokens in Erachain
|
|
|
Balthazar (OP)
Legendary
Offline
Activity: 3108
Merit: 1359
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 01, 2014, 12:14:22 PM |
|
значит нужна фича автоматического расчёта суммы транзакции, чтобы сдача была определённой величины (например нулевая) т.е. вводить значение сдачи
Можно проще, сдачу ниже порога просто добавлять к комиссии и всё. Расчет же суммы представляет собой проблему, потому что у транзакции может быть более одного получателя. может в АПИ сразу сделать расчет величины комиссии по данной рав-транзакции?
get_tax_raw(rawtx)
В случае RAW транзакций никаких комиссий нигде не считается. На то ведь они и RAW, чтобы всё делалось вручную.
|
|
|
|
Dimanoid
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 01, 2014, 01:38:18 PM |
|
Расчет же суммы представляет собой проблему, потому что у транзакции может быть более одного получателя.
Ну откуда-то сумма комиссии всё же берётся!? Вот в тестовой сети попробовал - тоже не хватило 0,002NVC: ![](https://ip.bitcointalk.org/?u=http%3A%2F%2Fstorage6.static.itmages.com%2Fi%2F14%2F0801%2Fs_1406899928_6793703_bc7e5bb7bb.jpg&t=665&c=n7fwzUPnETR0RQ) То есть точно рассчитать комиссию никак нельзя? Можно считать, что это "фича" и пользоваться как есть (добавить 0,001 и отправить снова)?
|
NVC: 5GRZSmMP6byiSsZXyJs9FomCo7cCF2ds7MSLFx15rnNygdKTdMCVms5d97ZFFc6PR7BfVqsXCTCSYtW HjHaHig6Q5RLbjv65q6d
|
|
|
Kepasa
Legendary
Offline
Activity: 1848
Merit: 1014
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 01, 2014, 02:02:32 PM |
|
Тому кто найдет следующий блок на пуле nvc.coinpool.ru в течении следующих 3 часов- 1 NVC от меня в качестве бонуса. Адрес в личку на пуле.
|
|
|
|
Balthazar (OP)
Legendary
Offline
Activity: 3108
Merit: 1359
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 01, 2014, 02:45:30 PM |
|
Ну откуда-то сумма комиссии всё же берётся!? Вот в тестовой сети попробовал - тоже не хватило 0,002NVC: ![](https://ip.bitcointalk.org/?u=http%3A%2F%2Fstorage6.static.itmages.com%2Fi%2F14%2F0801%2Fs_1406899928_6793703_bc7e5bb7bb.jpg&t=665&c=n7fwzUPnETR0RQ) ... Можно считать, что это "фича" и пользоваться как есть (добавить 0,001 и отправить снова)? "Комиссии" нет, как таковой, комиссия - это просто разница между суммой входов и суммой выходов. При автоматическом выборе входов и нехватке средств на комиссию добавляется ещё один вход, а остаток от него становится сдачей. Понятное дело, что в случае ручного выбора инпутов этого не произойдет и будет выдана ошибка. То есть точно рассчитать комиссию никак нельзя?
Нельзя, потому что не известен достоверно конечный размер подписей. Нельзя гарантированно определить, каким он будет точно, потому что при создании подписей используются операции над случайными числами. Конкретный клиент может использовать ограниченный диапазон для генератора случайных чисел, но другой (например, Electrum) может не иметь таких ограничений. Кроме того, форма на данный момент не знает реальный размер входов и использует заранее прописанные значения для разных типов, эти значения могут и не соответствовать действительности в конкретном случае. Отображаемые значения следует рассматривать как оценки и не более того. Для этого там и отображается тильда в поле размера.
|
|
|
|
icreator
Legendary
Offline
Activity: 1554
Merit: 1008
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 01, 2014, 05:33:05 PM |
|
Если сделать свою локальную сеть нод - скажем 2-3 компа то блоки в такой сети будут генерироваться с тойже скоростью что и в основной сети
значит можно создать такой же длинны цепочку блоков и как только она превысит (случайно) основную цепочку - синхронизироваться с основной сетью
и все - каюк биткоинам - переходим на новакоины ))
или там точно так же можно по сути - если отдельную сеть создать и внутри сети так же блоки гнать а 2 компа
|
Erachain Blockchain is fully ready for use Digital Ecosystem based on blockchain technology for business and government with low transaction costs, identification and built-in functions. +Decentralized exchange of tokens in Erachain
|
|
|
Ochert
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 01, 2014, 05:33:58 PM |
|
Походу кто-то потихоньку закупается?
|
|
|
|
Balthazar (OP)
Legendary
Offline
Activity: 3108
Merit: 1359
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 01, 2014, 06:01:03 PM |
|
Если сделать свою локальную сеть нод - скажем 2-3 компа то блоки в такой сети будут генерироваться с тойже скоростью что и в основной сети
значит можно создать такой же длинны цепочку блоков и как только она превысит (случайно) основную цепочку - синхронизироваться с основной сетью
и все - каюк биткоинам - переходим на новакоины ))
или там точно так же можно по сути - если отдельную сеть создать и внутри сети так же блоки гнать а 2 компа
Уж сколько раз говорил авторам статей, чтобы не писали глупости про длину цепочки. Фиг там, ответ "это слишком сложно, сравнение по длине проще для читателей"... Результат - множество людей формирует абсолютно не соответствующие реальности представления из-за того, что прочитанную статью писали с мыслью "читатель идиот, надо бы ему что попроще изобразить".
|
|
|
|
|
Balthazar (OP)
Legendary
Offline
Activity: 3108
Merit: 1359
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 01, 2014, 06:52:10 PM Last edit: August 01, 2014, 07:14:51 PM by Balthazar |
|
Разработчик Electrum (ThomasV) изначально был вдохновлен данной темой, и использовал этот подход на базе древовидной структуры в своем проекте. Правда, им не используется блокчейн для "запечатывания" хэшей текущего состояния.
Со смерженным же блокчейном непонятно, потому как проверить подлинность гипотетического блокчейна снимков UTXO можно будет лишь обладая копией основной цепочки блоков, одних лишь заголовков недостаточно. Вследствие чего возникает вопрос, а что дадут снимки UTXO, если для их проверки нам все равно нужен блокчейн, или те у кого он есть?
Конечно, возможен вариант, в котором для создания снимков используются только PoW блоки и проверка их PoS предков не производится. Тогда можно будет обойтись заголовками, однако проверка таких снимков будет всецело полагаться на work составляющую. В принципе, это даже можно реализовать модификацией Electrum-server... Это не изменит его концепцию принципиально, но добавит надежности.
Кому суть идеи непонятна по тому посту в теме, то упрощенно это выглядит так:
1) Формируем список хэшей всех непотраченных транзакций (по аналогии со списком хэшей транзакций, включаемых в блок); 2) Считаем хэш всех элементов списка (по аналогии с merkle хэшем в блоке); 3) Создаем структуру вида:
Версия Хэш предыдущего экземпляра структуры Хэш всех элементов списка Время создания Номер блока
И добавляем её в coinbase-транзакцию генерируемого блока в основной цепи. В результате, хэш состояния оказыватся защищенным от изменений PoW сложностью, и снимки состояния можно хранить-передавать отдельно и дезависимо от основной цепи.
|
|
|
|
RoadTrain
Legendary
Offline
Activity: 1386
Merit: 1009
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 01, 2014, 07:09:09 PM Last edit: August 01, 2014, 07:20:36 PM by RoadTrain |
|
Разработчик Electrum (ThomasV) изначально был вдохновлен данной темой, и использовал этот подход на базе древовидной структуры в своем проекте. Правда, им не используется блокчейн для "запечатывания" хэшей текущего состояния.
Со смерженным же блокчейном пока непонятно, потому как проверить подлинность гипотетического блокчейна снимков UTXO можно будет лишь обладая копией основной цепочки блоков, одних лишь заголовков недостаточно. Вследствие чего возникает вопрос, а что дадут снимки UTXO, если для их проверки нам все равно нужен блокчейн, или те у кого он есть? Впрочем, возможен вариант, в котором для создания снимков используются только PoW блоки и проверка их предков не производится. Тогда можно будет обойтись заголовками.
Интересно, но Electrum слишком лёгкий клиент, в том плане, что слишком полагается на доверие серверам. Я не знаю в деталях его принципы работы, но полагаю, что несильно ошибаюсь. Тут идея состоит в том, чтобы сделать легковесный клиент, который, тем не менее, мог бы проверять цепочку без необходимости излишне кому-либо доверять. Чем-то напоминает развитие SPV-концепции, с добавленим загрузки и верификации UTXO set. Надо бы как-то сподобиться и накидать примерный вариант реализации, потом оценить, надо ли оно вообще... Со смерженным же блокчейном непонятно, потому как проверить подлинность гипотетического блокчейна снимков UTXO можно будет лишь обладая копией основной цепочки блоков, одних лишь заголовков недостаточно. Вследствие чего возникает вопрос, а что дадут снимки UTXO, если для их проверки нам все равно нужен блокчейн, или те у кого он есть?
Конечно, возможен вариант, в котором для создания снимков используются только PoW блоки и проверка их PoS предков не производится. Тогда можно будет обойтись заголовками, однако проверка таких снимков будет всецело полагаться на work составляющую. В принципе, это даже можно реализовать модификацией Electrum-server... Это не изменит его концепцию принципиально, но добавит надежности.
Думаю, в случае с гибридным дизайном придётся полагаться на pow составляющую. Хотя проверить pos блоки в принципе тоже возможно, если клиент уже обладает полноценной базой UTXO. В моём представлении, данный протокол в первую очередь облегчает первичную синхронизацию с сетью, что было бы особенно заметно в случае с биткойном. После получения всех заголовков и снимка UTXO, клиент может продолжить функционирование в "обычном" режиме - принимать блоки полностью, проверять их, проверять транзакции, коммитить изменения в локальную базу UTXO... Но это лишь один из вариантов, есть ещё всякие UTXO commitments и мета-цепочки, в которые я пока не углублялся.
|
|
|
|
Balthazar (OP)
Legendary
Offline
Activity: 3108
Merit: 1359
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 01, 2014, 07:20:25 PM |
|
Разработчик Electrum (ThomasV) изначально был вдохновлен данной темой, и использовал этот подход на базе древовидной структуры в своем проекте. Правда, им не используется блокчейн для "запечатывания" хэшей текущего состояния.
Со смерженным же блокчейном пока непонятно, потому как проверить подлинность гипотетического блокчейна снимков UTXO можно будет лишь обладая копией основной цепочки блоков, одних лишь заголовков недостаточно. Вследствие чего возникает вопрос, а что дадут снимки UTXO, если для их проверки нам все равно нужен блокчейн, или те у кого он есть? Впрочем, возможен вариант, в котором для создания снимков используются только PoW блоки и проверка их предков не производится. Тогда можно будет обойтись заголовками.
Интересно, но Electrum слишком лёгкий клиент, в том плане, что слишком полагается на доверие серверам. Я не знаю в деталях его принципы работы, но полагаю, что несильно ошибаюсь. Тут идея состоит в том, чтобы сделать легковесный клиент, который, тем не менее, мог бы проверять цепочку без необходимости излишне кому-либо доверять. Чем-то напоминает развитие SPV-концепции, с добавленим загрузки и верификации UTXO set. Надо бы как-то сподобиться и накидать примерный вариант реализации, потом оценить, надо ли оно вообще... Electrum проверяет заголовки блоков, а состояние UTXO запрашивает у серверов. Смысл же цепочки снимков в том, что теоретически с её помощью можно принудительно унифицировать поведение таких серверов... То есть, известно что в такое-то время хэш UTXO должен быть именно таким, и никак иначе, и все не соответствующие этому правилу сервера можно предать анафеме. Как-то так. ![Roll Eyes](https://bitcointalk.org/Smileys/default/rolleyes.gif)
|
|
|
|
RoadTrain
Legendary
Offline
Activity: 1386
Merit: 1009
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 01, 2014, 07:26:15 PM |
|
Разработчик Electrum (ThomasV) изначально был вдохновлен данной темой, и использовал этот подход на базе древовидной структуры в своем проекте. Правда, им не используется блокчейн для "запечатывания" хэшей текущего состояния.
Со смерженным же блокчейном пока непонятно, потому как проверить подлинность гипотетического блокчейна снимков UTXO можно будет лишь обладая копией основной цепочки блоков, одних лишь заголовков недостаточно. Вследствие чего возникает вопрос, а что дадут снимки UTXO, если для их проверки нам все равно нужен блокчейн, или те у кого он есть? Впрочем, возможен вариант, в котором для создания снимков используются только PoW блоки и проверка их предков не производится. Тогда можно будет обойтись заголовками.
Интересно, но Electrum слишком лёгкий клиент, в том плане, что слишком полагается на доверие серверам. Я не знаю в деталях его принципы работы, но полагаю, что несильно ошибаюсь. Тут идея состоит в том, чтобы сделать легковесный клиент, который, тем не менее, мог бы проверять цепочку без необходимости излишне кому-либо доверять. Чем-то напоминает развитие SPV-концепции, с добавленим загрузки и верификации UTXO set. Надо бы как-то сподобиться и накидать примерный вариант реализации, потом оценить, надо ли оно вообще... Electrum проверяет заголовки блоков, а состояние UTXO запрашивает у серверов. Смысл же цепочки снимков в том, что теоретически с её помощью можно принудительно унифицировать поведение таких серверов... То есть, известно что в такое-то время хэш UTXO должен быть именно таким, и никак иначе, и все не соответствующие этому правилу сервера можно предать анафеме. Как-то так. ![Roll Eyes](https://bitcointalk.org/Smileys/default/rolleyes.gif) Вот это интересно, но выживет ли сеть, если подавляющее большинство клиентов будут Electrum, даже если модифицированные? Децентрализация, отказоустойчивость и тому подобное сильно пострадают?
|
|
|
|
Balthazar (OP)
Legendary
Offline
Activity: 3108
Merit: 1359
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 01, 2014, 07:36:45 PM |
|
Сеть полных нод в любом случае не пострадает. Однако, подобные клиенты будут способны проверить лишь PoW составляющую, а потому будут менее безопасными. То есть, теоретическому злоумышленнику для обмана жертвы достаточно будет сгенерировать свою цепочку PoW блоков, привязав к ним фальшивые снимки состояния. Решить эту проблему можно, используя несколько параллельных подключений. К примеру, Electrum устанавливает 8 соединений с разными серверами. Вообще, использование множества серверов само по себе усложняет жизнь потенциальным любителям пошутить, даже без использования цепочки снимков . ![Roll Eyes](https://bitcointalk.org/Smileys/default/rolleyes.gif) P.S. Кстати, использование Electrum серьезно упрощает жизнь, перенес биткоиновый валлет на него на десктопе.
|
|
|
|
|