|
Вчера поставил на вывод с bitlish все что начислили 21.666btc, а так же там висит на аккаунте 460GH/s (их я выводить пока не буду).
По поводу новых асиков, я пока подумываю сворачивать деятельность по хостингу железа. Дома большие объемы не поставишь, а малые объемы - пользы мало, да и с таможней бодаться нет желания. Тем более у меня летом может не быть времени лично этим заниматься (хотя я рассматривал варианты облачного майнинга, например от того же KnC, но шведы пока тормозят с запуском).
p.s. С заказанными Нептунами решается вопрос о рефанде, точнее один заказ рефанд уже сделан, сейчас решается вопрос о рефанде второго (если есть желающие приобрести его по себестоимости в $ пишите мне в приват, решение нужно принять уже на этой неделе или ближайшие сутки).
|
|
|
|
|
Огромное спасибо ребятам от Метабанк за предоставленную компенсацию.
Надеюсь что в будущем вы будете лучше работать с общественностью.
p.s. bitlish, желаю вам развития, жду API а так же возможностей по выводу физического оборудования (по ситуации)
|
|
|
|
Вчера ночью одно из строенных устройств метабанка самостоятельно включилось, отказал блокпитания Chiftec 750w [ctg-750c] Купил на замену Chieftec 750W [APS-750CB] (он даже чуть чуть получше) за 3690р.
Электроэнергия за февраль: Февраль 2297 4180 <-- 3046р.
Январь 2879 5239
Декабрь 1955 3558
Ноябрь 1761 3205
Октябрь 1245 2265 Самое странное что в этом месяце мое потребление энергии было точно ниже (не майнил scrypt на видеокартах), понятно что разница в считанных 500р, это больше вопрос принципа, почему так происходит и почему потребление по счетчику стабильно растет. По всей логике за март потребление должно быть в пределах 1900-2000квтч. Обидно, что любые попытки добраться до истины обойдутся дороже или сравнимо с этой разницей.
Дивиденды: meta1th (за электроэнергию и блок питания -0.26976160btc), bfl60gh (за электроэнергию -0.00610399btc), meta155gh (за электроэнергию -0.01700397btc) Последняя выплата ~5btc по KnC saturn, который наконец то успешно продан, сюда же в буфер попали 2.5btc с продажи и 2.09 отложенные 45т.р. средства на растаможку и доставку. p.s. майнер от KnC был самым неприхотливым (правда без фаервола я бы не рекомендовал его использовать) но с ним было больше всего возни организационной деятельностью. |
|
|
|
Вообще считаю что более правильно было бы выбрать лицо не связанное с предзаказом и лицо незаинтересовнное, т.е. prman
хотя как раз может надо таки и наоборот? тогда уже fsb4000;)
действительно, по уму доверенное лицо не должно иметь никаких дел с метабанком, но тогда моя кандидатура не подходила бы, так как у меня хостится железа (гроупбай) от метабанка на 1.1TH/s. |
|
|
|
кто поставщик данных? меня больше интересует откуда информация о возрасте и поле посетителей? Это обсуждалось на нескольких предыдущих страницах. В принципе, никаких препятствий нет, и не требуется несовместимых изменений. Так что, вероятно, такой механизм будет реализован.
мы не закончили  по крайней мере у меня остались вопросы и недоумение о гарантиях. |
|
|
|
Странные вы люди. Сексом люди 'не интересуются' в интернете, если в реале с этим все в порядке. p.s. какой же я нетипичный биткоинерец  |
|
|
|
'Без меня, меня женили' Если я верно понимаю, ребята из Метабанка для аудита предоставят какую то информацию о количестве своих клиентов/проданного оборудования и грубо говоря список транзакций выплат? Почему нет, я могу этим заняться за простое 'спасибо'. p.s. Только информации для принятия решения маловато, к примеру у меня не будет возможности проверить, не пропустили ли к выплатам кого-либо, ведь публичной информации о предзаказах и их рефандах не было (кроме только что этой таблички, скопировал на всякий случай). |
|
|
|
|
Хватит уже про интернет... для бизнеса есть 100500 решений, для которых достаточно считанных килобайт на операцию.
Нет интернета? Сотовый есть, этого более чем достаточно... тонкие кошельки уже на чем только не написаны. При должном старании можно сворганить сервис рассылки sms об изменениях на балансе (указанном списке адресов) и принятии в sms готовой подписанной транзакции перевода (т.е. сервис не имеет доступа к монетам и максимум может нагадить - либо обмануть об информации по балансам... один раз, либо придержать исходящую транзакцию... тоже один раз и закрыться).
Разработать java приложение (а точнее надергать кода из готовых opensource реализаций) с соответствующим функционалом сможет чуть ли не любой недофрилансер (сложнее это сделать и протестировать для огромного количества моделей и платформ, но само собой реально).
p.s. про интернет, достаточно проекту Outernet ('wifi' на базе дешевых спутников) транслировать bitcoin блокчейн на весь мир, и бизнесу тем более будет достаточно простого sms для отправки транзакций, а балансы с неба будут падать.
|
|
|
|
Не взломали. Еще раз спрошу, уже хрен знает какой раз, что гарантирует, что транзакции в миксер не будут использованы дважды? т.е. клиент потратит ровно столько сколько внес? Вопрос по существу, что является в этом случае транзакцией 'послать в p2p миксер'? - просто публикация своего выхода, доступного для того чтобы их могли использовать другие и просили владельца 'подпиши транзакцию с использованием твоего выхода'? Вот пример атаки 'сделай гадость, на душе радость':
1. публикуем свою транзакцию (выход) как доступную 'для p2p миксера'
2. создаем свою транзакцию 'вывод денег из миксера' с чужими выходами
3. ждем когда эта транзакция подтвердится и тратим деньги куда хотим (т.е. у нас никаких затрат)
4. никогда не подписываем чужие транзакции траты этой первой транзакции
как результат - клиенты в конце концов просто не смогут вывести деньги с миксера
p.s. непонимание у меня больше от того, что если это ТАК просто почему этого нет ни в одном форке и тем более мейнстриме bitcoin? |
|
|
|
|
multisig.
Участники - только те чьи входы кто то решил использовать? И решение принимает тот кто создает исходящую транзакцию?
Т.е. для работы децентрализованного миксера получается требуется чтобы все те, чьи переводы мы решим использовать в своей транзакции были онлайн (имеется в виду в пределах срока, за который мы хотим получить монеты)? Чтобы мы попросили их... а подпишите ка мою транзакцию? Та еще задачка.
Так же, какое тут получается условие проверки, что проситель ранее положил в миксер входящую транзакцию на сумму меньше или равную?
|
|
|
|
Что значит отсылают друг другу? Все отсылают всем? scriptPubKey каждой транзакции в миксер достаточно для того чтобы воспользоваться ей как входом своей? а что мешает кому-то взять все собранные scriptPubKey и вывести монеты себе?
scriptPubKey - это правила траты выхода. Обычно там указывается хэш публичного ключа (адрес), соответственно, чтобы потратить монеты, нужно знать приватный ключ этого адреса. Вот по ссылке в моем посте выше хорошо описан протокол, там используются сортированные списки входов-выходов, причем деанонимизатор не сможет поставить соответствие вход-выход для участников. Способов сделать такой миксинг несколько, может быть значительная разница в деталях. Да елки палки, знание приватного ключа - это только для СВОИХ монет, а в децентрализованном миксере мы не можем раздавать эту информацию никому. Я кажется сформулировал вопрос верно. Неужели ответ на него - целая статья? Я его уже столько раз задавал, как именно формулируется условие в транзакции перевода и постоянно получаю тупо отписку общими словами, описывающими обычную транзакцию. Вот реально, последнее меня бы интересовал алгоритм выбора, какие из входов тратить! Сортировка, перемешивание или гадание на кофейной гуще... это конечно тоже важно, но мне не понятно то что происходит чуть раньше. p.s. либо тут все прекрасно знают глубокотехнический английский и задорно смеются над моими вопросами либо что то другое может цитату из статьи нужную скопипастите? |
|
|
|
|
Что значит отсылают друг другу? Все отсылают всем? scriptPubKey каждой транзакции в миксер достаточно для того чтобы воспользоваться ей как входом своей? а что мешает кому-то взять все собранные scriptPubKey и вывести монеты себе?
|
|
|
|
Юзеры отправляют список своих входов и желаемых выходов миксеру, а миксер составляет транзакцию. кому и что отсылают юзеры? мы кажется говорим не про классический централизованный миксер... |
|
|
|
|
i2p bote
Полностью децентрализованное хранение сообщений в сети dht внутри сети i2p, анонимно, децентрализованно, защищенно от прослушивания... недостаток - медленно (т.е. это почта а не чат)
|
|
|
|
Я так понимаю ты меня тролишь? Зачем мне описывать создание обычной транзакции? Мы же говорим о coinjoin. Конечная цель которой - сокрытие реальной истории переводов. User A создает особую транзакцию и тратит 1btc User B создает особую транзакцию и тратит 1btc User C создает особую транзакцию и тратит 1btc -------------- User B создает транзакцию, использующую выход User A, не имея его приватного ключа, и не требуя от него никакой дополнительной информации (а то ведь он может передумать и не дать ее позже). Вопрос КАК? Чем должна быть подписана транзакция User A чтобы это стало возможно |
|
|
|
'Красивая картинка' про coinjoin показывает что транзакции вывода из миксера указывают какие то выходы с транзакций ввода.. и ? ? ? это обычный централизованный миксер.
Не понимаю, что в нем "обычно централизованного", если он децентрализованный?  Нет никакого центра, чистый P2P. Чтобы скомпрометировать децентрализованный миксинг на базе CoinJoin, необходимо чтобы большая часть транзакций в сети создавалась ЦРУ. Нет иного способа, кроме как понадеяться на то, что клиент пользователя несколько раз подряд включит ЦРУшные монеты во входы для миксинга. Бесспорно, что ZeroCoin гораздо труднее скомпрометировать, потому что в таком случае нужна уже совсем другая стратегия, которая пока непонятна. Опять никакой конкретики в ответе  попробовать что ли в последний раз? Какое должно быть условие в транзакции передачи монет в 'p2p миксер' чтобы точно такое же количество (и не больше) из него мог бы забрать только ее создатель? Это не означает, что нет целевой аудитории, которой это нужно и может пригодиться. Просто она пока не очень велика, но это вопрос времени... Пройдет 10 лет и бумажные деньги будут восприниматься, как сейчас расписки древних китайских императоров, т.е. будут иметь чисто археологическую ценность. Современные централизованные системы ждет та же участь, уже позже но сам факт отсутствия тактильного фактора существенно облегчит понимание сути вещей. Хотя конечно, это не повод сидеть и ничего не делать, пока свернут выпуск наличных денег. как бы нам (миру) в ближайшие десятилетия (одно-два поколения) не скатиться к варварству и тотального отпуления... просто набрав критическую массу 'недалеких умом и знаниями' (ведь это выгодно здесь и сейчас тем кто это будет организовывать). p.s. классический обыватель в будущем (из не 'золотого миллиона') - http://www.retrohive.com/wp-content/uploads/2011/04/science_fiction_wallpaper_12.jpg |
|
|
|
|
doge форк от форка bitcoin, у демона есть удобные ключи (можно настроить в конфигурационном файле):
-blocknotify=<cmd> Execute command when the best block changes (%s in cmd is replaced by block hash)
-walletnotify=<cmd> Execute command when a wallet transaction changes (%s in cmd is replaced by TxID)
куда уж проще, повесить на эти колбаки свое приложение, анализирующее кошелек или сразу транзакцию.
|
|
|
|
...про coinjoin... скажите пожалуйста 'двумя русскими словами', каким именно образом создатель транзакции (тот кто выводит деньги из этого децентрализованного миксера) это делает, чтобы след его ввода в этот миксер потерялся? В Zerocoin это достигается тем что информация о входящем переводе зашифрована и только знающий грубо говоря пароль сможет потратить средства но только в таких же по объему (кстати я так понимаю можно и в любых, это просто сложнее и 'дороже по месту' в блокчейне), а проверка траты майнерами проводится на базе возможностей гомоморфного шифрования, им же не нужно знать кто куда и сколько пересылает, им главное чтобы дебит с кредитом сошелся. 'Красивая картинка' про coinjoin показывает что транзакции вывода из миксера указывают какие то выходы с транзакций ввода.. и ? ? ? это обычный централизованный миксер. |
|
|
|
rPman
Пока пытаюсь понять, какие элементы сети будут заниматься матчингом заявок
Вопрос на миллион. В моем варианте реализации понятие и процесс исполнения транзакции размазывается по нескольким узлам. Таковыми являются: * залоговый гарант * клиентские терминалы * процессоры шлюзов (в упрощенной реализации это будут делать залоговые гаранты, иначе нужно целый аналог ripple городить, точнее кусок, или хотя бы простой blockchain, но с двухранговой сетью, где блоки подтверждает центр - залоговый гарант, а не майнинг) Обычный процесс создания транзакции состоит в диалоге между всеми участниками, залоговым гарантом и шлюзами/процессорами переводов, причем к некоторым будет по 2-3 запроса. Заявки хранят залоговые гаранты и раздают клиентам, клиенты их все собирают и по своим соображениям выбирают какие исполнять (точнее для каких создавать встречный ордер и соотв. сами транзакции) и сами инициируют подтверждающий запрос к владельцам заявки (в т.ч. через залогового гаранта, как способ скрыть адрес), так же залоговые гаранты могут предоставить инструментарий по автоматическому выбору и подтверждению заявок (это уберет лишнюю задержку и уменьшит проблему манипуляций на базе этого временного интервала, когда злоумышленник будет ддосить заявки конкурентов, кратковремено блокируя их но не высылая подтверждение создания - тут так же есть свои методы решения и подводные камни, а в случае, когда залоговый гарант сам процессит транзакции платежного шлюза, сокращает время 'исполнения транзакции' до почти нуля, потому как в пределах одного сервиса все). |
|
|
|
О каком равенстве, балансе, не отрицательных счетах банков вы говорите? Разве у нас что то гарантирует (законодательство?) что банки не уходят в минус? Классическая ситуация (ради чего банки и создаются) собрать с народа вклады (пенсии с бабушек) и вложить все (доступное) в какие-нибудь ценные бумаги ('а давайте в грецию вложимся' ) с целью поиграть на курсе... |
|
|
|
|
Show Posts
