I don't know much about Tahoe-LAFS, but if there's no built-in incentive to provide storage, I'm guessing there's also no built in verification that you're actually storing what you say you are.

If there's an incentive system for providing p2p storage (which is something I really hope to see), there needs to be a very robust verification scheme, otherwise people will fake it for free money. To me this seems an extremely challenging problem, though probably solvable (I did spend some time thinking of some possible solutions).

Whether we use Bitcoin or OT or both or neither for payments is trivial in comparison.

@kjj Nice strawman you put up there. You're imagining a very limited way to use this.

Whitelisted senders will of course not need to send bitcoins/PoW. This solves the mailing list and some other issues.

Until everyone uses this, of course the receiver will not reject all messages that don't have payment. Rather, it will be used to accept messages that would otherwise be mistakenly spamfiltered, which also means that the spam filter can be a bit more aggressive (because those who really want to send a mail to you can do it by sending payment). Going forward it will start deprioritizing paymentless messages, then warn senders that the recipient wants payment for messages, and only after it's a global standard, reject messages without payment.

Also, "Sending email should be free" is stupid, and the amount of payment under consideration here is for all intents and purposes free.

@organ: I don't really speak R, but as far as I can see, your simulation matches the mean pmf because you simulated the mixture variable I talked about rather than your target quantity. That's also evident in your verbal description of the simulation. But I think I finally understand the source of your confusion.

The variable we are interested in is M="the minimum balance over the next n rounds". Its cmf at point X is the probability that the minimum is at most X, which means that the balance reaches X or lower at some point. So once we find the pmf of M, we can calculate the chance of hitting any X by the area under the curve.

To simulate the pmf, we need of course to make many instantiations of the random process, and add +1 to the empirical weight of the resulting value of M. What is the value of M? The minimum among all the values of the (shifted) cumulative sum. But instead of adding +1 to the minimum, it seems you added +1 (or +1/n after normalization) to all the values in the cumulative sum. If this is fixed you'll get a proper simulation.

Instead of a generative simulation, you can also find the cmf by approximating the process as a simple random walk, and solving (numerically or, if possible, symbolically) the following recursion (in Mathematica syntax):

Using this, I find that f[20, 1000], the probability of going below -1000 BTC (20 blocks worth) in 1000 rounds, is approximately 50.67%.

I think you're forgetting that the spammer will not use a CPU, he will use a dedicated hashing device. Which means that the difficulty will need to match the dedicated device, so a legitimate user can't use his CPU. He will need to use an external service, which adds more overhead and fallibility to the system. With Bitcoin payments, the user will just use whatever Bitcoin solution he's already using.

This is a move that I support, but I think you're too optimistic with respect to demand. Hashcash serves the same purpose (albeit less effectively) and its adoption is very weak. Network effects are strong here, it will only be effective if most people use it.

Of course it needs to be higher than the value of the spam email - on one side you have the costs (Bitcoin, bandwidth if paid, etc.), on the other you have the value of the mail to the spammer. The costs need to be higher than the value to prevent the sending.

I don't think it's going to be a problem, the value of a legitimate email outweighs the cost of propagating a transaction. Even if not there are many possible solutions.

Sounds ok. Though I think the fee for transfer should be less than for a trade.

On that note, I think the fee for trades can be increased. The weak point of GLBSE isn't the fees, it's development/support. If raising the fees can help getting more work done (which I hope it will), I doubt anyone will object. So maybe 1% for trades, 0.5% for transfers?

I agree, except for the part where it's radical. It should have been continuous (allowing maybe 8 decimal places like Bitcoin) from the start, and I don't think it's too late to change that. (Edit: Fees should probably still be in bitcoins. There's no problem with making the trade fees symmetrical in the current system, they can be taken from the buyer's balance based on the trade price.)

Because asset transferring has many, many use cases. It's not just a way to trade assets for bitcoins outside the exchange. rdponticelli has given one great example; another one is borrowing assets (useful for shorting) or gifting them; I have an asset I plan which will simply be impossible to issue at all without transfers (I'm keeping it under wraps for now); many other uses which nobody has yet thought of, and mundane stuff like internal bookkeeping.

If gigavps is content with big players who don't care much about liquidity, sure. But if he wants to also deliver to the many people wanting to invest 1 BTC, he is not going to pay them each individually.

+1.

I'm not sure I completely understand the Goat incident but I'm under the impression there were potential security issues, making it too time-critical for this procedure. But there's no excuse to handling the transfer disabling this way.

Because of this, it would be a good idea to offer an official apology for not having followed this procedure.

DGM has 2 parameters. You can decrease variance at the cost of either operator risk or maturity time. If the decay is too fast you can increase o while keeping c fixed. Of course, then people will need to understand that their payment for mining now will be spread out over the next several blocks.


DGM is perfectly usable by intermittent miners, the average reward is not affected. There will be variance which has mostly a psychological effect (I'm not saying psychological factors shouldn't be considered, only that you shouldn't assume there's anything more than that). If the variance (even with optimal parameters) is too much to bear, go with PPS.


DGM is provably hopping-proof. Block withholding attacks (including lie-in-wait) are still possible, as with any other system.

Asset transfers between accounts have multiple use cases and need to be allowed. I can't stress that enough.

The simplest solution would probably be to charge a fee on transferring assets between users (within a user should be free) based on the last traded price, or the lowest ask.

After more critical issues are fixed, you can develop better ways to handle this.

Not sure if serious. Bitcoin transactions need to include cryptographic signatures and reference outputs recognized by the network as unspent. A modified client that broadcasts invalid transactions will have them rejected.

To further stress the point: Once a Bitcoin client broadcasts a transaction, it's out, there's nothing more it can do so I don't care what it does afterwards. But you are proposing a client that broadcasts market orders, which are a promise to do something if contacted later. If the promise is enforced on the promiser's client it's worthless.

What stops the GUID from being faked?

Didn't think so, just wanted to make sure my query wasn't lost in the fold.

You can use the continuous approximation, and then you're talking about the pdf of the Erlang distribution.

No arguments there. (There could be off-by-one errors but that's immaterial.)

Here is where things start to get horribly, horribly wrong. Both in what you're trying to get, and how you get it.

First, I'll say again: If what you want is the balance after n rounds (which is what the text implies), it is simply (n - Sn/D)*B. That's it. Sn is the number of shares the pool had to pay. Any other derivation is nonsense. So I can only assume you really are trying to figure out the probability that a balance of X will be reached at some point within the first n rounds. Even if this is the case, the above quantity is misguided.

Let's begin with this formula. It is absolutely, and obviously, wrong.

The event X∈(S1, S2, S3, … ,Sn) contains the even X=Sj for any j. Therefore its probability must be at least the probability that X=Sj, which is the pmf of Sj at point X. So the probability must be greater than all the pmfs, so it can't be equal to their average.

The one place where the average of pmfs is meaningful is when you have a mixture variable. For example, if you have a variable Sr which is generated by first choosing a uniform random integer j between 1 and n and then setting it equal to Sj, its pmf will be given by this formula. But such a variable has no relevance whatsoever to the problem at hand.

If you do want to find the probability that X will be in the set, you need to treat this as a union (logic or) of the equalities X=Sj, which can be expanded with the inclusion-exclusion principle. I don't know if the expansion has a nice closed form in this case, I think it's extremely messy because of the dependencies between the Sj's.

So now maybe you can understand why the quantity Pr(X∈(S1, S2, S3, … ,Sn)) is not meaningful. It is not a pmf of anything. The total area under this curve is more than 1, and you can't take areas under the curve for any insight. The events 0∈(S1, S2, S3, … ,Sn) and 1∈(S1, S2, S3, … ,Sn) are not mutually exclusive, so you can't disjunct them by simply adding the probabilities.

You need to define the problem as "what is the probability that the balance will reach X or lower at some point within the first n rounds" (taking into account, obviously, the shift of +B for every round). This is a problem that should be solvable with recursion, for either the exact problem or for an approximation for it.

Not in the least. I'm not following your train of thought because you're not explaining what, why and how you are trying to get.

Probably the CLT at work.

Don't worry, more bonds will be issued in the future. In any case it might be worth it to put up a bid at a reasonable price.

GLBSE doesn't currently allow doing this. You can do it in a person-to-person way; find someone willing to lend some bonds to you, and agree to pay them back at a later time + all coupons in this time period + rental fee. Sell them, and hopefully buy at a lower price to pay back.

The possibility of calling the bonds makes this a bit more complicated, but the exact terms in the contingency can be negotiated with the lender.

Here is the thread, but I don't think there are any active bounties.

Organ, any news about the pdf issue?

Is this enforced by the local client? What stops someone from using a modified client that does not enforce this? (Pretend to be a normal client and broadcast the order, but not execute it when requested)

This is the relatively easier part, it may or may not be possible depending on what MintChip can do. OpenTransactions might help.

By enforcing orders I mean - let's say I put up a bid to buy 1000 bitcoins for $4 each. Someone takes me up on my offer. What makes sure I will go forward with it? Maybe I have no interest at all in buying bitcoins and am just trying to manipulate the market?

The Bitcoin client doesn't mine, it allows you to use Bitcoin. GUIminer allows you to mine.

What are you planning to do with a virtualized environment? If you want to mine you need your hardware to have compute power.

Even if this MintChip thing is any good (TBD), it does nothing to solve the fundamental challenges of making a decentralized exchange - atomic trades (solvable in some contexts), and enforcing orders (to which I don't know of any solution, other than trust networks).

I issued 1000 new bonds at 0.38 BTC, for a total of 2000.

Are you using a different worker for each computer? If not try it. And also try to give it more time to see if it changes, if not I think you should contact slush for support.