Winners may wish to consider reinvesting their earnings in a new long position via POLY. Indeed. I picked some up  Do you plan on having a bot on the Bid side too? The bot is also bidding, you'll notice there's always a bid for 50 bonds at the face value. I'm the massive loser on this and would like to play again:) Thanks.
Soon there will be POLY.10.-2, which works differently but also allows you to take a short position. |
|
|
|
Winners may wish to consider reinvesting their earnings in a new long position via POLY. Sold out! Any plans to issue more? Or the short variety? Sure, all in due time. |
|
|
|
|
This is interesting, but can you clarify what advantages this would have over existing methods such as personal webpages and social networks?
|
|
|
|
it seems that whenever it hits 5.97 Meni sells a bunch ... Really, I want it to hit $6 already so I can get it over with. High: 6.00000 Indeed. ABSORB.1.4-6.LONG has been triggered, and all bonds were bought back for 1 BTC each (the buyback feature worked like a charm on my end, I hope people actually got their coins). Note that if the >=$6 trades are cancelled in the next few days, ABSORB.1.4-6.SHORT will still be eligible. If not they will be bought back for 0 or a token amount. Winners may wish to consider reinvesting their earnings in a new long position via POLY. |
|
|
|
|
The nonce ("random data") is incremented sequentially from 0 to 2^32-1. There's also an extraNonce in the coinbase transaction, which I believe is also incremented sequentially.
Some data is chosen randomly by each miner (such as the payout address of the coinbase transaction) and affects the Merkle root which is also part of the hashed data.
|
|
|
|
it seems that whenever it hits 5.97 Meni sells a bunch ... Really, I want it to hit $6 already so I can get it over with. |
|
|
|
For example: "had W malfunction with mining rig, production will be down for at least X weeks in order to perform Y repairs at Z cost". Insert whatever scenario you want here for W X Y Z variables.
This is one of the reasons why I think deterministic bonds are, where applicable, superior to companies. Issuers of a mining bond can't do that - their entire datacenter can blow up and they will still pay coupons normally (assuming they're honest of course). The price plummets for a couple weeks and then the owner can how execute buy back provisions or buy it outright on the open market.
Re buyback, this is why I think buyback provisions should be sane and not the 105% 7-day average nonsense you see sometimes. Also, ideally the buyback price should be independent of the traded price. This leaves the option of buying, but again this assumes there is anything an honest issuer of a deterministic bond can do to depreciate them (other than issuing more bonds, which is counterproductive if he wants to call them). For companies there is little point in doing this, because they're not committed to anything - they can always close shop and distribute any remaining assets among shareholders. What I'm suggesting is that the bonds being issued should allow the investor to benefit from the rewards.
As I mentioned elsewhere, bonds should be priced cost-side based on the cost of the latest hardware offerings. |
|
|
|
The problem with bonds is that a normal bond market assumes the value of the underlying can change. For example, interest rates can go up or down. Inflation can increase affecting interest rates, etc.
But with BTC, a bond that is tied to a MHash/sec rate puts all the risk on the bond buyer because the underlying (MHash/sec output) is always increasing due to hardware improvements.
Someone who issues bonds on current FPGA hardware will take that money and buy the next generation FPGA hardware, yet the bond holders don't benefit from the new purchase. In fact, bond holders will suffer because the share price will drop as new bonds are issued on the better performing hardware.
It is fundamentally erroneous to issue bonds on existing hardware. I mean, you can of course issue bonds when you have spare capacity, but the basic idea is to use the raised capital to purchase hardware, and to price the bond based on how much the hardware costs and how much you'll have to pay on your own until it arrives (which is a major factor in offerings such as BFL). If the issuer plans to buy new cheap hardware, he can offer the bonds cheaply. And if investors believe there is new cheap hardware around the corner, they should avoid paying too much for a bond. |
|
|
|
if you think you can't differentiate yourself or the average person can keeps lots and lots of machines running effectively
The average person doesn't need to run lots of machines. Just whatever the amount he wants to invest in mining will buy him. Doing something more efficiently than others isn't really differentiation, and can be taken into account in a bond model. If you believe you're more efficient than others, offer your bonds at a lower price (thus being more competitive), knowing that you'll still make a profit. This is like any other commodity where whoever produces it at the lowest cost wins. IMO investors shouldn't play guessing games about the issuer's competence - they take the risk of BTC price and difficulty, the miner should take all other risks because he is the only one in a position to evaluate them. |
|
|
|
|
POLY.10.1 is now offered at 107% of face value. There's a bot that updates prices every 2 minutes.
|
|
|
|
|
I strongly disagree.
IMHO mining bonds are a superior model to mining companies, for reasons I have discussed at some length elsewhere (short version: Mining is a commodity. Anyone can buy hardware and operate it. Some people can do it more efficiently than others, which warrants collecting investments for startup capital and risk-sharing wrt to changes in difficulty and BTC price; but there's not much room for differentiation, thus it is better to have a standard framework for such investments). The popularity of the concept among both issuers and investors seems to support this opinion.
Much more importantly, mining bonds are a different model from mining companies. usagi seems to say "mining bonds do not work the same way as companies, thus this model is broken, dishonest and doomed to failure". Mining bonds are not companies and thus this is not a fair comparison. Both models can coexist peacefully as alternatives which cater to different needs. (We might also have mining companies that short mining bonds to hedge their risks.)
Ultimately, if an investor in a mining bond wants to maintain the value of his stake, he can use the coupons to buy more bonds. This isn't much different than a company that pays less dividends and invests the profits in growth.
Of course, as with any investment, it will only be profitable if the initial purchase price isn't too high. It's up to every investor to decide whether the current traded price is attractive for him.
Wrt to terminology: A bond is a publicly traded fixed-term loan, with predetermined payments. A mining bond is a publicly traded infinite-term loan, with payments that have a predetermined relationship to external mining parameters. I think the name is appropriate, but you can call it however you want.
|
|
|
|
Right, this is because of the changing function, with some support from the continuity approximation.
Let's go to the extreme: Let's say after several rounds we end up with 2 elements, so k=2/N. Then after another round we should end up with 2-2/N) elements which is a bit less, and with additional rounds we converge to 0.
Of course, we cannot actually have a noninteger number of elements. But that's not a problem when we change the function each time. Most functions will map 2 elements to 2 elements; but after enough rounds we eventually stumble upon a function that maps both elements to one.
With a consistent function, this can't happen; either it sends them to 2 elements (which must be the same ones) or it doesn't. If it does then it remains at 2 elements forever without decreasing further.
And this doesn't have to happen when we're at 2 elements; after enough rounds, we've weeded out all elements that are not in the function's cycles, and what we're left with we're stuck with forever. And the set of cycle elements can be very large, though I have no idea just how large.
You've given me an idea on how to analyse the fixed-function case. You're better than me at this stuff, so correct me if I'm wrong. Represent every element as a vertex in a graph. Then, add directed edges between vertices according to how SHA-256 maps elements onto other elements. The final set of cycle elements is all the stuff that is part of a cycle. The question is, how big is this set? I attempted a rough estimate, and was surprised at what I got. The graph can be constructed by building chains/cycles. To begin, pick an element, run it through the random oracle, then add a directed edge between input and output. Then pick the output element, run it through the same random oracle ... etc. This builds up the first chain, and eventually this chain will loop back on itself, creating a cycle. How big is this cycle? Let N be the number of elements. After adding 1 edge, the probability that the chain will loop back on itself is 1 / N. After adding k edges, the probability that the chain will loop back on itself is k / N. Thus the probability that the first chain has k edges with no cycles is: (1 - 1/N)(1 - 2/N)...(1 - k/N) This can be approximated as (1 - k / (2N)) ^ k (as long as k is much smaller than N), and then approximated again as exp(-k ^ 2 / (2N)). Equating this to 0.5 reveals that the first chain, on average, has a length of roughly sqrt(N). The rest of the graph can be constructed by picking an unconnected vertex and running it through the random oracle, building another chain. However, this time, the chain either loops back on itself (creating another cycle) or merges with a previous chain. Very roughly, the second chain has a 1/2 chance of creating another cycle and a 1/2 chance of merging with the first chain (because, its average length should be similar to the first chain's average length). Likewise, the ith chain has a 1/i chance of creating another cycle and a (i - 1)/i chance of merging with any one of the previous (i - 1) chains. The average number of cycles is then 1 + 1/2 + 1/3 + 1/4 + ...; the harmonic series. Even for 2 ^ 128 terms, this is only about 100. My estimate for the size of the final set is: average cycle length * average number of cycles, and is very roughly, 100 * sqrt(N). For SHA-256, this is about 2 ^ 135. That's much lower than I expected! But to get to this, you probably have to go through an insane (like 2 ^ 128) number of rounds. Looks ok, there are a few small issues but they don't matter much. |
|
|
|
No, because the assumptions I made become less true the more rounds are done (maybe they're not even accurate enough after one round). The set of all possible images of SHA256^N becomes smaller for larger N until it converges to a fixed set (which is probably very large). Then SHA-256 is a permutation (one-to-one mapping) on this set. (This is true for every function from a space to itself).
But this is probably because I assumed that each round had its own independent random oracle. The results may be different for a fixed function like SHA-256. Right, this is because of the changing function, with some support from the continuity approximation. Let's go to the extreme: Let's say after several rounds we end up with 2 elements, so k=2/N. Then after another round we should end up with 2-2/N) elements which is a bit less, and with additional rounds we converge to 0. Of course, we cannot actually have a noninteger number of elements. But that's not a problem when we change the function each time. Most functions will map 2 elements to 2 elements; but after enough rounds we eventually stumble upon a function that maps both elements to one. With a consistent function, this can't happen; either it sends them to 2 elements (which must be the same ones) or it doesn't. If it does then it remains at 2 elements forever without decreasing further. And this doesn't have to happen when we're at 2 elements; after enough rounds, we've weeded out all elements that are not in the function's cycles, and what we're left with we're stuck with forever. And the set of cycle elements can be very large, though I have no idea just how large. |
|
|
|
I did a calculation which says that every application of SHA-256 reduces entropy by about 0.5734 bits. I have no idea if that's correct.
Assuming SHA-256 is a random function (maps every input to a uniformly random independent output), you will end up having (on average) (1-1/e)*2^256 different outputs. This indeed means a loss of entropy of about half a bit. Further iterations map a smaller space to an output space of 2^256, and the loss of entropy of each further application drops very quickly. It's certainly not the case that you lose any significant amount by doing 1000 iterations or so. I took it one step further and considered the distribution among the outputs, which is not uniform; the result for the amount of entropy lost is (1/e)*sum(log_2 n / (n-1)!). But this is probably little more than a nice exercise, as SHA-256 is likely too far from random for this calculation to be meaningful. And I mistakenly input ln rather than log_2 to the software, so the value I want really should be 0.827. |
|
|
|
I did a calculation which says that every application of SHA-256 reduces entropy by about 0.5734 bits. I have no idea if that's correct.
Mmmh. Does that mean that sha256 ^N(some 256bit input) for N sufficiently large would always converge to the same value, independent of the actual input. No, because the assumptions I made become less true the more rounds are done (maybe they're not even accurate enough after one round). The set of all possible images of SHA256^N becomes smaller for larger N until it converges to a fixed set (which is probably very large). Then SHA-256 is a permutation (one-to-one mapping) on this set. (This is true for every function from a space to itself). First, do we actually *know* that sha-256 is *not* a one to one mapping on the 256 bit space ?
If it turns out to be, then you've got nothing. I don't know the answer, I'm not a professional cryptographer,
but looking at the code for SHA-256, there doesn't seem to be an obvious dropping of bits within
the transform step itself, but then I am too lazy to analyze it in-depth.
SHA-256, as a cryptographic hash function, aspires to be indistinguishable from random. If it was in fact random, the number of preimages for every 256-bit element would follow the Poisson distribution - about 36% would have no preimage, 36% would have one, 18% two, 6% three and so on. So I'd say it's almost certain that it's not a 1-1 mapping. Very interesting observation, and you're probably correct. Even more interesting would be to find a way to measure if that is indeed the case (even if the verification is in a monte-carlo sense) That's probably as hard as determining whether the function is broken. Finally, what someone said: the likely intent of the team who designed bitcoin was to slow mining down, not to
add a layer of security there.
What could that mean? The difficulty controls the mining rate. If a hash function half as hard would be chosen, the difficulty would double and you'd have the same generation rate. You're right, but then I'm not entirely convinced by the 'this buys use time the day sha-256 gets cracked' either. If that was their concern, why not combine two wildly differing 256-bit hash algorithm and XOR the result ? That probably could work too, but that also doesn't guarantee improves security. Maybe the two hash functions are actually connected in some unexpected way and the XOR is actually weaker than either. SHA-256 itself is multiple iterations of a basic function. I'm guessing it is assumed that the basic function itself is ok and that the more times you apply it, the harder it is to attack. |
|
|
|
I did a calculation which says that every application of SHA-256 reduces entropy by about 0.5734 bits. I have no idea if that's correct. The reason for this sacrifice is almost certainly to prevent cracks in SHA-256 from being immediately translated to an attack on Bitcoin hashing. First, do we actually *know* that sha-256 is *not* a one to one mapping on the 256 bit space ?
If it turns out to be, then you've got nothing. I don't know the answer, I'm not a professional cryptographer,
but looking at the code for SHA-256, there doesn't seem to be an obvious dropping of bits within
the transform step itself, but then I am too lazy to analyze it in-depth.
SHA-256, as a cryptographic hash function, aspires to be indistinguishable from random. If it was in fact random, the number of preimages for every 256-bit element would follow the Poisson distribution - about 36% would have no preimage, 36% would have one, 18% two, 6% three and so on. So I'd say it's almost certain that it's not a 1-1 mapping. Finally, what someone said: the likely intent of the team who designed bitcoin was to slow mining down, not to
add a layer of security there.
What could that mean? The difficulty controls the mining rate. If a hash function half as hard would be chosen, the difficulty would double and you'd have the same generation rate. Arguably, they failed because they didn't foresee the length at which people would
go to mine coins (first GPUs, then FPGAs, then dedicated ASICs).
Of course they foresaw all of this, if not the timing of their advent. Had they realized, they would have added an scrypt-like round to the hash step.
The hash function should be easy to verify - each application should be fast but block generation requires many applications. Choosing a slow hash function would be counterproductive. satoshi encouraged people to mine with gpus, he did foresee this.
Eh. I remember hearing the opposite. I probably remember wrong. I know of one comment Satoshi made about GPUs, and it wasn't an encouragement: We should have a gentleman's agreement to postpone the GPU arms race as long as we can for the good of the network. It's much easer to get new users up to speed if they don't have to worry about GPU drivers and compatibility. It's nice how anyone with just a CPU can compete fairly equally right now.
|
|
|
|
|
The IPO is scheduled for June 14 2012, but bonds will start selling only after the necessary preparations are made.
Due to limitations in the characters allowed in a GLBSE ticker, the bonds are renamed to POLY.10.n.
|
|
|
|
For the less mathematically imaginative, I made a little google spreadsheet "simulation"
You can enter the current exchange rate, amount of BTC to invest and which N to invest in (the yellow fields) and see what happens for price moves.
Great, this can be handy. (you need to make a copy of the spreadsheet to be able to edit using "File -> Make a Copy...")
It seems this option is disabled for outsiders. "Download as" works but is a bit difficult because Google uses a different function name for POW than Excel/OO. If you could either change the privileges, or add another sheet with -1, it would be good. Hm, the next priviledge level would be "allow edit by anyone who has the link", which I don't want to do. What do you mean by "add another sheet with -1" ? I should have said 1, and I was talking about N - have one sheet with N=(-2) and one sheet with N=1. Can someone sanity-check it?
Looks good. It's important to clarify that all USD profits given are assuming that the alternative is to keep USD. This is made somewhat confusing by the fact that the field to enter is "BTC to invest". true. there's 2 kinds of users: those who "think" in USD and invest USD and those who think/invest in BTC (and also want the gains in BTC). I don't think it's 2 kinds of users but rather 2 mental modes that can be employed by the same user as is relevant to what he is trying to figure out at the time - as long as it's clear which is which. The trader doesn't need to physically buy or sell BTC for USD but he needs to know if a $10 profit means "$10 more than if he kept BTC" or "$10 more than if he kept USD". Don't really know how to fix this. I put a text ("this assumes you sell the bonds and exchange the BTC for USD") above the "USD Value" and "USD Gain" columns. Does this clarify enough?
I'd do the following: 1. Put the text "Assuming the alternative is keeping USD" above "USD gain". 2. Not put anything above "USD value". 3. Put the text "Assuming the alternative is keeping BTC" above "BTC gain". |
|
|
|
Meni, I admire you: you got 2 things in one package that seldom come together: brains and balls. (the brains to think up such a scheme and the balls to actually offer it)
I have a consistent methodology for these things: Start small, see if it works, then expand. This way I can try out many different ideas without taking excessive risk. Will you provide the market maker bot as well?
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. I think I could provide that using my python code ( https://github.com/molecular/traidor) what exactly would it have to do? - receive trade requests (amount, desired price, sell/buy)
- place order with mtgox
- observe order getting filled
- give back info about executed trade request
? and maybe also: - provide info about liquidity (market depth)?
- provide info about volatility?
- provide info about last trade price?
Based on your description it looks like more of an order placement assistant. What I'd need for now is something that runs every ~1 minute and does the following: - Cancel existing orders on GLBSE
- Collect data on the number of outstanding bonds, the mtgox last price, and some parameters such as my desired position, my net worth, and price volatility.
- Calculate the marginal value for me of each bond (I still need to work out some details with this).
- Place bids on the bonds at a little below the value, and asks at a little above.
- Alert me when my position becomes too unbalanced despite its efforts, so I can balance it by trading manually on Mt Gox, making CFD deals, or in the worst case, making a forced buyback of bonds.
- Send me a daily summary of its status (number of outstanding bonds, position, account balance...)
For now it seems simple enough that it would be better to develop it on my own. Going forward I'll consider getting something more professional made. For the less mathematically imaginative, I made a little google spreadsheet "simulation"
You can enter the current exchange rate, amount of BTC to invest and which N to invest in (the yellow fields) and see what happens for price moves.
Great, this can be handy. (you need to make a copy of the spreadsheet to be able to edit using "File -> Make a Copy...")
It seems this option is disabled for outsiders. "Download as" works but is a bit difficult because Google uses a different function name for POW than Excel/OO. If you could either change the privileges, or add another sheet with -1, it would be good. Can someone sanity-check it?
Looks good. It's important to clarify that all USD profits given are assuming that the alternative is to keep USD. This is made somewhat confusing by the fact that the field to enter is "BTC to invest". Calling. The issuer has the right to buy back the bonds
I don't understand how this works with glbse. Can the issuer forcibly buy back? Yes, GLBSE has a forced buy back feature - The issuer specifies an amount per bond, this is paid to bondholders and all bonds move to the issuer's account. Very useful. I haven't tried it yet but i hope it works. EDIT: Nebulous... will you just "virtually" buy back before the bond goes to negative value as in "liquidate"?
The bond face value is never negative. Any losses cause the investment to shrink, so this is equivalent to margin trading while always being on the allowed margin - any losses cause immediate forced liquidation in the amount required to cover them. This is unrelated to the calling clause. |
|
|
|
Is this the reason for the CFD you recently offered?
No, quite the opposite - ABSORB, forum trust-based CFDs, and POLY are all alternative ways for people to reach their desired position - both me and others - and I'm experimenting to see which one works best. I've started doing this because in general, if I'm bringing capital from the fiat world for Bitcoin investments I want to hedge the exchange rate. Though if POLY ends up scalable and profitable for me on its own, I might also use CFDs to balance the position resulting from it. |
|
|
|
|
Show Posts
