способ достижения мгновенных платежей

[mak]

 Большим недостатком биткойна является низкая скорость платежей.
Моментальные платежи понадобится для релизации многих платных серверов,
таких как: torrent, облачные вычисления, базы данных.
Идея в том, чтобы записывать долг базу данных. Когда задолженность
превысит порога доверия, возникает требование погасить долг,
тогда произойдет перевод биткойнов  путем  транзакции.
База данных задолженностей заводится  при каждом биткойн-клиенте
участвующего в быстрых платежах. Вне зависимости, предоставляет он услуги
или только пользуется.  Все партнеры прописаны в этой базе.Положительное
значение в поле баланса партнера означает то, что ты должен данному партнеру.
Отрицательное значение означает - партнер должен тебе.
Общение между партнерами производится по средствам forth-скриптов
(поток слов-команды разделенных пробелами). Для увеличения скорости, можно
запустить режим бинарных кодов-команд. Среди этих команд есть платные.
Изменение в локальной базе задолженностей соответствует изменению в базе партнера.
При посылки платной команды в локальной базе увеличивается  значение поля баланса данного партнера.
Исполняя полученную команду значение партнера уменьшается.
Послав  БТЦ  на адрес пополнения баланса - в локальной базе значение  уменьшится, а у партнера увеличится.
Между партнерами требуется взаимная регистрация. Поиск партнеров и регистрация производится автоматически.
Если партнер не отдает долг или его функции неправильно отрабатываются, производится соответствующая пометка
в базе и взаимодействие с ним прекращается. При этом могут, быть некоторые потери, но они не должны быть большими.

[1714774945]

1714774945

[1714774945]

1714774945

[1714774945]

1714774945

[rPman]

бред + бред + бред.

Биткоин-клиент уже хранит ВСЮ информацию обо всех пользователях (адресах), вся проблема, вокруг которой необходимо думать - это обеспечения гарантий, что записи в 'базе данных' верные и текущая реализация медленная только потому, что записи в базу добавляются только при нахождении нового блока ~ 6 раз в час.

При децентрализации, на данный момент, это лучшая технология, способная предоставлять гарантии корректности информации об анонимных пользователях - именно благодаря тормозам.

Для загрузки файлов нет никакой принципиальной разницы, как точно и скоро будет получена информация об балансе пользователей... задержка перебивается требованием гарантированного положительного баланса, потратить который можно не быстрее чем тормоза системы.

Если каждый факт загрузки кусков файлов будет отражаться в базе блоков (списания или пополнения средств) то размер базы будет расти просто неадекватными и кошмарными темпами, нужны кардинально другие методы хранения информации.

p.s. если будут нормальные, продуманные идеи, пиши, необходимость в децентрализованном торрент-трекере с рейтингами есть.

[joe82]

Согласен про скорость платежей, Солидкоин это исправил, и если создатели будут его развивать то будущее именно за ним на данный момент.

Большим недостатком биткойна является низкая скорость платежей.
Моментальные платежи понадобится для релизации многих платных серверов,
таких как: torrent, облачные вычисления, базы данных.
Идея в том, чтобы записывать долг базу данных. Когда задолженность
превысит порога доверия, возникает требование погасить долг,
тогда произойдет перевод биткойнов  путем  транзакции.

[rPman]

Надеюсь вы все понимаете, что надежность транзакций сети bitcoin определяется стоимостью атаки, в самом простом и реальном для реализации случае - это атака с целью создать фейковую транзакцию, которая отобразится у клиента с некоторым количеством подтверждений.

Так вот, чем дольше транзакция, тем дороже такая атака. Solidcoin, благодаря более частым блокам (30 блоков в час или 2 минуты на блок, но самое главное, 10% ограничением по росту сложности позволяет появиться скорости выше, например сейчас это 48 блоков в час) создает видимость скорости, но стоимость взлома все-равно от этого не зависит, а зависит от текущей мощности сети и количества подтверждений, которые готов ожидать пользователь.

В конечном счете стоимость атаки на данный момент сравнима со стоимостью профита, который можно получить обладая такими же мощностями, по крайней мере формула такая:
* требуемая мощность на 1 блок, 1 подтверждение = 50btc (32 для solidcoin, 48 - i0coin,..)
* сейчас, для получения доступа к данным нужно 6 подтверждений - это порядка 300btc
* плюс флюктуации, атакующему может повести (можно посмотреть на статистику пулов - очень часто блоки идут сериями кротких и редкими длинными блоками, примерно 3 к 1)

Получается доверять приему суммы в 50btc имеет смысл с тремя подтверждениями, меньше или равные 17btc - одно подтверждение..

p.s. Существует опасность одновременного существования нескольких bitcoin-сетей, так как мощности могут быть кратковременно перекинуты между block-chain, облегчая получение кратковременной мощной атаки.. например пулы средней мощности.

[LZ]

Согласен про скорость платежей, Солидкоин это исправил, и если создатели будут его развивать то будущее именно за ним на данный момент.

Он быстрее за счет меньшей надежности. Если выбирать между скоростью и криптостойкостью,
я выберу второе. Зачем мне быстрые монеты, если они так же быстро могут пропасть? Логично?

[mak]

При децентрализации, на данный момент, это лучшая технология, способная предоставлять гарантии корректности информации об анонимных пользователях - именно благодаря тормозам.

Наверно я плохо объяснил. Биткойн-клиент используется как есть, со всей ее защищенностью и скоростью на которую он при этом
способен. Я предлагаю оплачивать через биткойн-транзакцию не одну покупку, а сразу множество. Для этого требуется
оплата вперед или  запись долга.
При реализации магазина-автомата, эти проблемы в любом случае нужно решать.(даже если высокая скорость не пребуется )
 

Если каждый факт загрузки кусков файлов будет отражаться в базе блоков (списания или пополнения средств) то размер базы будет расти просто неадекватными и кошмарными темпами, нужны кардинально другие методы хранения информации.

 Что за база блоков?  Я предлагаю базу задолженностей (акка́унты партнеров). Т.е в нем столько записей, сколько партнеров зарегистрировалось.

[LZ]

Для этого же Ripple есть...

http://ripple-project.org/Main/Implementations

[JohnSmith]

Можно пометить адреса как доверенные и считать платеж состоявшемся вообще без подтверждений (под честное слово).

[mak]

http://ripple-project.org/Main/Implementations

 Честно говоря не особо въезжаю. Там требуется регистрация на неком сайте.
Как я понимаю, для контроля со стороны центрального органа. Т.о. это уже не P2P.
Каким образом, он обеспечит прохождение огромного количества мелких платежей?

[ArsenShnurkov]

не особо въезжаю - это уже не P2P.

Там разрабатывается и p2p версия - http://p2pfoundation.net/Ripple
Тут главное саму идею Ripple понять, а не к реализации цепляться.

[mak]

Можно пометить адреса как доверенные и считать платеж состоявшемся вообще без подтверждений.

 Если речь идет о биткойн-транзакции, все рано медленно.
А главное, база данных истории транзакций раздуется неимоверно.
Я виду речь, о тысячах платежей в секунду.
  Каким образом происходит продажа товара в принципе? (проблему скорости пока опустим)
Покупатель дает продавцу деньги, продавец должен отдать товар.
Должен то он должен, но кто его заставит? Можно наоборот, сначала товар потом деньги.
Однако, продавец вызывает большее доверие. У него бизнес и он заботится о своей репутации.
Т.к. мне все равно приходится доверять продавцу, я могу положить некоторую сумму ему на
депозит, а уже потом запросить множество товаров на эту сумму. Таким образом, не нужно
посылать транзакцию  за каждый товар.

[rPman]

Должен то он должен, но кто его заставит? Можно наоборот, сначала товар потом деньги.
Однако, продавец вызывает большее доверие. У него бизнес и он заботится о своей репутации.
Т.к. мне все равно приходится доверять продавцу, я могу положить некоторую сумму ему на
депозит, а уже потом запросить множество товаров на эту сумму. Таким образом, не нужно
посылать транзакцию  за каждый товар.

Выглядит как организация большого количества миниатюрных централизованных систем посредников с прямыми транзакциями меду участниками, которые не будут откладываться в общем логе... звучит вполне реализуемо, даже поверх bitcoin.

Реализация всего чего угодно может быть сделана, если разрешить использовать mesh сеть bitcoin для передачи шифрованных сообщений:
* создать новый тип транзакций - назвать например private или message, с ограниченным сроком жизни (кстати как долго сейчас необработанные транзакции лежат в буфере, ожидающих упаковки их в блок? как сеть реагирует на dDOS транзакциями?), можно даже зашифрованные с использованием приватного ключа адреса получателя, все получат: поймет только получатель, остальные по таймауту (чтобы лишний раз не принимать) его удаляют.
* разрешить отправку таких транзакций через https://en.bitcoin.it/wiki/IP_Transactions (это немного не то, сейчас это только возможность получить адрес для приема монет по IP), при отсутствии необходимости в анонимности, для скорости и чтобы не флудить в сеть лишними транзакциями.
* чтобы хакерам сделать жизнь слаще, такие транзакции можно делать платными (пусть платит тот кто выслал, вот только непонятно кому, а точнее как, ну, например, тому, кто первый обнаружит такую транзакцию и придержит ее у себя, для периодической повторной рассылки на время жизни сообщения), сложный момент, непонятно можно ли реализовать и как, но собственно тут вся собака и зарыта,.. обсуждаемо, но если этого не делать, то сама сеть bitcoin вообще получается не нужна.. иначе приложение само может себе создать mesh-сеть и поддерживать ее самостоятельно, более надежно, секурно и не мешаешь другим.

Сам клиент bitcoin никак не хранит эти сообщения, он должен их только доставлять до адресата, а уже пользовательское ПО средствами JSON запросов собирает присланные сообщения и обрабатывает как хочет... теми же средствами можно высылать ответ (или пакетом выслать сразу много ответов-подтверждений)

А дальше уже приложение само контролирует:
* private-account - некий идентификатор, определяющий этот подаккаунт и связанный с bitcoin-адресом, шифрующим или подписывающим сообщение
* private-balance - размер средств у этого подаккаунта
* типы private-транзакций:
 + sendtransaction - перемещения денег с балланса отославшего сообщение на указанный список с указанными значениями (все как у обычных транзакций bitcoin)
 + getbalance - запросить текущий баланс
 + setbalance - установить баланс, это ответ обработчика балансов на запрос getbalance или отсылается при любых изменениях баланса
Для примера есть 2 кошелька SERVER и CLIENT, у каждого по одному bitcoin-адресу выделено под использование private-account, каждый из которых назовем server и client, определяющий, например, балансы пользователя, только у SERVER аккаунт client, а у CLIENT аккаунт server, оба являются объемом средств пользователя CLIENT на SERVER..

p.s. самое главное, все вышеописанное требует, чтобы клиенты доверяли серверу (тому, кто теперь хранит их аккаунты)

[mak]

Реализация всего чего угодно может быть сделана, если разрешить использовать mesh сеть bitcoin для передачи шифрованных сообщений:

Что-то я не пойму, какие проблемы решаются?
 Допустим, я хочу воспользоваться услугами электронного магазина.
 Если я (в смысле, программа на моей машине) первый раз захожу на IP-адрес этого
магазина (оп каналу SSH) - производится взаимная регистрация: он меня прописывает в
свою базу я его в свою аналогичную. При этом, мы обмениваемся биткойн-адресами,
по которым мы сможем пополнять депозит друг друга и паролями для логина.
Чтобы пополнить мой баланс в этом магазине я посылаю транзакцию
и вычитаю посланное количество бтц из баланса этого магазина в моей базе.
Когда магазин получит транзакцию с адреса, который я ему  предоставил
на адрес который он предоставил мне то для него это будет означать
пополнение моего баланса. По моему, для общения между
программами, JSON слишком круто. Последовательность слов-команд - вполне достаточно.
 Из входного потока извлекается очередная команда, ищется в словаре и запускается
соответствующая ей процедура. Стоимость платных команд может
меняться. ( платные - значит при выполнении которых, из моего депозита
будет вычтена их стоимость (к его балансу в моей базе стоимость команды прибавляется)).
Перед посылкой на выполнение платных команд требуется их активация. Активация
 - это запрос их текущей стоимости. Активация требуется при новом логине и по команде
 партнера произвести повторную активацию (что означает магазин поменял цены).
Среди (бесплатных) команд так-же есть команды:  погасить долг,
запрос значения на которое я могу уходить в минус,
выяснение своего баланса и т.п.

[rPman]

Реализация всего чего угодно может быть сделана, если разрешить использовать mesh сеть bitcoin для передачи шифрованных сообщений:

Что-то я не пойму, какие проблемы решаются?

это я похоже не понимаю какая цель?

Допустим, я хочу воспользоваться услугами электронного магазина.
 Если я (в смысле, программа на моей машине) первый раз захожу на IP-адрес этого
магазина (оп каналу SSH) - производится взаимная регистрация: он меня прописывает в
свою базу я его в свою аналогичную.
 При этом, мы обмениваемся биткойн-адресами,
по которым мы сможем пополнять депозит друг друга и паролями для логина.
Чтобы пополнить мой баланс в этом магазине я посылаю транзакцию
и вычитаю посланное количество бтц из баланса этого магазина в моей базе.
Когда магазин получит транзакцию с адреса, который я ему  предоставил
на адрес который он предоставил мне то для него это будет означать
пополнение моего баланса.
По моему, для общения между
программами, JSON слишком круто. Последовательность слов-команд - вполне достаточно.
 Из входного потока извлекается очередная команда, ищется в словаре, и запускается
соответствующая ей программа. Стоимость платных команд может
меняться. ( платные - значит при выполнении которых, из моего депозита
будет вычтена их стоимость (к его балансу в моей базе стоимость команды прибавляется)).
Перед посылкой на выполнение платных команд требуется их активация. Активация
 - это запрос их текущей стоимости. Активация требуется при новом логине и по команде
 партнера произвести повторную активацию (что означает магазин поменял цены).
Среди (бесплатных) команд так-же есть команды:  погасить долг,
запрос значения на которое я могу уходить в минус,
выяснение своего баланса и т.п.

обычный веб сервер и протокол https, простейшее приложение на сервере, делов любому фрилансеру - на вечер/два + дизайн.

p.s... с соответствующими минусами - наличие публичного сервера, а значит и хостера, dns и т.п.
(здравствуйте, я правообладатель/правозащитник/ваш конкурент/злобный троль,.. у вас тут наша 'политическая педо-порнография' завалялась, пройдите в кассу или в тюрьму)

Каким боком тут bitcoin? исключительно как средство проведения платежей?

[mak]

Каким боком тут bitcoin? исключительно как средство проведения платежей?

  bitcoin относится к балансу в базе акаунтов/задолженностей как нал к безналу. Я предлагаю не новую валюту,
а другое представление бтц.

Когда магазин получит транзакцию с адреса, который я ему  предоставил
на адрес который он предоставил мне то для него это будет означать
пополнение моего баланса.

  bitcoin-клиент для передачи набирает требуемую сумму с разных адресов.
Послать с определенного адреса можно, но для этого на него предварительно нужно
переложить с других адресов послав транзакцию, но это делать не хочется.
Пусть bitcoin-клиент посылает как хочет. С какого адреса придет платеж сообщается
отдельной посылкой. Если требуемую сумма собирается с разных адресов, для
упрощения, эти адреса складываются XORом и сообщается результат этой операции.

[Qtiger]

В целом идея интересная. Но не как замена биткоину, а как развитие его инфраструктуры.

В идею биткоин-банков я не верю, на счетах отдельных сервисов не должно скапливаться очень много чужих денег. Слишком большая ответственность для создателя веб-сайта (ведь скорее всего, о нём будет мало что известно). И после аккумуляции большой суммы, он может легко скрыться.

Но, небольшой резерв на сайтах вполне возможен(например при интернет-магазинах), и протокол обмена между заинтересованными сайтами.
То есть внутренняя валюта сайта приравнена к биткоину, и сайты в такой системе обязуются обмениваться между собой. Доверие к каждому сайту основано на рейтинге и отзывах. И всё может смотреться через какой-то общий программный интерфейс (здесь даже p2p-особо не нужен, разве что хранить рейтинги и отзывы распределёно).

Как я это вижу.
Допустим есть некий магазин торгующий книгами, есть второй сайт ком. игры у которой есть внутренняя валюта и какой нибудь сервис вроде доски объявлений с платными услугами.

Человек скачивает спец. программу, открывает её.
Там он видит 3 этих сайта (у каждого свой лого,название, рейтинг, отзывы).
Через протокол программа подключается к внутренним счетам этих сайтов.

Допустим у пользователя осталась сдача от покупки в первом магазине (купил другую книгу например, не ту что планировал). Он часть переводит на счёт сайта с игрой, часть на сайт платных услуг доски объявлений.
Транзакция, копируется либо на все сервера сразу, либо хранится в распределённой сети (если делать p2p).
То есть это просто сервис по оптимизации скорости, но сама эмиссия основана на вводе/выводе биткоинов.
Такая сеть резервирования, гораздо более уязвимей сети биткоина, но там где нужна скорость, она будет более удобней, и эти внутренние валюты можно перевести в биткоины (так как они к нему привязаны).

[murasha]

Однако, продавец вызывает большее доверие. У него бизнес и он заботится о своей репутации.
Т.к. мне все равно приходится доверять продавцу, я могу положить некоторую сумму ему на
депозит, а уже потом запросить множество товаров на эту сумму. Таким образом, не нужно
посылать транзакцию  за каждый товар.

Ну так почему бы просто не сделать депозит продавцу на баланс в его магазине.
Здесь все от продавца зависит - если у покупателя есть счет, то покупатель может заранее его пополнить.
А все что выше описано - лишнее.

[mak]

Доверие к каждому сайту основано на рейтинге и отзывах. И всё может смотреться через какой-то общий программный интерфейс (здесь даже p2p-особо не нужен, разве что хранить рейтинги и отзывы распределёно).

По моему, не надо валить все в одну кучу. Программный интерфейс должен предоставить доступ к услугам магазина.
Рейтинг - отдельная задача и решается отдельно. Магазин - сервер, покупатель - клиент. Однако, покупатель может оказаться
таким-же магазином (подобным). Каждый владелец компьютера, как минимум, можем продавать файлы,
ресурсы машины и потреблять рекламу.  Партнеры могут обмениваться платными командами
(не зависимо, кто с кому залогинился).

Человек скачивает спец. программу, открывает её.
Там он видит 3 этих сайта (у каждого свой лого,название, рейтинг, отзывы).

  Не надо спец. программы. Тем более, нельзя увязывать конкретную группу магазинов.
Магазин предоставляет спецификации к словам командам. Для запроса товара, всего-то, достаточно
команды с 2-я параметрами - название товара и адрес доставки.
В частности, покупку можно осуществить в ручном режиме, по средствам SSH (по средствам терминала типа PuTTY).

Допустим у пользователя осталась сдача от покупки в первом магазине (купил другую книгу например, не ту что планировал). Он часть переводит на счёт сайта с игрой, часть на сайт платных услуг доски объявлений.

Это уже следующий этап. Магазин должен вернуть остаток по требованию (по средствам бтц-транзакции).
Перевод средств на счет в другой магазине - дополнительная услуга. Для этого, "сайт с игрой" должен предоставить
услугу по переводу средств на счет другого пользователя (в рамках данного сервера). Если при этом, "первый магазин"
является клиентом "сайта с игрой", он может предоставить своим клиентам переводить средства на счета в "сайте с игрой".

[mak]

Здесь все от продавца зависит - если у покупателя есть счет, то покупатель может заранее его пополнить.
А все что выше описано - лишнее.

  Что-то я не улавливаю отличия от того, что я предлагаю. Что лишнее и почему?

[pent]

Единственный способ достижения мгновенных платежей - это "авторитетные" биткоин банки со своими апи для мерчантов. Клиент ложит сумму в "банк", а потом ходит и расплачивается в инете мгновенно.

А временную задержку генерации блока никак не обойти.