Пропуск предыдущей выплаты был из-за совсем мелких сумм и ожидании решения по продаже KnC Saturn (потеряли время на решении орг. вопросах).
Дивиденды: meta1th, knc250gh не выплачивались (там всего в буфере 0.06355btc нет никакого смысла пыль слать, подождите окончания доставки покупателю и будет сразу много), bfl60gh, meta155ghp.s. один вкладчик запросил смену адреса, сменил пока на свой, жду подписи-подтверждения (как получу тут же вышлю). С электричеством разберусь в следующий раз |
|
|
|
|
@alpet
я бы настоятельно не рекомендовал путать и смешивать такие разные (хоть и взаимозависимые) задачи как ликвидность и высокоскоростной трейдинг, на что кстати у меня тоже есть планы, 'под пунктом 4', на текущий момент об этом даже говорить странно, потому как у слушателей нет понимания 'первых трех', в двух словах - нужен кусочек рипла, который отвечает за 'бесплатный' мгновенный процессинг транзакций и шлюзы ввода вывода в фиат (реальные торгуемые товары), так же сюда подмешиваем сложные мультиклиентские транзакции (когда участника больше двух и у всех разные товары, и все желают их друг с другом обменять) и самое главное инструментарий, который бы позволил клиентам работать с огромным количеством технических пар (все комбинации всех валют, шлюзов, способов вывода - для каждого грубо говоря свой стакан).
По поводу спреда, в децентрализованной бирже списки заявок на покупку и продажу по ценам ПЕРЕСЕКАЮТСЯ, т.е. стакан имеет вид не V а X, основной спред будет определять себестоимость обслуживания собственно перевода торгуемых товаров, и если она высока, обязательно будет использоваться промежуточный шлюз, выбор которого за клиентом (или алгоритмом. который клиент будет настраивать при выставлении ордеров).
По поводу скорости исполнения транзакции
- главным моментом в децентрализованной бирже у меня является различие двух типов транзакций - классическая в понимании клиента 'хочу продать 10btc за 10000$' и техническая, когда происходит автоматическое заключение договора на 'обмен определенного количества товара на другой с заморозкой залога'. Техническая транзакция - практически мгновенна (точнее там есть несколько методов ее заключения, в т.ч. полностью автоматическое у залогового агента на определенных условиях, либо с запросом подтверждения у запущенного терминала клиента - тут время это пара пингов до него) и является фактически фьючерсом на бартерную сделку на короткий срок (достаточный чтобы совершить поставку). Классическая же транзакция состоит из нескольких технических, последовательно или одновременно создаваемых и заключаемых с разными шлюзами, залоговыми гарантами и даже с использованием не совсем нужных товаров для клиента.
Отличный пример - половина транзакции будет обслужена за okpay, вторая половина будет обработана заключением тройной сделки между клиентами, меняющими qiwi<->bitcoin и qiwi<->webmoney, при этом qiwi/okpay/webmoney обрабатываются не напрямую а через шлюзы, обеспечивающие транзакции без комиссий (комиссии на ввод/вывод), затем при наличии на шлюзах okpay usd и webmoney wmz у клиента создается технические ордера по обмену этих денег на средства шлюза, удобного для вывода на текущий момент. При этом все условия и предпочтения (выбор шлюзов, возможность ухода в другие валюты или использование сложных транзакций, лимиты по размазыванию вывода по шлюзам и т.п.) определяются самим клиентом на этапе создания заявки или даже в настройках его терминала и могут быть естественно изменены в процессе исполнения сделки (но нужно понимать что если сделка прервана то на руках может оказаться куча мусорных промежуточных товаров, которые самостоятельно уже менять).
Так вот на совершение полной торговой операции может потребоваться время, которое будет сложено из количества промежуточных технических и времени на их исполнение, если это к примеру метод уменьшения размера залога для уменьшения рисков его потери (вместо 1 транзакции на 10btc совершить 10 шт по 1btc)
p.s. и еще абер фича, можно объединить функцию залогового гаранта и процессинг транзакций шлюза, поддерживающих обеспечение выдаваемых/эмитируемых шлюзом виртуальных товаров, которое в случае различных проблем (резкое падение курса товара в монетах залога или проблемы у самого шлюза) автоматически выдаются клиентам а шлюз закрывается. Если залоговое обеспечение будет больше или равно эмтитированным товарам по стоимости это добавит еще один механизм повышения ликвидности, так как уже сами шлюзы будут добавлять залог (или выкупать свои виртуальные товары) чтобы их сервис не схлопнулся, а клиентам не будет требоваться доверие этим шлюзам (что очень немаловажно) что приведет к появлению огромного количества мелких шлюзов, обслуживающих разные методы ввода/вывода, в т.ч. территориально или по фичам (время, объемы, платежки - один в один на текущий момент это текущие менялы на форуме).
Самое главное, клиентам нужно будет только доверие залоговым сервисам, которые могут держать только криптовалюту - что исключает влияние финмониторинга и злонамеренных правительств стран (типа как это делает россия или украина или кипр - отличные примеры, да и сша во главе стоит), которых может быть много и размер залога у которых может быть сравним с объемом одной технической транзакции (точнее чуть больше чем два от максимального). Грубо говоря клиенты могут управлять своими рисками, регулируя размер залога и его распределение по залоговым гарантам.
При этом информация о сделках в стакане - децентрализована (это просто сумма всех стаканов у всех процессоров залоговых гарантов, они будут почти всегда совмещены), и менее подвержены манипуляциям (правда сравнение сложно, в стаканах - технические сделки а не классические).
|
|
|
|
На самом деле этот пост не к тому, что мы не будем поддерживать Zerocoin в будущем. А больше к тому, что Bitcoin вполне может реализовать децентрализованный миксинг без изменений протокола. То есть, протокол Zerocoin не является безальтернативным решением, как многие думают. Если речь лишь о миксинге, то в BTC и форках это возможно уже сейчас, но вручную. Вот это мне не понятно, как это можно сделать без потери совместимости с клиентами, не поддерживающими zerocoin? Или в данный момент основывается на том что майнер может запихнуть абсолютно любую транзакцию в блокчейн, правда я пока не понимаю, какими именно должны быть эти JOIN_TX транзакции, ведь их 'выходы' должны тогда быть понятны старым клиентам, а текущий bitcoin полностью основывается на существовании истории. Можно на примере псевдоязыка описать пример такой транзакции? Что же до обмена через общую платформу на базе Zerocoin, то это проблематично. Весь смвсл протокола в том, что он не сохраняет никаких связей. Юзер создает одну монету Zerocoin и потом её обналичивает, это атомарная операция. То есть, у монеты Zerocoin есть номинал в валюте сети, и он фиксирован. Пользователь не может указать свой номинал, потому что при обналичивании нельзя будет его проверить. Поэтому кросс-сетевое обналичивание монет серьезно ограничено... Возможен лишь обмен по курсу, равному соотношению номиналов.
Что? Я похоже этот момент упустил или просто информации о именно zerocoin на русском нет а на английском тяжела для восприятия. Почему это номинал в zerocoin фиксирован? Да, тратить пользователь может ровно столько, сколько монет послал в 'особой' транзакции, но он мог послать десять раз по 0.01 или сто раз по 0.03521, т.е. номинал определяется самим владельцем а не зашивается разработчиками в код. И единственная причина, почему пользователи будут пользоваться 'красивыми' числами (например степени 10) - это то что иначе количество монет (и время) является еще одним методом деанонимизации. Я не прав? Даешь обработку транзакций на базе гомоморфного шифрования
В блокчейне в принципе не должно быть ничего зашифрованного и закрытого, даже если проверку зашифрованных данных можно сделать без знания ключей. Это главное идеологическое требование к криптовалютам в целом. Оно даже важнее, чем открытость исходных текстов. Спорное утверждение. Я например считаю что это совершенно нормально, что то шифровать в публичной базе данных! p.s. 'Блокчейн' никому ничего не должен |
|
|
|
alpet, ты говоришь о краеугольных проблемах, которые стоят на пути полной децентрализации торговли (не только с криптовалютами) а вообще любыми товарами/инструментами и бартерными сделками. Наверное мне пора выходить из 'тени'  со своим проектом децентрализованной биржи, на который я потихоньку ищу ресурсы и программистов. Проблема в том что основные затраты - программирование opensource части, а методы монетизации практически полностью получаются завязаны на создание закрытой серверной части залогового/посреднического сервиса, наличие которого в в виде единого монопольного сервиса не гарантируется ничем. Т.е. классическая схема найти инвестора - сложна, может быть только пожертвования? Но в россии эта схема инвестирования в проекты - практически всегда провальна. Проблемы тут следующие: 1. разрозненность валют платежных инструментов. Рубль QIWI и рубль Yandex совсем разные вещи, кто то должен обеспечивать трансфер реальных капиталов между ними. Я предлагаю вместо абстрактной торговой биржи btc/rub создать много много торговых пар yandex rub/qiwi rub, yandex rub/btc-wallet, qiwi rub/btc-walle (кстати bitcoin тоже бывают разные.. например это redeem код на btc-e или перевод внутри cryptsy или blockchain.info или локальный кошелек) и создать инструмент, позволяющий при создании ордера (самому клиенту) определять что предпочтительнее. 2. проблемы доверия участникам сделок, на текущий момент это основная проблема, после отсутствия инструментария конечно же, отсутствия ликвидности у децентрализованных торгов (обмен на форуме или сервисы обменники и рекламные площадки типа localbitcoins). Я предлагаю решать эту проблему автоматизированными сервисами залогового гаранта, которые блокируют залоги на счетах участиков на время совершения сделки и возвращают залог только ппосле подтверждения всеми участниками, либо уничтожает (жертвует публично кому то независимому) - особенности криптовалют позволяют это делать как минимум публично. 3. отсутствие систем автоматизации переводов. Основная идея децентрализованной биржи - это локально установленное приложение, работающее на основе правил, определенных пользователем (для этого и нужно opensource) и управляющее локально деньгами. Это возможно к примеру в системе okpay (есьт доступное API) но не возможно для qiwi или webmoney, там автоматизация ущербна и работает только в пределах сервисов-магазинов. Но я планирую что эта проблема может быть решена уже позже самими клиентами самостоятельно и на их совести. Если кто то заинтересован, задавайте вопросы, возможно у вас найдутся идеи, как можно заинтересовать инвестора на такой проект, может быть сами таковым пожелаете стать. Понятно что остаются пожертвования, но я не уверен что в России найдется хоть один человек, готовый на это  даже при условии наличия у меня какой то минимальной репутации, что я не пропью эти деньги (я кстати не пью). Если будут заинтересованные, создам отдельную тему. p.s. на текущий момент я собрал 2.5btc на условиях 'как-нибудь сам решишь', и есть работающая часть сервиса залогового посредника, без модуля работы с кошельком обслуживания залоговыми счетами (не проблема, просто до него еще не скоро дойдет), обрабатывающая транзакции на скорости порядка 90запросов/сек (транзакция обычно дробится на несколько, т.е. это от трех до много запросов плюс время на реакцию клиента) Я думаю начинать нужно где то с 4-5k$, программист тут на старте очень важен |
|
|
|
|
Добавьте еще, что в случае, если обязать расплачиваться за нефть в тенге, дополнительный доход получат банки, за конвертацию usd->теньге и теньге->usd, а это порядка 2*(1%..3%) с оборота компании!
p.s. а так же повысит ликвиндость на рынке обмена тенге на usd.
|
|
|
|
Собственно, Zerocoin нам и не очень-то нужен для этого. Основной проблемой классических миксеров является то, что они могут сбежать с монетами, т.к. перемешиваемые монеты проходят через их кошелек и временно даются им в полное распоряжение. Однако, это не является единственно возможным вариантом. К примеру, возможен такой концепт:
...
но забыли еще одну проблему миксеров - миксер ЗНАЕТ историю перемешанных монет, так как он определяет чьи входы кому отправлять. Закапывайте! Даешь обработку транзакций на базе гомоморфного шифрования, вон и генетики задумались о сохранении приватности изучаемых ими генных карт. |
|
|
|
Вчера удалил кошелек и заново синхронизировал все транзакции . Не помогло что именно сделали? Много адресов на кошельке с монетами? Что пишет в консоли (помощь -> отладка -> консоль) команда listaddressgroupings (должно выдать список адресов и суммарные балансы на каждом)? Если адресов мало (или вы точно знаете на каких из них лежат монеты, помним что сдача при создании исходящих транзакций переводится на автоматически создаваемый адрес), то можно вручную сделать дамп их приватных ключей (для каждого команда dumpprivkey адрес, если кошелек запаролен, то разблокировать временно командой walletpassphrase количество_секунд) а затем создать новый пустой wallet.dat (отключить кошелек и удалить/переместить wallet.dat и заново запустить) и импортировать в него адреса (для каждой строки, выданной dumpprivkey сделать команду importprivkey строка), баланс будет пересчитан после перезапуска кошелька а несуществующие в блокчейне транзакции исчезнут. Альтернатива - запустить какую-либо утилиту редактирования или получения дампа wallet.dat, но боюсь вам проще вручную команды в консоли кошелька написать. |
|
|
|
Если же хотим строить социализм в отдельно взятом государстве предотвратить вредоносное поведение пользователя, владеющего 99+% из общего объема генерирующих ресурсов, то можно предусмотреть рамки и даже жесткие ограничения. К примеру, запретить указание в prevhash хэша блока, не имеющего "достаточное" количество подписей. И это сработает, но в качестве бонуса это создаст и проблему. А именно, если среди "выборщиков" не окажется никого в онлайне и не будет конкурирующих подписанных блоков, то вся цепь встанет. Посему, подобный вариант в чистом виде является злом.
Я о том и говорю, что необходимы правила, который позволят грамотно использовать эту информацию на узлах. Еще раз конечная цель то какая? - необходимо отфудболивать блоки, в которых 'злонамеренно' использовался в качестве потомка не тот блок что уже 'вся сеть' знает а более старый. Вот это понятие 'вся сеть' знает ты пытаешься определить через рассылку дополнительной информации от клиентов в сети (я бы ото всех слал, точнее тех кто майнит, но у нас PoS - так что ото всех), которые говорят типа 'мамой клянусь я получил такой то блок', и если получаешь кучу таких подтверждений от ограниченного списка узлов, которые на основании детерминированного правила от текущего блока выбираются из всего доступного списка. А дальше - тот блок, о которых говорит большинство текущих доверенных, должен быть прописан в следующем принимаемом блоке, иначе он не будет принят. Необходимо подобрать интервалы времени, в пределах которых будут выбираться эти метки от стейкхолдеров, чтобы не получилось лавинообразного затыка с принятием блоков, например в момент глобальных проблем с интернетом (проблемы на транснациональных интернет-каналах) когда одна половина земного шара думает одно, а другая - другое, ведь сейчас такие проблемы для сети пофиг - прав тот кто просто быстрее считает. |
|
|
|
Суть идеи проста и похожа на жеребьевку. По детерминированному алгоритму функция принятия блока выбирает N proof-of-stake блоков из прошлого. Это делается таким образом, чтобы выборка была всегда идентичной для конкретного блока, но нельзя или сложно было бы предсказать результат выборки для блока в будущем. Далее из этих блоков берутся публичные ключи vin[0] коинстейк-транзакции. Вот это и будут те самые холдеры, которым будет предложено подписать блок-кандидат.
Интересненько... интервал времени определен алгоритмом как константа (ну, например те кто создал PoS блоки месяц назад) или так же определяется детерменированным алгоритмом? Я так понимаю, если ни одного юзера онлайн вдруг не окажется, то как должны поступать те кто надеется на отклик от стейкхолдеров, по старинке - верить всему? и какой вообще алгоритм использования этих откликов? Какие то зашитые проценты наличия при принятии блока? и алгоритм этот всплывает в момент оторфанивания блоков/цепочек? |
|
|
|
|
Управление входами - возможность указать какие именно входящие транзакции 'тратить', в подавляющем большинстве случаев (не PoS майнерам в некоторых форках) от этого функционала достаточно просмотра сумм входов на каждом адресе и возможность выбрать, с какого совершать трату.
К сожалению, где бы я не пробовал это управление входами, везде оно не верно считает комиссию (считает одну а при отсылке подставляет другую)
|
|
|
|
это та самая попытка избавиться от централизованных девелоперских рассылок (а ранее в коде) отметок о гарантированно валидном блоке, который нельзя отменить, чтобы злоумышленник не смог заорфанить 100500блоков разом? кто такие stakeholders? я в том смысле, кто или что их определяет. |
|
|
|
А выводит Resource id #3 потому что ssh2_exec возвращает стрем Returns a stream on success or FALSE on failure. сделай к нему fread $connection=ssh2_connect('192.168.0.4', 22);
$h=ssh2_exec($connection, '/home/thepandacoin/bin/thepandacoind getdifficulty');
echo fread($h,1024); // правильно читать до тех пор пока данные есть, результатом вывода может быть не только число но и сообщение об ошибке
fclose($h);
p.s. правильно говорят тебе, перебрасывай порты и работай с rpc вызовами, это по феншую (да и проще, быстрее и надежнее в случае взлома не будет ssh доступа к серверу с кошельками). |
|
|
|
|
Это фича bitcoin-qt, чтобы не 'пугать пользователей', они почему то скрывают адреса, сгенерированные кошельком 'для сдачи'.
p.s. Не нравится мне отсутствие развития проекта официального кошелька bitcoin-qt
|
|
|
|
|
Самое простое решение, если у вас кошелек работает, есть транзакции но баланс не верный.
Запустить кошелек с -rescan
Если это не поможет, сделать дамп каждого адреса с монетами (listaddressgroupings покажет адреса, для каждого сделайте dumpprivkey <адрес>) создать новый кошелек и импортировать в него адреса (importprivkey <строка выданная dumpprivkey>), после перезапуска кошелек пересканирует новые адреса и будет реальное состояние дел по вашим монетам.
|
|
|
|
|
те. деньги отосланы на адрес в совсем другом форке и у них адреса имеют один формат?
в том кошельке где генерировал сделай в help->debug console
dumpprivkey адрес
полученную строку введи в другом кошельке там же
importprivkey строка
и перезапусти кошелек, деньги по уму должны появиться
|
|
|
|
|
С юридической точки зрения вы (ваш сервис?) никто, т.е. вы частное лицо, и процессить какие либо платежи по определению не имеете право. Любой, кто свяжется с вами получит юридическую тайм-бомбу и в лучшем случае штрафы и головняк на первой же налоговой проверке.
По крайней мере на сайте нет даже раздела 'Кто мы/about us'
|
|
|
|
|
The auction has ended.
Device is seding to the buyer Clayce with escrow broker Kluge
|
|
|
|
Demurrage Fee - Chain Security is supported primarily through a demurrage tax on sent inputs. This tax proportional to average input age as measured in coin-years. I suggest 5% per coin-year as a reasonable fee. Active keys can avoid demurrage fees simply by remaining active. Thus the actual fee generation will be much lower than 5% per year. Dead keys must pay demurrage. The opportunity to evade demurrage motivates activity.
Полагаю, что в NVC политика комиссий в будущем будет именно такой, но комиссия будет функцией, а не хардкодным значением. PPCoin тоже к этому однажды придет, несомненно... извиняюсь что оффтопик, но в этом случае если я верно понимаю, единственный способ избежать этого '5% налога на богатства' для PoS майнеров, тратить только те выходы, что сгенерированы ими же, т.е. молодые, а остальные будут лежать до посинения? смысл О_о? |
|
|
|
|
В данном случае анонимные - не идентифицированные для регулятора (а там по цепочке, налоговая, эмитиент, оператор, провайдер, магазин..)
|
|
|
|
|
Show Posts
