Можно зарабатывать и на понижении курса. Например, текущий курс 25, вы думаете что он упадёт до 20 на следующей неделе, но в долговременной перспективе коины буду расти выше 25.

Тогда имеет смысл их продать по 25, а затем затариться по 20. Т.о. можно повысить их кол-во на 25%: из 100 BTC сделать 125.

То же самое можно сделать через фьючерсы: заключить контракт о продаже по 25 через неделю. Прибыль та же: 25 BTC.

Но при этом для фьючерсов с ограничением для заключения контракта нужно всего 25 BTC.

Т.о. при прямой продаже прибыль 25%.

При продаже через ограниченный фьючерс мы имеем 50 BTC из 25, прибыль 100%.

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

Есть три варианта применения:

1. Вы спрогнозировали куда пойдёт курс и хотите на этом заработать.
2. Вы считаете что курс будет оставаться на месте или медленно рости, но хотите подстраховаться от резкого падения (или роста)
3. Вы ожидаете поступление денег в будущем в одной валюте, а хотите их сконвертировать в другую по заранее известному курсу.

Разные варианты фьючерсов и опционов более или менее подходят для этих целей.

Тот вариант что у меня идеально подходит для того чтобы делать ставки на изменение курса BTC к USD оставаясь при этом в BTC.

К примеру, у вас есть 100 BTC, сейчас они торгуются по 20, а вы ожидаете что на следующей неделе будут по 30.

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

Вместо этого вы можете заключить фьючерсный контракт: "покупаю 100 BTC по 25 USD/штука через неделю".

Тогда если действительно они торгуются по 30 USD за штуку а вы купили по 25 то вы получаете прибыль по 5 USD за штуку, или (5 * 100)/30 = 16.67 BTC.

Т.о. в итоге вы получите 116.67 BTC. вместо своих 100 BTC.

Или в долларах: предположим вы купили когда курс был 20, а продали когда он по 30, доход 3000 - 2000 = 1000 USD.
А если вы ещё воспользовались фьючерасами то доход получится 3500-2000 = 1500 USD. То есть фрьючерсы дали дополнительно 500 USD.

Если курс вырос всего до 25 BTC то вы ничего не выигрываете и не теряете. Контракта как будто и не было.

Если он не вырос совсем и остался на 20 BTC то вы теряете по 5 USD за штуку, т.о. (5 * 100)/20 = 25 BTC.

Мой сайт все расчёты проводит в BTC, USD там фигурируют только при указании курса. Но при этом прибыль измеренная в BTC в точности равна тому, что бы вы получили проводя реальную покупку/продажу по контракту и проводя обмен через MtGox. (С небольшой особенностью: курс считается средний за прошедшие 24 часа.)

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

Для описанного выше случая подойдёт резерв в 25% от суммы, как для продавца так и до покупателя. Т.о. каждый кладёт по 25 BTC на кон.

Тогда при курсе ниже 20 убытки перестанут рости, они ограничены 25 BTC. А прибыль перестаёт рости на курсе 33.33 USD за BTC.

Вся загвоздка в том, что нужно чтобы нашёлся человек который согласится на другую сторону сделки. Например, чувак который думает что BTC останутся на 20, а выростут максимум до 25.

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

Товарищи трейдеры, как вы относитесь к фьючерсам и опционам?

Я сделал сайт для торговли фьючерсами особого вида (cash-settled in BTC): http://killerstorm.xen.prgmr.com:31337/st/main.html
Описание: http://forum.bitcoin.org/index.php?topic=14059.0 (советую сначала прочитать описание, хоть оно и длинное).

Он немного недоделанный, хотя торговать уже можно, только аккуратно.

Кроме того недавно запустили вот такое: https://bitoption.org/ (Точнее запустили они ещё пару недель назад но несколько раз переделывали.)

Есть ли что-то такое что на bitoption.org сделано не хорошо и можно сделать лучше? Т.к. я планирую добавить опционы.

В целом у меня концепция несколько иная -- все расчёты и резервы исключительно в биткоинах, без конвертации в USD, т.о. это скорее игра на курсе, а не прикрытие позиций.

Есть ли ещё площадки для торговли этим о которых я не знаю?

Here's a history of your orders:

2011-06-10 15:03:29 sell 0.03 30 +1 100 50
2011-06-10 15:04:39 sell 0.05 28 +1 50 50
2011-06-10 15:05:16 sell 0.04 25 +1 75 75
2011-06-10 18:58:53 sell 0.03 30 +1 50 50

Current version of exchange requires same reserve percentage for both parties so (0.05 28 +1 50 50) order matched while (0.03 30 +1 100 50) did not.

Even though there was a fuck up on my side (they did not match automatically until I fixed the bug) result is the same.



Sending new password to email? It is not very secure, you know...

But I guess I'll add an optional email field and password resets would be handled manually.



I guess withdraws will be manual until I'll get enough BTC to cover potential loss on txn fees. (And hopefully upcoming bitcoind versions will allow better management for txn fees.)

But I guess I'll add a button to add withdraws into a queue for manual review and execution.

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


Я думаю какая-то часть будет постоянно в обороте, а какая-то осядет в долгосрочных сбережениях. Хранить деньги в биткоинах имеет смысл -- инфляции они не подвержены.
А часть будет перманентно утеряна...


Хранить их должен каждый полноценный участник сети, а не только майнеры.


Идеологически неверно НЕ проверять блоки. Майнеры ведь могут включить в блоки неправильные транзакции с целью наживы.

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

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

Да, можно требовать двух подтверждений. Но вероятность что один майнер выдаст два блока подряд весьма существенная.

Насчёт идеологии, я боюсь вы вообще её не правильно понимаете.

Безопасность биткоинов основана на том, что сами участиники сети заинтересованы в своей же безопасности. А если их много, то мала вероятность того, что они войдут в преступный сговор. И именно поэтому консенсус реально работает.

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

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

Но реально важны именно майнеры. В идеале должно существовать большое количество майнеров с равными вычислительными возможностями: в этом случае очень мала вероятность что они войдут в сговор ради собственной наживы.

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

Не важно сколько людей занимается хэшированием, они выполняют тупую работу. Важно что все транзакции проверяет и выбирает deepbit, и он может делать что угодно. Если даже сейчас у него ресурсов не хватает, что будет если он объединится с несколькими другими пулами? За ними стоят люди и их можно подкупить. Ситуацию с пулами смотрим здесь: http://www.bitcoinwatch.com/

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

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

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

Собственно, пока что пулы текущие правила вполне устраивают -- по 50 BTC за блок вполне нормально. В будущем эта халява прекратится, награды уменьшатся. Тогда пулы могут принять решение увеличить комиссию за транзакцию. Или, например, продолжать выдавать по 50 BTC за блок.

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

Далее, к примеру, они могут выпустить свой, слегка пропатченный клиент. Хочешь чтобы твои транзакции проводились -- пользуйся одобренным пулами клиентом и плати комиссию. Иначе биткоинами пользоваться не получится.

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


Да можно ещё более радикально -- выделить одну trusted party подписывать блоки. Хуле там, зачем нам вообще майнинг?


А как ты новичку объясняешь что после запуска клиент часа три тарахтит винтом скачивая транзакции?

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

IMHO обычный пользователь должен пользоваться 3rd-party поставщиком услуг а не работать напрямую с сетью.

При этом возможно создание клиента, который приватные ключи хранит локально а за всем остальным обращается на сервер.


То есть больше часа ждать подтверждений? Ну спасибо.

Я ещё раз советую перечитать. Легковесная проверялка должна через опрос сети убедиться что более длинной цепочки ни у кого нет.

Т.о. злоумышленнику будет достаточно того, чтобы к этим тонким клиентам настоящая цепочка не попала. Например, спомощью ботнета сделать кучу фейковых клиентов которые будут давать только цепочку злоумышленника и гасить настоящую. Забить ими IRC каналы и т.д.

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

Не совсем так. Outputs транзакции описывают кто и как может использовать коин. После того как его используют (в другой транзакции) эта информация уже не нужна.

Т.о. можно удаять только те транзакции, все output'ы которых потрачены. А их как правило два, т.к. нужна сдача.

Более того, после удаления транзакции остаются хэши дерева Меркле. Их можно удалять только когда все транзакции в ветке дерева удалены.

Т.к. не все коины сразу же тратятся с большой вероятностью значительный объём данных прийдётся сохранять. По оценкам сейчас с помощью это оптимизации можно цепь сократить примерно до трети (https://en.bitcoin.it/wiki/Scalability) . По большему счёту это ничего не решает.

К тому же имеет смысл посмотреть на bitcoin days destoyed метрику которая показывает, грубо говоря, какая часть биткоинов находится в обороте. Примерно 25%. Остальные пылятся. Вот все что пылятся нужно описать в блокчейне.



Нет.


Не в официальном клиенте. Официальный клиент это полноценный нод который проверяет все транзакции.

Пока сеть не очень развита не следует слепо доверять получаемым блокам.


Угу. Но комфорт вновь подключающихся не является приоритетом. Серьёзные пользователи узнают адреса нодов из других источников (twitter, форум и т.д.) А несерьёзные пусть пользуются eWallet типа MyBitCoin.com или MtGox.

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

And we've got a settlement at 26.823286 spot price (due to 24h average it didn't drop very fast).

I've put in my 0.01 BTC and earned 0.0005 BTC through buy 0.0074 at 25.

dacoinminster lost some money on his buy at 28 and the other guy earned a little bit from this two contracts.

So it totally works

We've got a first contract!

There was a bug that orders were not matches properly. I've fixed it and then I canceled and placed again dacoinminster's order.

Since the other guy had sell @28 it was matched with dacoinminster's order and resulting contracts are are at 28. So dacoinminster got a better deal.

This is a feature: when you place an order you might get better price than you're asking. Contacts are always created at prices of orders which are already in order book.

I apologize to dacoinminster's counter-party: if there was no bug in code and orders were processed in order they were placed he'd get sell @30. But, well, sell at 28 was his choice...

My intent was to prevent order spam like creating tons of small silly orders or something like that. You can do that but you need to pay for it.
I see how commission might be frustrating if order did not work, but I guess it will be less of an issue when exchange goes more lively.

Fee is tiny anyway.

What do you think about making reservation at time of making order? My rationale for not making reservation is to help market makers who would make orders in different directions: if one order is filled then they won't need reserves for another one.
Also people might try to place orders on different dates to see which one works.

But maybe it is better to make sure that there is enough reserves for orders all the time. And then if, say, market makers want it other way this over-commit feature can be enabled for them specifically.


You've placed your order on 2011-06-10 00:27:26. Currently time is 2011-06-10 17:00:21.
It will expire at 2011-06-11 00:01.

http://wwp.greenwichmeantime.com/


Yep, I see. Other people pointed that out too.

A problem is that I have only 0.02 BTC and buying them is kinda of PITA

But my hope was that people would be more eager to play with a few bitcents.

Anyway I'll try to populate it with my own money for the beta release.


Thanks, that's a good idea.


Yep, I see. But the ugly URL kinda warns people that software is of alpha quality and they shouldn't send tons of money here


Thank you too.

As you probably noticed, there is one more user. He have almost made a contract with you, but he set 100% seller reserve requirement instead of 50% default, so it did not work.

I think exchange should have created contract anyway because when seller sets reserve percent to 100% this means that he would reserve up to 100%, but reserving less shouldn't be a problem.

So I think it should have made contract with 50%/50% reserves even seller could pay more. But I just haven't implemented this logic yet.

I have an idea of making a virtual market (aka prediction market, derivative trading...) where people will be able to bet on pretty much anything.

Particularly, stock market prices. E.g. if you believe that AMD stock price will be at least 9 in a month you can do this by making futures/options contracts. Then virtual exchange monitors real exchange and does settlement: awards profits to ones who won (at cost of ones who lost).

The thing is I've already implemented this for exchange rate speculations (see http://forum.bitcoin.org/index.php?topic=14059.0) but it all depends on what 'spot price' is, so it can be easily transformed into arbitrary virtual market.

Of course, it also needs a simple front end which allows people to make a simple bets. E.g. "I bet 25 BTC on AMD market price higher than 9 in a month", literally. This will be translated into futures contract or an option. And expert users will be able to work with those futures/options directly.

But I wonder whether people are interested in this stuff... I've seen moderate interest in futures trading, but when I've actually launched it it currently has just one user who deposited 0.03 BTC.

I don't quite get WTF happens, either people see it as not reputable enough (but hey, 0.01 BTC isn't a big sum to lose, right?), or they are not interested because they all bet on BTC by buying them. (BitOptions is pretty much empty too, so I guess the later...)

Anyway, if you'd like to see virtual market please donate to this address 12xN4yB53aigoHqu1ES2m1ihGxyvFCswSk
or deposit money into my futures exchange and post a comment. Even if it is just 0.01 BTC I still would appreciate that.

I could consider open sourcing the thing, but my current code base is in Common Lisp so I doubt anybody's going to use it

Thank you!

BTW, there is a know bug: if you leave browser for a long time session will expire, but UI won't tell you. So just reload page if it acts strangely and re-login. Also I've noticed sometimes bitcoind hangs and then site hangs too, then I'll need to restart it manually...


2011-06-11 00:01 GMT


Yep I see this as a deficiency too. I'll add a button to cancel order, but not contract.

But you'll be able to effectively cancel contract by doing a contract in opposite direction... Some time in future.


If you set 50% reserve for buyer then you need only 0.015 BTC to place 0.03 BTC order plus 0.0001 in a fee. So you have 0.0149 for another order. (Keep in mind that there will be another fee and possible rounding effects.)

Note that service does simple sanity checks for orders but you can still issue many orders even if their total sum of reserves exceeds balance you have. In other words, actual reservation is made for contracts. It is a feature... or a bug.

Exchange does additional checks when orders are filled so wrong orders would not hurt.

I've switched it to use real Bitcoins in hope to get some attention (I've got like 10 people registered and looked around but nobody bothered to deposit testcoins). Seriously, WTF, announcement of upcoming project got much more attention than a working service...

'Capped futures' with full reserves are generally useful for making bets about short-term bitcoin price moves while still keeping bitcoins.

It is of limited use in case you're a merchant who accepts BTC and would like to hedge against possible price drop before he cashes out into USD: the need to make upfront reserve makes it less attractive. But if you keep some sum in BTC as a reserve you can use it for a futures contract with, say, 25% seller reserve and 50% buyer reserve, it would be better than nothing, I think. Or if you do settlements frequently (each day instead of each week) you don't need that much for reserves.

I'm planning to implement capped options next: using options you pay one-time, fixed price and enjoy protection against BTC exchange rate drops (within certain limits).

Current version is not friendly to arbitragers and market makers because you need to make individual reserve for each contract.

I'm going to fix it in the next version: if you'll have contracts going into opposite directions for a single settlement date they will essentially cancel out and you won't need to reserve for a second one. (Moreover, your currently reserved money can be freed up!)

And, finally, I'm going to implement contracts which won't need full reserves and won't be capped, but will be based on trust and insurance. Also I can implement reservation/settlements in USD (and other currencies) but only if I'll find a partner who will handle financial part 'coz I don't want to deal with official currencies myself. (Oppressive gov't etc.)

Long term plans include trading on other currencies and pretty much everything you can assign monetary value to. All it needs is a reliable way to assign spot price which cannot be easily manipulated.

There are things called prediction markets where you can even trade on events.

One particular thing which should be interesting to Bitcoin miners is betting on Bitcoin mining difficulty: when you buy a mining rig you invest your money and expect certain money flow. If difficulty goes too high they won't return their investment. So we can issue a swap contract which will exchange a variable Bitcoin cash flow which one gets from mining for a fixed cash flow at a certain difficulty. So, essentially, you can sell your hashrate on the market and get a fixed profit no matter where difficulty goes.

Old forum thread for context: http://forum.bitcoin.org/index.php?topic=5529.0

Current version works with a single type of contract: capped BTC/USD futures settled in BTC, with MtGox used as a spot price.

Here's what it means, how it works and why it makes sense:

Let's say Alice wants to sell 100 BTC for 30 USD each on a certain date (like 2011-06-15) and Bob wants to buy it. However they do not want to deal with USD because it is messy (not anonymous! subject to regulations!) and instead agree to settle in bitcoins. I.e. instead of giving Alice 30*100 = 3000 USD Bob will give her an equivalent in BTC.

Of course they need to decide what is equivalent. For example, they can agree on smoothed out MtGox price, like 24h average.

1. If MtGox price goes to 40 by the settlement date then Bob owes Alice 3000 USD / 40 = 75 BTC.

2. If it goes to 25 then it is 3000 / 25 = 120 BTC.

So in the first scenario Bob gives Alice 75 BTC and she give him 100 BTC back (amount of BTC sold). So if Bob agreed to buy at 30 BTC/USD but price went up to 40 BTC/USD he have earned 25 BTC and instead of sending money back and forth Alice can send him this sum and they'll be settled.

Likewise, if price goes down (Bob bought BTC for higher price then real price is) Bob has a 20 BTC loss and needs to send this to Alice.

So you can see this as a bet where parties agree to pay each other depending on external conditions, but in theory if Alice actually wants to buy USD she can jump to MtGox, do the trade and get them.

But as bitcoins are kinda anonymous it is hard to enforce this contract (if Bob have lost the bet he will pretend he is dead), so Alice and Bob ask a trusted 3rd party -- let's call him killerstorm -- to make sure that agreement is enforced.

Killerstorm will take money both from Alice and Bob and hold it as a reserve. At the date of settlement he will compute who owes whom how much and will move money, returning unused reserves. But now we have to deal with situation that reserves are finite and need to be available at date of agreement, not at date of settlement. Each party's profit is limited by reserve his counterparty have made and his loss is limited by reserve he made. So each party is interested in making his reserve as small as possible while conterparty's reserve is adequate. (Also it is possible that they don't have that much BTC on agreement date so reserve percentage limits contract amount.)

Reserve amounts define price range in which settlement will be exact. For example, if Bob reserves 20 BTC and Alice reserves 25 BTC then they can settle exactly as long as price is in 25..40 USD-per-BTC range. If it shots to 45, for example, Bob will get only part of his possible profit. This is why we call them capped futures.

(Note that it doesn't make sense to reserve more than 100% of contract amount for seller -- seller never takes loss higher than what he sells. Buyer's loss in BTC is potentially unbound, though -- if BTC price drops to, say, 0.01 he would need lots of BTC to settle the contract.)

So, as you might have guessed, I made a service which implements this kind of trading. It is not 100% ready yet, but at least it can accept orders, make contracts, calculate spot price and do the settlements. So I think it is usable.

But I run it on testnet for now. So instead of bitcoins it works with testcoins. Also, withdrawals are disabled. But I'll promise I'll send all testcoins I've received to the faucet.

EDIT: Due to apparent lack of interest in testnet version I've switched it to real bitcoins, but please not deposit more than a few cents -- software is not well tested yet. Minimal order is 0.001 so even one cent is enough for testing.

So here is it: http://killerstorm.xen.prgmr.com:31337/st/main.html (apparently, it is a temporary URL).

And here is how you can test it:

1. Go to http://killerstorm.xen.prgmr.com:31337/st/main.html, choose login/password and click register.

2. It it works you'll see your account (empty) and address to fill it. Note it is a TESTnet address, not Bitcoin address. If you don't have testcoins you can get them from the Faucet http://testnet.freebitcoins.appspot.com/. Then you have to wait for a single confirmation, ~10 minutes and hit 'update balance'. (Note: if server sees your transaction address will change, but it will show money only when 1 confirmation is made). (Sometimes if bitcoind hangs my server hangs too, so if it doesn't work please retry some time later.)

3. Meanwhile you can explore 'order book' (probably empty at start) and spot price sections.

4. Once you've got money on balance go to My Orders and hit 'place new order' button. You will see a dialog which is fairly obvious. Maturity is in days, e.g. +1 is next day. Price is how much USD you think one BTC will cost. Seller/buyer reserve percentage is relative to order amount in BTC, e.g. 100 BTC contract with 50% percentage means that 50 BTC is reserved. Placing order costs you 0.0001 (t)BTC. Once you place it it can be filled partially from orders currently in order book and the rest will show up in 'my orders'. When exchange sees orders in different directions which agree in price it destroys them and creates corresponding contracts. Go to 'my contracts' to see them.

5. At around 00:01 UTC (GMT) settlement will be made. Orders and contracts will be wiped, you will get money on balance and you'll see how much you've earned/lost

So, testing will take about 10 minutes to move money and <24h to see settlement. (Hmm, if you people do not like that and want to try trading part faster I can give some fake amount to each new account and set up more frequent settlements.)

On the technical side it is implemented via JSON-RPC so you can write a bot or make an alternative client.

If there is enough interest I will launch server working with real BTC (EDIT: done!), but as it is an 'alpha'-quality version I would recommend depositing no more than 0.02 BTC

Preview version running on testnet done. See reddit post http://www.reddit.com/r/Bitcoin/comments/hve8n/bitcoin_currency_futures_exchange_preview/ for details.

Currently fees are used mostly to discourage 'spam' transactions which could flood the network. They are negligible compared to number of bitcoins mined.

For example, here is one of larger blocks: http://blockexplorer.com/block/00000000000010636a97e1aa823a6b2d60b5a964f087448857190093e014a5d5
Block 12931 has 99.155 kilobytes and it got 0.581 in fee (compared to 50 BTC generated).

Let's compare it to a smaller block: http://blockexplorer.com/block/0000000000000035d573e3a205d166de752a540dd30d59477d3526ec30d9006a
Size: 15.5 kilobytes
0.2 total fees


As block size goes larger fees required by miner go large as well, so at some point if there are too many transactions they won't get into a current block (but they can go into a next one). So fees received by miner can be roughly proportional to block size, and so amount of computations needed to verify it.

But I think computational power required for verifications is negligible compared to computational power spent on mining.

A quick estimation: there would be like 4000 small transactions in 1 MB-large block. Let's say 3 msecs is spent on one verification (number from wiki). This means that one CPU core would verify the whole block in 15 seconds.

But it would take many _years_ for one CPU core to solve proof-of-work challenge. So it doesn't matter much until we'll get much larger blocks.

(It is not as simple because verification also requires IO operations, but you get the idea... At least with current block sizes like ~100 KB top it doesn't matter.)

But even if amount of CPU time required for verification is tiny miners could skip it altogether for whatever reasons. So fees, whatever tiny they are, still encourage miners to run official client but not something else.


The way it works now: client assigns a fixed fee. Miner sorts transactions by priority and goes through the list, verifying whether they have enough fees. (As block gets larger fees get more expensive.) If transaction is not accepted into block it might be accepted in some other block mined by another miner. So if you pay no fees or fees too small it would take more time until you'll get a confirmation.


Definitely it will, when there will be larger number of transactions it would make sense to make fees configurable.

In a limited way it is now -- if you want your txn to be included into a larger block you might need to configure higher fee in your client (there is an RPC call for it now).

There is also a miner who accepts lower than default transaction fees and also non-standard transactions:
https://en.bitcoin.it/wiki/Free_transaction_relay_policy

There is a simple way to make sure that txn fees are passed on users: check for fund availability in sendfrom should include transaction fee. (I.e. forbid negative account balances.)
I guess it is not made this way for convenience reasons: this way sendfrom can just use SendMoneyToBitcoinAddress function.
But it isn't hard to rewrite it a bit to use CreateTransaction instead and do a check before committing, right?

estimatetxfee might be useful, but it doesn't solve anything because it provides no guarantees.

BTW now reading the code I see that it is possible to write a send-transaction function which would cram as much as possible into a free (or minimal-fee) transaction. Is anybody interested in this?

Option 3 looks kinda complicated to implement, it can be replaced with a simple RPC API function, let's say, sendlowfee(address, amount) which will send coins one at a time.

Let's say it was called as sendlowfee(address, 100). Now if we have coin >= 100 BTC it will be sent in full.

If we don't have big sum coin but we have, say, 69.75 one it will send one transaction with 69.75 amount, and this amount will be returned as RPC result.

Now service using bitcoin server should note that there are 30.25 BTC to send and then, say, after 10 minutes it will do sendlowfee(address, 30.25).

As I understand single input, single output transactions can be send for free, so this way you can send any sum for free unless you have money in tiny (<0.01 BTC) coins which cannot be sent without fees.

Optionally it can also include a fixed fee with each small txn.

So options 2 and 3 I've described are easy to implement in bitcoind (as far as I understand) but they require complex handling in applications. They are flexible, though.

With option 1 it is send&forget, but it is not flexible and requires complex implementation in bitcoind.

Unless there is a way to do it with current software, something like this would work:

1. Pay txn fee from sum sent. E.g. new RPC function sendupto(<address>,<amount>) Let's say amount is 100 BTC. Client estimates that it will incur fee of 0.50 BTC. Then it sends 99.50 BTC and a 0.50 BTC fee. Ideally it should find optimal amount/fee ratio: if sending 99.50 BTC takes only 0.45 BTC in fee it should try sending 99.55 BTC. Then fee goes up to 0.46 BTC and it tries 99.54 BTC and so on. At some point it will converge.

2. Limit/estimate transaction fee. E.g. new RPC function maybesend(<address>,<amount>,<maxfee>). You start by calling it maybesend(<address>, 100.00, 0.0). If it can send 100 BTC without a fee it does this, otherwise it returns estimated fee size: 0.50 BTC. Then  I check whether I can pass 0.50 BTC fee on a customer, if he has >100.50 BTC in his account I call it again like maybesend(<address>, 100, 0.50). If situation hasn't changed since last call and it still costs 0.50 BTC then transaction is sent. Otherwise it returns new value, say, 0.51 BTC and I repeat the process. If customer does not have enough funds I will notify him in GUI with an option to send smaller amount (e.g. 99.50 BTC).

3. Bitcoin client should try to find a way how to send an amount within a certain maximum txn fee window. E.g. if amount is large it should try to use bigger 'coins' to limit size of transaction. If it is not possible it should try to break transaction into small pieces and send them slowly over time. As far as I understand it is always possible as long as amounts I've received are multiples of 0.01 and might be not possible otherwise.

4. If anything unconditional transaction fee limit is better than noting, at least it can be handled manually.

And finally I think fees are too damn high, they should be totally negligible (and, well, they were when BTC exchange rate was lower). But if network needs these fees for whatever reason I'm ok with this as a service-owner as long as I can pass them on users . As a user I'd be very angry being slapped with exorbitant fee     , but what can I do with that...

Wiki (https://en.bitcoin.it/wiki/Transaction_fees) described how version 0.3.20 works, apparently something have changed in 0.3.22:


but I have no idea WTF it means. Where can I find information on how exactly _current_ version works, aside from reading source code?

I'm concerned with this because I'm making a service where people can send coins to their accounts and later withdraw from them (among other things). I definitely do not want to lose my money when user withdraws his, so I'd like to pass transaction fees on users or something like that.

As I understand from a few forum discussions here fees can be pretty much arbitrary and there is no way to tell how much it costs until client makes one and there is no way to limit fees. Is it still relevant for new version?

I see a following potential attack against service owner: customer will send his money to his account slowly, over time, in tiny transactions like 0.01-0.02 BTC. Then when significant sum is accumulated, say, 100 BTC he will withdraw it. I'm lazy to calculate how much it will cost, but I guess easily fee can be larger than 1 BTC.

So at current exchange rate one can easily rob a service owner for $20, which sucks. Then he can repeat this attack until service will have no money left. This would destroy a business because other users won't be able to withdraw.

Maybe I'm a bit paranoid, but if attack described above is possible I'm kinda afraid to run a service which allows withdrawals. It's a horrible bug in software IMHO.