I have decided to take a more active role in ensuring the stability of the PureMining traded price, by placing a bid of 1000 bonds at 0.3 BTC.

I do not commit to keeping it active forever, but I will make an effort not to change this bid without a week of prior notice.

If the bid gets executed I may replenish it at my discretion.

Hopefully this should prevent low-volume selling from drastically affecting the price, which could prevent the fear of a panic sell from fulfilling itself. Ideally, the bid needn't be executed at all - it would inspire enough confidence in the bond value that people will place their own higher bids.

Going forward I will consider using the bot I'm developing for POLY to act as a more active market maker for PureMining, offering tighter spreads for buyers and sellers. One problem is that GLBSE's fee structure makes it technically more difficult to be a market maker.

Even if that's true, offering constructive criticism is not hating. Truly supporting something  is caring enough to try to improve it, nobody needs a yes man.

I am a fan of p2pool, and I've spoken several times about its importance going forward.

I don't recall ever asking/recommending p2pool miners to switch to a different pool, so this is purely your own speculation on what I might be aiming at.

A few remarks I did make about p2pool:
1. The reward system should be looked at to verify that it is truly hopping-proof, and not just "almost hopping-proof" like the naive variant of PPLNS.
2. Some of its suggested advantages are a bit exaggerated, at least at this point - the network isn't going to crumble tomorrow without p2pool.
3. The correct way to use p2pool is not by directly connecting to it, but with a PPS proxy.


[joke] Must be Deepbit. They're also clever enough to hide this connection by paying us to speak ill of the proportional method. [/joke]

@organofcorti Why do you work so hard to provide objective, actionable information to people who would rather bury their head in the sand?

Seriously though, check_status, your comment was completely out of line. OOC has empirically investigated many pools, in many cases he found inadequacies caused by negligence or malice of the operator.

There was a legitimate concern raised about p2pool functioning properly. I learned about it myself some time ago and run some calculations, hoping and expecting to find it well within the acceptable range. What I found was that it is within it, but not well within it.

OOC too was hoping to show how great p2pool is and that there is no problem despite the fear. What he found was that there is weak evidence suggesting a problem. What would you have him do? Hide the information? Lie about it? Or share it so that the relevant people can look into it and possibly fix it (whether it affects the rewards or just the displayed values)? Or even if it is in fact an insolvable problem, being open about it and giving people the chance to make their own decisions in full knowledge of the facts? In fact mechanically presenting the data despite his personal feelings about it is exemplary scientific integrity.

In my day job, whenever I find an inconsistency in our data, people are ecstatic because it means there is a bug that, when fixed, will improve our data considerably. I don't get put down for working hard to show how bad our data is. You should adopt the same mentality.

Right, it's not easy to decide how much to pay, but there is an equilibrium and whoever makes the best job estimating the future wins.

I don't think BFL has much reason to artificially limit supply, demand should be high enough as it is. If they wanted to do that they'd be better off investing in something with a smaller NRE in the first place.

As far as verbal analogies go, a dollar auction has some resemblance but the quantitative difference means not much of the intuition is transferred. A classic example of time-sensitivity is negotiation between two people dividing a pie, where the pie slowly rots/eaten away by someone else while they're arguing. They'd prefer to make some fair division early on rather than constantly making counter-proposals which will end up with each of them getting less.

I think the stated problem is exaggerated. There is an equilibrium where the rig price is so close to the marginal cost that it's not profitable to reduce it further. This can work with 1 manufacturer but the more manufacturers, the more stable the equilibrium. Without fixing prices, no manufacturer can arbitrarily increase prices too much. The equilibrium also shouldn't be too sensitive to the BTC rate - doubling the rate won't cause the rig prices to double, as the difficulty will also increase so they won't generate twice as much revenue.

The healthiest way to converge to this equilibrium when there's just 1 manufacturer which is leaps and bounds ahead of everyone else, is to start by pricing it similar to the competition, and gradually decreasing the price. Based on their announcement BFL don't plan to do it responsibly in this way, which is a cause for some concern.

That said, I will support an initiative to develop an ASIC mining solution which is not by a company who tries to hide the fact that their target market is Bitcoin miners on one hand, or that plans to centrally do all the mining itself on the other.

There's a very simple game-theoretic model for this, and the key factor is time. Someone who buys a rig knows his profits will decline as more rigs are bought, but he hopes to make up for it in the time until this happens. This leads to a natural and steady decline in prices and increase in difficulty.

Let's assume that the current network hashrate is 12 TH/s and BFL starts churning out 1 TH/s rigs at a rate of 1 per day. After X days, there will be a total of X+12 TH/s, so let's assume the profit per day for a rig is 7200*0.999^X/(X+12) (the exponential factor is to account for reward halving etc.) Then a potential buyer at day N expects to receive $\sum_{X=N}^{\infty}7200*0.999^X/(X+12)$. That's a nonelementary expression but the first 10 values are 28410.8, 27810.8, 27257.5, 26744.2, 26265.7, 25817.5, 25396.1, 24998.4, 24622.1, 24265. So a buyer on day 0 can expect to get 28410.8 BTC out of the rig, so that's what he should pay for it, and that's more or less what BFL should charge for it; on the next day it should charge 27810.8 BTC, and so on.

Of course the offered model is extremely simplified but it demonstrates the point. Additional factors such as differing skills and opportunities among potential buyers, uncertainty regarding delivery times, and a bit of irrationality for good measure just enhance the possibility of a stable equilibrium.

Does a Bitcoin node merged-mining Namecoin need to know all Namecoin transactions? I was under the impression that no, he needs only to know the Namecoin block header, and to include a Bitcoin transaction acknowledging it. If that's true, then a miner of a shard doesn't need to know all transactions of other shards to MM them.

Can you explain? I'm not an expert on MM but the way I see it everyone will have all the block headers of all shards, and Merkle branches of special transactions that have to do with MM. If there's a reorg they know about it from the block headers. They don't need to store all transactions of all shards.

There is no way to enforce this. I've added a clause saying this is not an intended use case.

I make an effort to preserve investor value, but there is absolutely no guarantee that the bond will produce a net profit over its lifetime. The market conditions change and the bond price will adapt, whether I'm issuing new bonds or not.

I'm handling this in the fairest way I know and it's impossible to please everyone. If I price it too high I may end up stuck with bonds nobody wants to buy (and lowering the price then would be even more problematic). If I announce a new price without any waiting period there will be resentment among people who have recently bought for higher. By being vague I'm giving people an opportunity to reassess their evaluation and act accordingly - but those people can end up unpleasantly surprised if the issue price turns out to be higher than they expected.

Two important events have happened since the last issue: BTC appreciation to the $6.5 level, and BFL's announcement of their planned ASIC pricing - which should be taken with a good serving of salt, but is still edible.

Anyway, to more directly answer your question - the total coupons paid per bond so far is 0.076534754 BTC (not including errors and compensation). So whether this is a profit or loss really depends on how long one has held the bond and how much he paid for it. The highest price the bonds were offered by me (correcting for compensation) is 0.4 BTC.

It also depends if you're looking at the profit of holding bonds compared to holding BTC or holding USD. Compared to USD I think it will be a profit for everyone who bought from me. BTC price affects the difficulty which affects the BTC price of a mining bond, so the position of holding a mining bond is positive but still lower than directly holding BTC, so people should expect not to profit as much from a BTC rally as if they were holding BTC.

Merged mining.

With my proposal all shards have to recognize each other, so someone can't single-sidedly start a shard.

There can be a direct upgrade path from the current Bitcoin.

If the shards are designed in advance to recognize each other, you don't need to mess with exchange rates and finding someone to trade with you.

All you need is a modification that new coins can be created in a shard, if there is a transaction that destroys coins in another shard and encodes information about the receiving shard and address. So to send coins from shard 1 to shard 2 you destroy them on shard 1, and broadcast a transaction on shard 2 where the input is a reference to the transaction from shard 1, together with its entire Merkle branch.

Nodes will need the entire blockchain of their shard, as well as block headers of all shards, and Merkle branches of every transaction from another shard to theirs. So instead of all transactions, they need (1/N) of transactions plus branches of (1/N) of the transactions. If a transaction is 500B and a Merkle branch is 1.5KB this can be an improvement even without N too large. But they also need N times the block headers.

All shards will be merge-mined with each other.

As a further optimization, instead of all block headers you could have headers of only X% of the shards. Then to send a transaction you need to find someone in the target shard which has the headers for the source shard.

I think I like this idea. And I wonder if the above ideas can be integrated into a more seamless way to shard the blockchain.

Another idea: Maybe it will be good to recommend to people to choose a shard based on geographical location. So local transactions can be done with the least latency and without crossing shards.

I've been asked about bulk/presale discounts. I'm not a fan of these things but I guess it couldn't hurt if done modestly and openly. So here are the terms:

1. Out of the 5000 bonds currently issued, up to 3000 are elligible for preordering.
2. Preorder must be at least 500 bonds.
3. Discount will be 2%. The actual price will be determined and disclosed when the bonds are offered publicly.
4. Preordered bonds will start to be delivered after bonds are publicly put on sale.
5. The preorder agreement isn't binding for either party. The buyer can cancel the order if he's unhappy with the price or for any other reason. I can also back out of the deal, but will only do that with a good reason.
6. If more bonds are preordered than available, buyers will be put on a waiting list. Bonds will be offered to buyers who are still interested in the order they requested the preorder.
7. Preordering is done under the understanding that the bonds will not be immediately resold.
8. Preorder request can be done by either posting in this thread or sending a PM.

Question #1 is a trick question. It's Fermat's little theorem and it was stated by Fermat, but its first known proof is by Euler. I say this after looking it up, but I did pretty good from memory - "Hm, Euler or Fermat? Hey, isn't this thing called Fermat's little theorem? But wait, didn't Fermat have a notorious habit not to prove anything?"

Question #3 is wrong. There are many polynomials whose set of roots equals the set of eigenvalues of a matrix. And you can't sidestep this by saying "by multiplicity" because the algebraic multiplicity can be different from the geometric multiplicity.

Anyway, I don't know how serious you are with this, but these days kids know more than their parents (and more generally age explains only a tiny fraction of the variance in knowledge between people), so trying to deduce age based on knowledge is futile. Basically only people who have recently studied a relevant course have better than average chance at a solution.

I will issue 5000 more bonds early next week.

The price will be somewhat lower than the last issue, to account for hardware advances and the increase in the BTC exchange rate, both of which mean that more hashrate can be bought per bitcoin.

eWallets keep a database of how much they owe to each user. When a user wants to transfer funds to another user, they just update the balances rather than make a Bitcoin transaction.

1. You can have a transaction with multiple inputs and outputs. I don't think you'd get much in the long term, since the load on the blockchain is proportional to the transaction data size. But if you do the transfers internally rather than with Bitcoin transactions, you can avoid them being on the blockchain at all.
2. AFAIK the scripting language allows a transaction to be valid only after block X.
3. With bitcoind they're stored in wallet.dat. If you're making a custom solution you can store them wherever you want. Ideally you'd have multisignature addresses, and put most coins in a cold wallet.
4. If a user gets the private key he can forever spend any coins in the corresponding address. Depending on what you are trying to do, multisignature transactions can help.

Well, if a stale share happens to be a block, it is technically an orphan block, so this is still an increase in the orphan rate, depending on how you count it (maybe orphan blocks which are known to be orphaned when the pool receives them are not counted). What we care about here is the total rewards of the pool, not how they are distributed internally.

Cool. "Proven" should be taken with a grain of salt, as advanced Bitcoin usage (such as oblivious mixing) can involve transactions with multiple inputs which do not belong to the same person.

@Smoovious: I think it's the other way around. A centralized pool should have more latency than solo because first the pool needs to learn about the block, then it has to long-poll you. When solo mining you just need to learn about the block.

The wallet should have those addresses in its buffer. Which means that if you click on "generate new address", the new addresses you'll get are the ones you had before. What they won't have is the label, which you can add.

Do note however that change addresses, generated when you send bitcoins, also count towards the 100 addresses buffer.

You should be able to see the coins in your balance and spend them even without re-generating the addresses.

I've never actually tried this before so reports on your progress will be welcome.

They're already in his wallet, no need to import anything.

According to http://p2pool.info/luck/, 3851 PH were calculated but 3491 PH worth of blocks were found. Assuming difficulty = 1.6M this means 560.4 blocks expected and 508 blocks found. So the likelihood ratio between poisson distributions with mean 560.4 and 508 for 508 found is (508/560.4)^508*exp(560.4-508) ~ 12.5.