I've thought about this and may add it, but currently I don't see a situation where this will be needed and still be fair to investors. Controlling my exposure will be done, if all else fails, by exercising the buyback clause.

That's different, what (I think) you are doing is running a PPS pool which is really a proxy to your DGM pool.

But it's probably true that a PPS/DGM hybrid is equivalent to splitting hashrate between a DGM pool and a PPS pool which is a proxy to the same pool.

There are all sorts of things you can do, I'd say chapter 7 is worth a read.

That's the plan. If someone else does a maker bot, I'll still need to operate a balance bot which will execute trades placed by the maker bot.

Your benefit would be the same as in any other market - if the spread is high and the traded price oscillates between the bid and ask, you can buy low and sell high for profit. But for me a maker bot will be even more effective since it can double as a balance bot (and it will improve liquidity, making my offering more attractive).

You can do a convex combination of different reward systems. But preferably each of the component systems should be good - if half of the reward is proportional, the pool will be almost as hoppable as a prop pool.

A PPS/PPLNS hybrid can work. It would be similar in some ways to DGM, which one is better is a matter of taste.

I touched this briefly in section "Hybrid reward methods" (currently 7.3) of AoBPMRS.

Individual miners won't be classified as prop or PPLNS. All shares will enter the same database; when a block is found, the reward corresponding to prop for this data will be calculated, as will the reward corresponding to PPLNS. Every miner will get half of each.

(reserved)

I've done some more calculations regarding the effective leverage of investing in ABSORB bonds (added to OP), and realized that it's too sensitive to the current price, and not very intuitive. Because of this, I don't believe I will issue new ABSORB series.

Instead, I intend to offer POLY, a margin instrument which is riskier for me, but should be easier to use.

tl; dr: Every POLY.10.n bond will have a face value of (X/10)^n BTC, where $X USD is the last trade price of BTC on Mt. Gox, and n is a value specific to the particular bond.

Introduction. This instrument emulates BTC/USD margin trading, acting as an alternative to margin trading platforms and as a substitute while they are inactive. Unlike the margin emulation asset ABSORB, POLY is persistent (in principle the same asset can be used indefinitely) and embodies a much clearer effective leverage, allowing traders to more easily control their position.

Operation. Specific bond offerings will include for example POLY.10.1 and POLY.10.-2. In general, every POLY.10.n will have a face value of (X/10)^n BTC, with $X being the last traded price of BTC on Mt. Gox. Bondholders have the right to sell the bonds back to the issuer at their face value.

Position equivalence. Holding 1 BTC worth of POLY.10.n bonds is locally equivalent to holding (n+1) BTC, in the sense that for small a, an increase of $a in the BTC exchange rate causes an increase of $a*(n+1) in the USD worth of the held bonds. Unlike normal margin trading, holding POLY bonds means profits are immediately reinvested in increasing the position, and losses are immediately liquidated and deduct from the position.

To see this, we first consider some trivial cases. POLY.10.0 bonds always have a face value of 1 BTC, and holding 1 BTC worth of the bonds (1 bond) is equivalent to holding 1 BTC. Investing in such bonds is uninteresting, since one may as well keep the bitcoin.

A POLY.10.-1 bond has a face value of (10/X) BTC, and since each BTC is worth $X, each bond is worth $10 regardless of the BTC price, and thus holding a bond is equivalent to holding no BTC at all. This again is uninteresting because one may as well sell the bitcoin for USD.

A POLY.10.1 bond has a face value of (X/10) BTC. 1 BTC gives you (10/X) such bonds, initially worth $X. If the exchange rate rises to $(X+a), the new face value of the bond is (X+a)/10 BTC, so the value of all (10/X) bonds is 1+a/X BTC, which at $(X+a) per BTC is worth $(X+a)(1+a/X) = $(X+2a+a^2/X) ~ $(X+2a), an increase of $2a, so the position implied by 1 BTC of bonds is indeed 2 BTC (so investing in such bonds is equivalent to taking a long position with 2:1 leverage). With the new price of $(X+a) per BTC, the held bonds are now worth 1+a/X BTC, so the position is now 2+2a/X BTC, meaning that the profits have been reinvested in an even longer position. If the trader wishes to maintain the same position, he will have to sell some excess bonds (or buy new bonds in case of loss).

More generally, a POLY.10.n bond has a face value of (X/10)^n BTC. 1 BTC gives you (10/X)^n such bonds, initially worth $X. If the exchange rate rises to $(X+a), the new face value of the bond is ((X+a)/10)^n BTC, so the value of all (10/X)^n bonds is (1+a/X)^n BTC, which at $(X+a) per BTC is worth $(X+a)(1+a/X)^n = $X(1+a/X)^(n+1) = $X(1+(n+1)a/X+O(a^2)) ~ $(X+(n+1)a), an increase of $(n+1)a.

In particular, holding 1 BTC worth of POLY.10.-2 bonds is equivalent to holding -1 BTC, so starting with USD, buying 1 BTC and using that to buy POLY.10.-2, is equivalent to short selling 1 BTC.

Calling. The issuer has the right to buy back the bonds, at a multiple of the face value which varies according to the specific bond. For POLY.10.1 and POLY.10.-2, the multiple will be 120%.

Termination. If the trade prices from Mt. Gox become terminally unreliable, such as if it ceases operations, the bonds will be bought back for their face value, determined by the agreed upon last meaningful trade price.

Challenges. Assuming, as is likely at this point, that the BTC exchange rate will eventually reach either arbitrarily high or arbitrarily low values, it is easy to see that by buying both a ^1 (long) and a ^(-2) (short) bond, the trader is guaranteed profit, meaning the issuer is guaranteed loss.

This is because of the trader's implicit right to to reinvest all profits in extending his position, regardless of the issuer's ability to hedge the position. Normal margin trading platforms have multiple ways to control this. They can simply refuse to extend the position; they can increase the fee; they can charge interest for taking an unfavorable position, and pay out interest for depositing funds they can use for hedging.

With the way the POLY contract is set up, none of this is possible. The issuer has only two mechanisms to handle this: Calling the bonds when the position becomes intolerable, which is expensive; and using the time value of money to compensate for the future losses. Since there is no way to control interest rates, the effectiveness of this is limited.

Since this is risky for the issuer, the offering price of the bonds will have to include compensation for it. The trader will have to weigh the advantages of an unlimited permission to extend his position (up to the issuer's right to call the bonds at a profit to the trader) against the higher price.

Even so, this is only sustainable with a market maker bot constantly balancing the issuer's position, and with enough trading activity to make sure that increases in the face value of a bond can be matched with traders looking to sell bonds.

Series details. As an initial proof of concept, 200 POLY.10.1 bonds will be offered. POLY.10.-2 should soon follow. The IPO is scheduled for June 14 2012, but bonds will start selling only after the necessary preparations are made.

In the future, higher-leveraged bonds might be offered, and additionally, if the price of BTC changes so that the value of each single bond becomes hard to work with, new series such as POLY.100.n may be offered.

Update: Currently POLY.10.1 and POLY.10.-2 are offered.

POLY.10.1: You can buy at 110%, sell at 106%, target is 400 BTC.
POLY.10.-2: You can buy at 104%, sell at 100%, target is 400 BTC.

In Bitcoinica, the bitcoins are used as collateral to back up any losing positions, so they need complete control over them. If you could withdraw bitcoins on your own, you could simply run away with the money if you lose. Also, Bitcoinica used customer deposits as reserves for trading, so they cannot assign a dedicated wallet per customer.

If customer funds are not put to use but still need to be held, complex scripts might provide a partial solution. A customer-specific address can have a spending condition of (Service private key | Customer private key & Time > X). Then if the service is down without coins being stolen, the customer can still withdraw after a while; and if the service continues to function, they move it to a new address with a different time.

For an eWallet where funds don't need to be tied up, there may be even better solutions, for example (Service key & Customer key | Customer key & Time > X | Service key & Time > Y). This way, the eWallet cannot steal the coins; if it is down or hacked, the coins can be recovered eventually; the customer cannot double-spend, so it can use the service's green address; and the coins are still safe if the customer's key is lost or stolen.

It's just a marketing name for the custom ASIC chip they are developing, as opposed to the FPGA they are using in their current products. How they will deploy this chip in a final product is to be determined - they will probably offer both a small box (with just one or a few chips) and a large one, like they do now.

Don't future contracts have a set term? And don't CFDs rely on future price?

I'm not sure it's equivalent to options. It could seem at first similar to the two parties exchanging options, put and call respectively, at the current price; but with such an arrangement, each party reserves the right to exercise its own option independently, while in the CFD, one option expires when the other is exercised (and a party can force the other one to exercise its option).

Deal (for 1000 BTC) was completed with teek, with O=5.432.

I will issue 5000 new bonds tomorrow, at a price which is to be determined.

In other news, more or less all of the units from the first BFL shipment have arrived; I will post more pictures once Inaba finishes tidying them up.

Update: Bonds have been issued, and offered for 0.37 BTC.

Coupon payment summary for May 2012 (total 0.0186125703 BTC per bond):

I got a few offers while sleeping. I'm currently negotiating with the first one.

With a forum account twice as old as mine and Brendio's reference, sure. But for now it looks like you were beat to it.

I've added some info about timing, it will be flexible with a minimum of 2 weeks, I expect to keep it for a few months.

It can be seen functionally as a futures contract, but to me CFD seems much more descriptive - we agree to pay based on the difference in the BTC exchange rate.

The end time isn't specified in advance, either party can request exercising it when it wants (up to some conditions).

I've added some timing info. I have enough available bitcoins to pay for the difference, especially if we occasionally refresh the contract as I described in an edit (so I don't end up having to pay 500 BTC at once if the price climbs to $10). Presumably the counterparty will also have some bitcoins lying around, but if he needs more time to prepare the payment that can be negotiated.

I need to hedge against a decrease in the price of BTC. With Bitcoinica down and kronos.io not yet finished, I would like to do this with a CFD. If you want to take a long position you can do this deal with me.

The deal will be done only with reputable members, without any collateral offered by either party. No money will be transferred when the agreement starts, and only bitcoins (not USD) will be sent when it ends.

How this works: When we start the agreement, we record the BTC exchange rate $O. When either party wishes to settle the contract, we look at the current exchange rate $C. I will then pay 1000*(1-O/C) BTC (equivalent to 1000*(C-O) USD, which is what you would have gained by buying 1000 BTC and then selling them). If this is negative you pay me 1000*(O/C-1) BTC.

To avoid confusion about the exact time in which the exchange rate is determined, I suggest that we use the Mt. Gox opening rate (as available from bitcoincharts.com) of the day after we decide to start/end the contract.

Duration: The contract will last until one party decides to settle it, which it can do with 2 days notice. This should be enough time to prepare the settlement payment, but a leniency of a few days in actual payment will be allowed. The minimum duration is 2 weeks and the contract can't be ended before this time elapses. These terms are negotiable.

Contract refreshment: To avoid either party being in too much debt to the other, the contract should be occasionally refreshed (for example, whenever the exchange rate moves by $1). To do this, I will pay 1000*(1-O/M) BTC where $M is the current exchange rate, and then M will be assigned as the new value for O. (The exact value of M isn't as critical as the initial O and the final C).

Yes, see for example this. I'm not aware of anything that would make that impossible - AFAIK a transaction just needs signatures from each of the input address, it doesn't know if they are from the same "wallet".

Is this true? I was under the impression that you can (by protocol, if not by existing software) have a transaction with 2 inputs from different wallets by exchanging signatures without exchanging private keys. There are use cases where this would be done with addresses belonging to different people.

I don't know anything about FPGA or what kind of overhead is created by eldentyrell's "DRM", but on the face of it it seems to me that his method is by far superior, and kudos for being able to pull it off.

I'll preface by saying that your proposed method is a general concept not specific to bitstreams; it applies to any situation where an arbitrary piece of information needs to be monetized and the only way to use it is to receive a copy of it (and specifically where the more people possess it, the less valuable it becomes per person). Since this is a very general and common problem I've been interested in solutions to it for a while, but I suspect what you suggest usually doesn't work, and this includes the bitstream problem.

We should acknowledge that once eldentyrell gives the data to Alice, there's nothing essential distinguishing them - they both equally have access to the data, and can sell it to whoever is willing to pay. Possibly people will be more willing to deal with the "true" originator of the bitstream and eldentyrell may have a better distribution platform, but in theory, if eldentyrell expects to receive a total of X from the following bidders, so should Alice.

So Alice has plenty of incentive to defect. She doesn't have that much incentive not to. Not everybody uses this kind of FPGA, so the difficulty increase from propagating the data is minor, and hasn't much effect on Alice's own mining profits.

If you consider the fact that the next recipients can also trade in the data, and the fact that the time scale of propagating data is much faster than that of receiving mining rewards, and follow this to the logical conclusion, you'll find that eldentyrell will be hard-pressed to sell the data for anything at all; nobody will want to buy something that will be plentiful and worthless in a heartbeat.

Even if this somehow works, it creates unnecessary risk in the valuation. Suppose someone develops an equivalent open-source bitstream tomorrow. Then the data will become worthless, and in retrospect, the data is almost worthless today. When Alice buys the data she doesn't know for how long it will have added value, so she's basically gambling. There's nothing inherently wrong with a risky investment but it's still inferior to a product where you pay exactly what it is worth. With a cut taken by the creator this is what happens - as long as his product creates value he receives a reward proportional to the created value, when it no longer does he's no longer rewarded.

PS the Shapley value for the cut is 50% of the difference, and eldentyrell would be well within his right to charge that. Taking only 20% is basically him being nice.

Yes, the block reward will decrease and the difficulty will increase, the question is how much. As with most other investments, nobody knows exactly what the reward will be and the investors are those who believe this will be profitable taking everything into account. Different people will have different evaluations of the situation.

As an extremely simplified model you can consider what happens if the difficulty remains the same forever and the block reward diminishes. A quick calculation shows that in this case 1MH/s will generate 1.04145 BTC over its lifetime.

Now lets assume that the BTC exchange rate remains fixed, while difficulty increases by a factor of 2 every 2 years due to hardware advances. When the block reward halves it will also necessarily have a negative effect on the difficulty - my guess is a factor of 2^(1/3) decrease for every halving. Taking all this into account, the lifetime reward per MH/s is 0.421304 BTC. Maybe the difficulty will climb faster due to some low-hanging fruit such as ASIC, maybe not. Let's just say that half a year ago some people expected the difficulty to soar due to the BFL products, but so far that didn't exactly happen.

Changes in the BTC exchange rate also complicate the dynamics. Difficulty follows price with some lag, so a price rally increases USD-denominated profits, but with a different profile than direct BTC investments.

The bottom line is that if you think mining bonds are currently overvalued, you shouldn't invest in them, and maybe even try to short them.

No, but you can just reinvest manually (or with the API).

I think Stephen missed a bit what the OP was after on some points, so I'll provide my own answers.

Yes. Confirmed = There is a block which includes the transaction.

Yes. The only way to confirm a transaction is to release a block which acknowledges it. With the first block that includes the transaction you will have 1 confirmation.

No. If you think of the block chain as a tower of lego blocks, with your transaction being included in one of them, the number of confirmations is the number of blocks above it (including itself).

It will take about an hour, which is one reason why people shouldn't talk about the magical 6 confirmations.

To the first miner. This is to incentivize him to include the transaction in the block; subsequent miners don't have much say on the matter, they automatically confirm it by linking to the previous block.

Take a look at the fees in this block for example. Mostly 0's, then the default fee 0.0005 BTC (equivalent to less than a cent), then some other values.

In most cases it doesn't matter. In some cases 0.0005 BTC can help a lot, without it it can be stuck in low-priority limbo for a while, and sometimes miners reject all fee-less transactions disregarding the fee size. More than that doesn't really help currently.

I don't think anyone would care enough to do this propaganda, the network does just fine currently based on newly minted coins. In the future it will be more interesting.