It doesn't even cover one day maximum move.

You can see price range and initial margin yourself. There is a formula for var. margin. So you can calculate maximum loss.

Duh. I discussed this very problem with Fireball ~2 years ago, before ICBIT was implemented.

It is fundamentally impossible to implement an anonymous market for classic futures.

One either needs to introduce some kind of a counter-party risk, but it has an unfortunate effect: it is quite like a lottery in sense that market participants never know when it will bite them; and it is exploitable by scammers.

Or introduce limits on profit and loss, so contracts won't behave as futures anymore.

Actually you have a chance to do this if you want.

I talked to Vitalik, he will start with shortest distance db first, and he haven't started with DFS-coloring, so it's an open task now.


Wow, that's weird.


Yes, we have our own half-assed tx data server which can work instead of blockchain.info, I think.

У LTC есть www.litecoinglobal.com и куча других сервисов, а у вас что? Не всё упирается в майнинг.

LTC позволяет мне покупать акции какой-то хлебопекарни в Мексике, согласитесь, это уникальное предложение.

Что такого уникального продаётся за NVC?

Well, it is possible to do same thing, but without vanity addresses. In fact it is already implemented, sort of.

To be honest, I have no idea.

All I know is that server can get transaction history from Bitcoin network, and that's enough.

If client side was working once, it probably still works now. Client just needs cryptography to work, the rest is fairly straightforward.

There are talks about using bitsofproof instead of bitcoinjs server. bitsofproof is being actively developed now.

Yeah, I suspicious of in-browser wallets too.

Now ArmoryX is more-or-less dead, and so Electrum development will likely get higher priority, so we can allocate bounties for color-aware Electrum. (I'm not sure how much exactly, though.)

However, my opinion is that electrum-server is a piece of shit, and it is not suitable for what we need out of box. (At least it wasn't when I've checked it.)

I'd rather use a different server. Protocol doesn't matter much.

Vitalik is going to port DFS coloring to JS.

Shortest distance to coinbase server is still up for grabs.

I think it's only a couple of hours of works for an experienced developer who knows both node js and bitcoin stuff, so 7 BTC bounty corresponds to ~$100/hour pay, which is pretty good. :-) Of course, this number is lower for a person who cannot develop it this fast.

How do you know whether a fragment of a picture is correctly rendered?

Suppose I don't even have a GPU, but I love money, so I will get rendering job, but will submit just some black pixels.

How do you detect a fraud like that?

What if I will modify software to do a cheap inaccurate rendering, and thus get an ability to render 100x more images than my GPU allows.

That would give me 100x more profit.

Well, protocol outlined by OP is kinda defective, but it is possible to make a good protocol using smart property:

The seller of the software will send a coin representing smart property ownership to customer's wallet. (Obviously, wallet needs to be smart property-aware.)

Software will then need to communicate with that wallet, requesting proof of ownership of a private key smart property was sent to.

It will check such proof periodically.

Suppose hackers copy private key... If private key isn't secret anymore, anybody can transfer this coin from it, and software licensing module can detect this.

So we have three advantages compared to system we have now:

1. There is no activation server, software will work as long as bitcoin blockchain is alive.
2. One can sell software, simply transfering smart-property coin to buyer's wallet.
3. There is a strong incentive NOT to share your private key with anybody you do not trust. E.g. you can install software on 10 computers within your organization, but if you post key on forum you'll lose your software.

Companies can further discourage piracy by offering trade-in: customer will return an old smartproperty to get discount on new version.

Of course, one might hack by patching a binary...

But, honestly, I don't think that smart property-based software activation is better than monthly membership model like this: http://www.adobe.com/products/creativecloud.html

Company can get a steady stream of revenue, and customer pays only as long as it uses this software.

Bitcoin isn't particularly relevant for monthly membership, it is just a payment system like any other.

Yes, theoretically possible, but not as easy as mining because rendering requires a lot of data to be transfered.

Another problem is that it is possible to check whether hashing work is honest, but it isn't possible to check whether rendering work is honest.

Perhaps somebody can develop a rendering algorithm which isn't that much data-intensive. Say, in theory, it's easier to distribute voxel rendering work, but voxels kinda suck, nobody uses them.

I guess I need to provide some context... A centralized exchange like MPex both lists securities (including contracts, some statistics, etc) and provides the means of exchanging them, i.e. executes orders.

Decentralized exchange, like one based on colored coins, is supposed to provide an ability to trade without using one centralized service of some sort.

Basically, any trade with securities listed on MPex goes through MPex, and it depends on MPex. I.e. if MPex is down, you cannot trade. If MPex blocked your account, you cannot trade. If MPex knows who are you, it can report you to authorities. Etc.

Trade with colored coins can be completely person-to-person, e.g. you might meet somebody in person and send shares to their address and they'll give you cash. In a more realistic scenario people can use p2ptrade protocol which would allow to trade safely and anonymously. (Well, it is as anonymous as Bitcoin. I.e. probably not completely anonymous.)

But still, if somebody wants to trade using a centralized service of some sort, it's his right. It's just that people do not need rely on a centralized service.

OK, anyway. The way I see it, exchanges can still exist in 'colored coins' model, but their role is reduced to publishing listing information and whatnot. Exchange is an informational tool, it merely helps investors to find securities they might want.

There might be different exchanges. Perhaps some will enforce some quality standards for contracts and assets. (You know, like MPex lists few securities, but those have professionally composed contracts, some financial reporting standards and relatively high market cap.) It might provide additional services like charts, faster trading protocols and whatnot.

It is important to understand, however, that we are talking about OPTIONAL services.

Company can sell its shares without being listed on any exchange. (It can publish color definition on its own web site.) People can trade shares without relying on any particular service.

Exchanges are supposed to improve convenience for investors, and there is nothing wrong with it, it doesn't betray a goal of decentralization in any way.

In same way existence of bitpay and mtgox doesn't make Bitcoin any less decentralized.

Well, Devcoin kinda works, and this one seems to be somewhat similar on the surface.

Are you familiar with devcoin model?

I've tested coloring via bfs traversal on the real blockchain, and it doesn't work so well: sometimes it needs to scan like 20000 transactions to get to coinbase one. (And thus prove that output in uncolored.)

DFS seems to be a little better, but it blew up Python stack on at least one output, which means that depth is about 1000, which isn't cool either.

So I think we need a solution which finds the shortest path.

So to start with this we'll allocate two bounties:

1. Port dfs backward-scan coloring to JavaScript: 5 BTC.

As I've already mentioned, it is already implemented in Python by Vitalik Buterin.

BFS version: https://github.com/vbuterin/BitcoinArmory/blob/color/gettxcolor.py

DFS version: https://github.com/vbuterin/BitcoinArmory/blob/92f021b0770cf7504bbe5df17d89044b97fc901b/gettxcolor.py

However, DFS should be implemented in such way that it doesn't blow up the stack, also it needs asynchronous queries, so it's going to be considerable different from Python version in structure. But still you need something like get_matching_inputs to do the coloring.

Theory: https://github.com/bitcoinx/colored-coin-tools/blob/master/colors.md

To access transaction information you can use blockchain.info API: http://blockchain.info/ru/api/blockchain_api (and async queries, of course!), but please abstract transaction-data query function so we will be able to use it with a different API.

You can take this code for an inspiration: https://github.com/domtancredi/bitcoinjs-color/blob/master/async.js it kinda tries to implement this via DFS, but is broken. Still you can borrow general structure etc.

2. Build shortest path database based on bitcoinjs server: 7 BTC.

We need to know distance from a transaction output to nearest coinbase. We will store these distances in database, and then query this database to find shortest path.

Algorithm is fairly simple:

Scan all transactions in blockchain sequentially starting with the first block:
1. If transaction is coinbase its outputs have zero distance to coinbase.
2. Otherwise, for each tx output, we find all matching tx inputs (same function is used for coloring, see get_matching_inputs here: https://github.com/vbuterin/BitcoinArmory/blob/color/gettxcolor.py)
    Fetch distance of each input from database (they are already there because we're scanning sequentially).
    Find minimum of input distances, then output's distance is minimum+1.
    Write this number to database.

I recommend using this as a starting point: https://github.com/0i0/bitcoin-tx-spent-db
It is a thing you need to run together with bitcoinjs server, basically it installs its query code into bitcoinjs, then it provides REST API to database it have built.

You can either fork it and replace spent-db code with distance-to-coinbase code. Or you can extend this code and write to two separate collections. It's up to you.

The starting point is  https://github.com/0i0/bitcoin-tx-spent-db/blob/master/app.js -> everParseBlock -> getCollection, it is a function which goes through transactions and adds the to database, but in our case it should find shortest distance for each output and write it to database.

Please note that working with main net is very resource intensive, you'll need 20+ GB of disk space and 20+ hours for processing. Use testnet, there is a command line option for bitcoinjs. (Don't forget that genesis tx hash is different, for some reason it is used in app.js)

Both tasks share the need for get_matching_inputs. It would be cool to implement it only once in JS, but it's not critical, I guess.

That's all... Whoever wants to work on this, please let me know. Questions are welcome not matter whether you're going to work or not.

If you think that bounty is too low (e.g. you would do it for 10 BTC), please let me know.

Check this: https://en.bitcoin.it/wiki/Smart_Property


Well, there is no defense against software patch.

Не советую, там много буков

Но основная идея простая: те кто хочет заниматься майнингом должен превратить деньги в stake, после этого он может подписывать транзакции (по определённому графику). Если обнаружен double-spend то майнера банят, его деньги не возвращают.
При желании можно перевести stake обратно в деньги, но ввод-вывод занимает какое-то время.

Остальное -- сложная система генерации новых монет, организация майнеров и т.д.



Хороший вопрос

Я пока не знаю как должна работать "идеальная" криптовалюта, а браться за такой масштабный проект просто чтобы реализовать одну идею, по-моему, не стоит.



Да, с Ripple не всё ясно, но распределённый консенсус может работать если удастся решить проблему с Sybil attack.

К примеру, как предлагает Ben Laurie http://www.links.org/files/distributed-currency.pdf , проверочными узлами могли бы стать приличные коммерческие и некоммерческие организации. Вероятность что все они войдут в сговор крайне низка.

Насколько быстрыми?

10 секунд на блок вполне реально, по-моему. Такое расстояние между блоками используется сейчас в p2pool. В GeistGeld было 15 секунд.

Конечно, 6 10-секнудных блоков это совсем не то же самое что 6 10-минутных блоков. Но для небольших транзаций, вероятно, хватит.


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

Какой-то анализ пытался провести Meni Rosenfeld: https://bitcointalk.org/index.php?topic=79837.0
Но ничего конкретного я не вижу. Видимо, сложная тема.



Пока не смотрел.

Есть большой интерес к point of sale использованию.

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

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

В принципе можно рассмотреть экономическую модель атаки включающую аренду hashrate.

Пусть аренда hashrate соответствующей вероятности нахождения блока q равна C(q, T).

Матожидание прибыли от атаки равно k(T, q)*Gds - C(q, T) где k(T,q) -- матожидание количества удачных double-spend за время T, Gds -- прибыль от одной double-spend.

k(T,q) = Psds(q, n, f) * T/(Ti*n*f)

где Psds(q, n, f) -- вероятность удачного double spend за время соответствующее n*f блокам (формулу можно найти у Розенфельда) при необходимости n подтверждений
Ti -- временной интервал между блоками

Пусть Tc -- среднее время подтверждения транзакции, тогда Ti = Tc/n.

Тогда имеем: k(T,q) = Psds(q, n, f) * T/(Tc*f)

Т.о.

profit = Psds(q, n, f) * T/(Tc*f) * Gds - C(q, T)

Наша цель -- минимизировать профит атакующего изменяя Tc и n. Понятное дело, большее время конфирмации Tc даёт большую надёжность, но время ограничено соображениями удобства, к примеру, Tc = 1 час. Для заданного Tc мы можем минимизировать экономический эффект атаки изменяя n: при больших n Psds(q, n, f) меньше.

Таким образом большая частота блоков надёжнее. (Если не принимать эффекты начинающиеся при большей частоте.)

С точки зрения атакующего дело выглядит несколько иначе: он может оптимизировать свой payoff изменяя q, T и f.

Функция C(q, T) нелинейна и зависит от используемых технологий.

В случае если для атакующего оптимально q > 0.5 (а я думаю оно оптимально если C линейна по q и T), то безопасность сети зависит только от Ts и n не имеет значение.

Но это вырожденный частный случай. При прочих равных болшее n безопаснее.

С практической точки зрения куда интереснее мгновенные надёжные переводы с использованием доверенной стороны.

Это можно сделать при помощи multi-sig платежей. К примеру, Вася перечисляет свои 3 биткоина на multi-sig адрес так что платёж требует две подписи: Васину и InstantPaymentsInc.

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

Магазин в котором Вася купил пирожок доверяет InstantPaymentsInc и поэтому отдаст пирожок Васе сразу же. Если Вася попробует сделать double spend то на второй транзакции просто не будет подписи InstantPaymentsInc.

Почему InstantPaymentsInc можно доверять?

Если эта компания позволит double spend то разрушит свою репутацию, соответственно никто не будет платить за её услуги в будущем. Если цена пирожка меньше чем прибыль InstantPaymentsInc то обманывать экономически невыгодно.

Конечно, если речь идёт о передаче миллиона долларов, то лучше подождать конфирмаций.

Так что вопрос: что за use case такой что 5 минут подождать можно, а час уже нет?


Уже придумали... Быстрые и надёжные платежи теоретически могут быть обеспечены чистый proof-of-stake (см. Eltase2 decrits) и распределённый консенcус вроде того, что реализовано в ripple.com.

В чистом PoS обязательно должно быть наказание за double-spend. К примеру, у майнера ставка миллион баксов. Если он сделает хоть один double-spend он лишается ставки. Т.о. ему можно доверять передачу сумм меньше миллиона.

Откалибровать PoW или PoS+PoW так чтобы какая-то надёжность достигалась за 5 минут наверное можно, но зачем?

Об абсолютной гарантии, кстати, речь вообще не идёт. В любых подобных схемах double spend просто невыгоден экономически. Но нельзя исключать возможность взлома майнеров и т.д.