If I understand this correctly, it's worse than I thought.

Let's say I'm the original uploader. I'm keeping the verify-cap (and may or may not keep the file), and at some later time I want to verify that node A is storing the file as he's supposed to. Do I need A to send the entire file to me? Bandwidth is expensive, and this means each verification is expensive. So I can't do it very often, let's be generous and say once a month. So I upload the file to A and pay him. He chooses not to store it, and one month later he fails the verification. What penalty does he have? What recourse do I have? If I pay after the fact, what makes sure I pay? Since it's to a large extent about redundancy, I can choose to pay only in the contingency that I require the download. Also, what stops A from not storing the file, but rather redownload it from another node on each verification? If downloading each time is cheaper than storing it, A can cut costs and I lose the redundancy I paid for. If it's expensive, it also means I pay for the verification more than for the storage.

For the system to make any sense at all verification needs to be cheap. I was thinking some sort of probabilistic test where I quiz on X random bits, if I have a copy that's cheap, and the probability to pass the test without the file (or at least so large a portion of it that he may as well keep the whole thing) is slim. Then I can do verifications more rapidly which limit the room for manipulations. But unless there's some fancy cryptographic way to conduct the test without the entire copy, it still means I need to rely on other nodes to verify each other, and they also need to be incentivized to do that. And there needs to be some sort of conflict resolution (based on a probabilistic model) for times that I'm not around (even if I normally operate a trusted node, it could be down for maintenance or something).

I'll say again - a volunteer platform is entirely different than a monetized platform. When money is involved people will do everything they can to manipulate the system, steal and obtain pay for no work done. There needs to be a system resistant to manipulations, and I'm still not at all convinced Tahoe-LAFS is at that level.

I'm happy for you, but I get spam to my Gmail accounts.

This isn't clear at all. Is the ciphertext known only to the file owner? If so, does this mean that only the owner can verify? And even if everyone can verify, again - what incentive do they have to do this? I don't want a system where the owner needs to continuously operate a node to keep everyone honest. He should be able to upload, pay for storage for X period with Y redundancy, forget about it, let the system keep itself in check, and connect at a later time to download the file as needed. Is that really not a challenge?

Not "overly aggressive". Slightly more aggressive than it could otherwise be.

It is a general rule of machine learning that if you have another feature whose information content outweighs the added model complexity, you can improve your precision and recall. This may be less relevant if spam filters generally deal with black-or-white situations.

The system will only be relevant for unsolicited mail from someone that isn't whitelisted. Ideally, wherever the sender got your email address from, he can also see a note "this receiver uses Mailcoin" (complete with links to easy-to-use instructions for the uninitiated). If the message is important, and he sends it once without getting a reply (or with an indication that the message was spam-filtered), he can try sending again with payment. This can significantly increase how aggressive the spam filter can afford to be without missing out on anything.

You speak of spam as if it's a solved problem. I get spam, I get legitimate mail into my spam folder, and I have some of my own messages classified as spam. The problem is real, and I believe this can go a long way towards fixing it.

I suppose the verifying node will itself need a copy of the file (or the part of the file it's verifying)? Then either the owner of the file will need his own node to store the files and verify (which somewhat defeats the purpose), or he will need to rely on other nodes to quiz each other. What incentive do they have for this, and in case of a conflict, who should be believed? What are the penalties for failure to verify?

Maybe there are already solutions for all of this, and if so it's great. But again, a fully monetized platform is a league of its own in the requirements for a comprehensive verification protocol. As I understand Tahoe-LAFS is not currently a fully monetized platform, so I have my doubts that such a verification protocol has been developed.

I will have a period of unavailability between Apr 12 around 14:00 UTC to Apr 14 around 18:00 UTC. Because of this, it is likely that the coupon payment for block 175391 will be delayed.


Automation is not the problem with betsofbitcoin, it's that it's not a market, it just distributes funds in an arbitrary way. Even someone who knows exactly the probability of an event when the market doesn't can't reliably make a bet with a positive expectation.

I'm not going anywhere near Eligius, I'll think about P2Pool.

Sure. But for the current purpose I would like to know in what way can blockchain verification make less room for fraud.

Everything won't "break down" without malicious intent on my part, and if I had such intention I could exercise it even with a demonstration of hashing power. I can understand that it can show that I have less incentive to run, but this doesn't seem like a strong enough case to me.

A difficulty increase would be beneficial to a hypothetical naked issuer and make it easier for him to fulfill his obligations.

It would of course be detrimental to investors. It's no secret that there is a very real risk that such a bond will not pay out as well as hoped. I want potential investors to have the power to decide for themselves how good is the bond for them. I also have put a lot of thought and effort into issuing this and there are many risks involved, and would like to profit from it. If there's demand, I'll offer at a higher price than what I would have been willing to pay myself.

We're going to have a Bitcoin prediction market, either in GLBSE or elsewhere, with all kinds of bets on difficulty, block timestamps and so on (a prediction market on the time of block 210000 would be cool). I planned to experiment with making a prediction asset on top of the current GLBSE platform, but was talked out of it.

But none of these has the same purity and alignment with real-world conditions as a perpetual asset tied to a given hashrate, which I believe will be the main form in which mining-related speculation and hedging will be done.

It is impossible for PPS payout with a fee to make more than DGM without a fee on average.

If you've recently added new hardware, it means your score hasn't built up yet, so your payment is deferred. If you're 1.5 GH/s and the pool is 413 GH/s, you're really making 0.18 BTC per block, but the 0.08 BTC is delayed a bit.

EDIT: There is always the possibility of an implementation bug that will cause a change in the paid values.

I thought about saying this before, but it seemed pretty banal. In light of Inaba's following comment (and the earlier comment I didn't read), I guess I should have.

But if your stated PPS payments are calculated rather than observed, the above is the correct explanation after all.

I guess. Still doesn't seem like a very intuitive quantity to look at.

Right, the maturity time for future rounds is nonnegative and can be positive, so it has a positive expectation. And that - the average maturity time over the next N rounds - may be of interest to some people.

For an optimal miner it is inconsequential, because he can just leave when the buffer is low. But for a miner that wants to sign up for an extended period of time, it is a useful quantity that can be compared to the maturity time of other pools. The pmf of this average can fairly easily be simulated, and is more useful than the current graphs and IMO can replace them (as long as it is very clear what they represent). I can't think of a closed form for the pmf, but maybe it can be approximated by modeling it as Brownian motion.

I'm quoting something you wrote in another thread, because I still have a hard time grasping your suggested failure mode.

If I'm going to lie, cheat and steal, I can do this even if I proved that I control the hashrate.

If I "disappear" then I've already failed the contract. If I have hardware errors I will still pay on schedule. If I have a medical condition my family will pick up the handling of the bond. If I do anything that indicates I'm going to call the bond, if anything it will create a panic buy since this increases its value.

If I somehow do manage to create a panic sell, I'll need the panic to continue during the month it takes to affect the call price. During which there are 13 coupons payments. If I pay them then I don't see why people would continue panicking, if not then I may as well not pay the calling price at all.

Anything I would do along the lines you suggest would be a massive hit on my reputation. And again, I can do this even if I provably have the hardware.

tl; dr: If you trust that I will fulfill the contract, you should believe me when I say I have hardware, or at least trust that I will not pull any blatant dirty tricks.

All that said, I think that with the first batch of hardware I'll average about 1 block per week. This means that it will take months to demonstrate a given hashrate with any accuracy, during which my mining is suboptimal. Also, since I don't personally have physical access to the hardware, it may be harder to supply the desired proof. I can see what I can do, if I can be made to understand what good that will do, or at least see there is sufficient demand for this that understanding is not required.

PS The first batch of hardware hasn't arrived yet, but it should happen really soon.

Yes, that's what I said, if he compromises the mail account and the coins he can send spam (less than with a payless system), but he can't steal the coins, which are useless for anything except sending mail from this account.

The payment per mail should be less than the value of a legitimate mail, but more than the compute resources required to send mail, and more than the value of a spam mail.

This means that if users keep enough coins in their account to comfortably suffice for day-to-day mail usage, hackers suddenly have a greater incentive to compromise accounts. Or not, depending on the numbers. I guess maybe it can work with direct bitcoin payments after all.

That's the amortized cost. I hope nobody mistakes that for the marginal cost (which is close to 0).

If DGM is implemented as described in the forum or in AoBPMRS, it requires score rescaling if the average fee is changed. If no rescaling is done, it means that people who mine shortly before the change will get on average less than a 1.25% bonus, rather than 1.25% as they were promised. This has no effect on people who mine after the change. I don't think that has any relation with zvs's observations, though.

Another effect, which is normal, is that changing the timescale means that miners have a new equilibrium score, which takes some time to build up to. This can cause a reduction in immediate payments, which is compensated by a higher later payment. Edit: On second thought, this effect doesn't happen on the global level. It happens per miner when the overall hashrate changes.

But from a casual examination, it looks like what zvs refers to as "messed up payments" is not related at all to the parameter change. The total reward of a block depends on the luck of several previous blocks. (This is the result of cashing out previous score, it has no affect on the profitability of mining new shares). It's possible that there were a few lucky rounds before block 87, causing a reduced total payout which slowly builds up back to the equilibrium.

The what has been clear for some time.

As for the why - you only need to provide a clear, verbal, unambiguous description of what you are trying to find. In the second part that is fairly clear and as far as I can tell you have a simulation that serves the purpose (you get the cmf of M, from which you can obtain the pmf if you want). In the first part it looks like you just took a bunch of numbers and mashed them together for no reason. The solution as far as I can see is to just remove the first part.

EDIT: It's actually easy to give a verbal description of the first graphs. The one with the cusp is a graph of "the average % of rounds that end with a balance of exactly X", and the accumulated area under it is "the average % of rounds that end with a balance of at most X". (eg, if there are 1000 rounds and 300 of them end with a balance less than -1000 BTC, the value of the variable will be 0.3 - and the graph lists the average of this over all instantiations). Note that as described these are not a pmf and cmf, though they can be looked at as the pmf of cmf of the mixture variable earlier discussed. And again, what you're looking for is not the average % of rounds that end with at most X, but rather the probability that at least one round ends with at most X.

If I had to take a wild guess, I'd say it's because the tail of the exponential distribution (corresponding to bad luck) is more similar to normal than the head. If that's true, your observation will be different if you take the negative of each shifted geometric variable (so effectively, instead of looking at hitting a low value, you're looking at the probability to hit a high value).

Yes, miners receive transaction fees in addition to the new coins being minted. As cunicula points out, there are doubts that transaction fees alone will be enough in the current system.

If they get access to the bitcoins and take them, it means the payment system just made things worse.

Maybe this can be more robust if we give up on the idea that anyone should receive the coins. For example, there could be an alt "Mailcoin" which has a built in mechanism to convert bitcoins -> mailcoins, and the mailcoins need to be destroyed to send mails. It should also be possible to tie the mailcoins to a specific sender (decided when the bitcoins are destroyed to generate the mailcoins), so they will have no trade value and the spammer can't gain anything by directly stealing them.

Being an asset issuer, I look forward for the day short selling on GLBSE is possible and easy. The possibility to short is a large part of my long-term vision for this asset.

I don't like this at all. Not because there's anything wrong with it, but because you have much better things to do, and because whatever you can do along these lines will not have the same flexibility as direct negotiations between lenders and borrowers.

Just make it possible to buy and sell on margin (and as great as that would be, I don't expect it to happen next week, or next month).

Fees should apply only to transfers between users, not between accounts of the same user.

Oh, I get it. I get jokes

Depending on how this is implemented, it may not be the case that being able to compromise an email account will also mean having access to the bitcoins used to pay for messages. So this may make it much harder for spammers to steal the resources required to send messages.

* The recipient.
* There will be some sort of DNS system that resolves email addresses to Bitcoin addresses. This will be handled automatically by the mail client.
* The transaction will embed a hash of the message.

It looks like https://www.coindl.com/ beat you to it. There are/were other similar services but CoinDL seems to be the best so far.

You should probably think about it some more. "Reaching a balance of X or less at any point" is equivalent to "the minimum balance is at most X", which is the cmf of M. If you find the pmf of M, you can use it to find the cmf. In any case I'm talking about balance rather than debt, but that's only a matter of flipping the sign.

It's just the tallying of the empirical pmf. If I wanted to simulate the probabilities of the results 1-6 on a die roll, I'd have variables num1,... , num6, and I'd add +1 to num1 whenever I roll the die and get a 1. Likewise, you need to tally the number of times each value of M appears. Unless you have a different approach to this?

It's within reason, the model solved with this recursion is not very accurate (and I'm guessing the application of the general theorem also has some error). Maybe a better estimation can be found with a simulation after all, with 100000 iterations of 1000 rounds I get about 50.8% chance of going below -1000 BTC. My code for this is: