The most well-known PKC algorithm is RSA; the basic idea is moderately simple and you can read about it in the linked Wikipedia article, but you need to understand a bit of number theory, starting with modular arithmetic (if you don't, that should be your first step). There's also a numeric example.

If the secret prime numbers are p and q and their public product is n=pq, then to encrypt a message you take its representation as an integer and raise it to some power, modulo n. Anyone can do that, but most can't take a power and figure out what the base was. The recipient who knows p and q can find the totient phi(n) = (p-1)(q-1) and with some number theory magic use it to invert the power operation.

And for those who use it, it's not synonymous with cryptography; rather, they use cryptography to refer to developing and using cryptographic techniques, cryptanalysis to breaking them, and cryptology to both.

If P=NP then there's a polynomial-time algorithm to break PKC. Whether this has practical relevance is not clear; if the best polynomial has order 20, then it's still impossible.

ThePiachu's point is to create a pool for other miners to participate in, not (or not only) to do the mining himself. Running a mining pool is distinct from running mining hardware, which itself is distinct from developing hardware.

Kudos to ThePiachu but it's not like he invented anything new. The theoretical basis for outsourcing vanity address generation has existed for a while and he just started a project to get the ball rolling. One way or another this will end up as a FLOSS platform so there's not much monetization potential.

Looking forward to the advent of compatible miners.

That's because I was never asked

Shift-PPLNS is a method invented by DrHaribo of BitMinter which I then refined a bit. I've discussed it briefly in this comment as well as section "PPLNS variants" of AoBPMRS.

Shift here refers not to bit-shift, rather to worker shifts. Shares are grouped into shifts, and miners are rewarded for the shares they submitted in last few shifts rather than the last N shares. Since all shares submitted within a shift are equivalent, there's no need to store the individual shares, rather just the total shares submitted per miner per shift (or more accurately the total pB).

By using a gap of 1 shift between work and reward, it also doesn't matter (on average) whether a share is counted as belonging to one shift or the next. So this works in parallel - each pool instance tallies work per shift for the miners connected to it (because of the gap, it is ok to be a little out of sync with the other instances wrt which is the current shift) and then compute rewards after the fact with the summed data.

Shift-DGM is applying the same principles to DGM. I've never actually worked out the details (again, due to lack of interest), but it should work. The idea is that shares will decay only between shifts rather than within a shift, so you can do it in parallel with out-of-sync instances. Within a shift it's a simple tally of the total pB of shares submitted.

PPLNS can work too, but there are a few differences to consider:
1. What most people refer to as PPLNS is the naive variant which isn't completely hopping-proof. There are correct variants but they're slightly harder to implement.
2. PPLNS is potentially more resource-intensive, as it requires a history of shares - DGM only strictly requires keeping track of the score of every miner.
3. DGM can absorb variance, which may or may not be needed or used but it's nice to have the option.
4. In DGM the decay is gradual rather than abrupt, this can be seen as a pro or a con depending on taste.

There's also shift-PPLNS and shift-DGM which work better with a parallel architecture.

Ok, it's going to be easier than I thought. I'll be at home for the next ~10 days, and even in camp I'll have some free time and internet access.

Anyway, I've been away for a week and they change everything. It'll take a while to catch up with everything that's been going on...

SHORT has sold out, but LONG hasn't had a lot of demand. Since I do want to sell them to balance my position, I've reduced their price to 0.62 BTC.

I've put them on sale a few hours ago. Apparently GLBSE clips the ticker symbol in a strange way, until this is sorted out they can be distinguished by their description, the long says "leveraged purchase" and the short says "short selling".

I "believe more" in the short bond when taken as part of my entire portfolio. I need more bitcoins than what I want my BTC position to be; so if I buy bitcoins above and beyond my desired position, I need to simultaneously short them. I used to use Bitcoinica for this, now I hope to do this with issuing excess long bonds. I've also priced them cheaper than the short bonds in relation to the respective baseline value. If there's demand for both bonds I'll issue more of both, the difference will correspond to my target position delta.

Right. For me this acts as insurance against a drop in BTC exchange rate. If long is correct I'll need to pay extra, but it doesn't bother me as much since in this scenario my BTC holdings become more valuable.

Bonds are now being offered, ABSORB.1.4-6.LONG for 0.678 BTC and ABSORB.1.4-6.SHORT for 0.351 BTC. Prices are subject to change.

Good question. A trade will only trigger the bonds if it is reasonably assured that it will not be reversed, for example if a day passes and there is no report of suspicious activity.

Right, I forgot to take into account the effects of the temporal scale of this pool.

In this case the issue will be aborted. By the rules of the contract this will settle the bonds' value, which makes it pointless to issue them.

Maybe so, but still badly needed. I've had a few ideas how to achieve this functionality which might be a bit more "fancy", but also more needlessly complicated.

This is to be finalized, but I think we'll first reach an agreement that Mtgox isn't coming back in the foreseeable future, and in this case, I'll buy all bonds according to a simple algorithmic evaluation of their worth, based on the last trade price (I'll give more details later but if the price is $5.5, I'll buy the long bonds for roughly 0.75 BTC and the short bonds for roughly 0.25 BTC).

I'd like it even better if we had a proper predictions market. Though I had a few other ideas for margin instruments which are more suitable for GLBSE than a predictions market.

If I understand you correctly, yes - the first time there is a trade at at least $6, the long bond becomes entitled for 1 BTC no matter what happens later. The first time there is a trade at at most $4, the bond immediately expires.

It's an approximation which I think would be good for most use cases. It isn't for someone who believes the price will crash to 0 in the middle of the night. But someone who believes in a gradual decline (like the one from $31 to $2) - whether if it is because Bitcoin is going to fail, or because it is currently overvalued and things will get worse before they get better - can buy a short bond, roughly double his bitcoins, and then sell them or reinvest in a new shorting instrument.

I think so. As a matter of general principle, I believe that for every action there is an equal reaction, and that it's impossible to make a bet on a market without it ending up affecting the market itself.

By way of specific mechanism, I as an issuer have a certain position I wish to achieve. If someone buys a short bond, he'll have to buy 0.5 BTC for it, but I will also need to hedge my position by either:
1. Selling 2.5 BTC, or
2. Issuing more long bonds and/or decreasing their price, in an amount sufficient for someone else to buy one more long bond - preventing him from buying 2.5 BTC.

Of course, this is all amortized over many trades, so is more difficult to see on a smaller scale.

Right. It's an approximation designed to answer specific needs with as little overhead as possible - and it relies on other markets in order to ultimately transfer USD in or out.

This doesn't make a lot of sense to me. The smaller the pool, the greater the % lost to hoppers.

Not all transactions, just low-priority ones.

(reserved)

tl; dr: If the BTC price reaches $6 before it reaches $4, every ABSORB.1.4-6.LONG bond will be bought for 1 BTC. Otherwise, every ABSORB.1.4-6.SHORT bond will be bought for 1 BTC.

Introduction. Bitcoinica's suspension of operations has left a void among those in need of buying bitcoins on leverage or selling them short. It was only a matter of time until alternative instruments were to be introduced, in particular by utilizing the GLBSE platform. The ABSORB family of bonds aims to be just that - while conveniently satisfying my own need for this functionality.

Operation. The first series to be issued is ABSORB.1.4-6.LONG and ABSORB.1.4-6.SHORT. Their settlement depends on what happens first: BTC is traded on Mt. Gox at a price of $6 USD (or higher), or at a price of $4 USD (or lower). If $6 comes first, every ABSORB.1.4-6.LONG bond will be bought back for 1 BTC, while ABSORB.1.4-6.SHORT will become worthless. If $4 comes first, every ABSORB.1.4-6.SHORT bond will be bought back for 1 BTC, while ABSORB.1.4-6.LONG will become worthless.

The issue price is TBD but is expected to be around 0.5 BTC for each bond. Buying ABSORB.1.4-6.LONG or ABSORB.1.4-6.SHORT, respectively, is very similar to buying or selling BTC at roughly 5:1 leverage (if the BTC price increases/decreases by 20%, the investment will be doubled/erased).

Series details. Initially, 400 ABSORB.1.4-6.LONG bonds and 200 ABSORB.1.4-6.SHORT bonds will be offered. The IPO will be on May 28th 2012, the hour will depend on my availability (I'll have limited availability during that time).

Baseline value. The baseline value of an ABSORB bond is defined as the expected value of the bond, in USD, under the assumption that the exchange rate follows a driftless exponential Brownian motion, translated to today's bitcoins. For a pair of bonds settled by reaching $L or $H, with the current BTC price being $M, the baseline value of the long bond, in BTC, is

[ln (M/L) / ln (H/L)]*(H/M)

And for the short bond it is

[ln (H/M) / ln (H/L)]*(L/M).

The baseline value will be used as a guideline to choosing the IPO price of the bonds, but the final price will be determined by my own needs.

Termination. The issuer has neither the right nor the obligation to buy the bonds back before they are settled. Bondholders are of course welcome to try to sell bonds on the open market, which is likely to react to any changes in the BTC price.

In extreme external circumstances which render the bond meaningless, such as extended suspension of Mt. Gox (according to which settlement is decided) or GLBSE (through which settlement payment is to be disbursed), the bonds will be bought back for their baseline price, with M being the last traded price on Mt. Gox.

Leverage. Under the assumption that the baseline value accurately reflects the worth of the bond, holding long bonds with a total value of 1 BTC is locally equivalent to holding 1/ln(M/L) BTC (that is, an increase of $0.01 in the exchange rate increases the total USD value of the bonds by $0.01/ln(M/L)). Holding 1 BTC worth of short bonds is equivalent to holding (-1)/ln(H/M) BTC.

It's definitely legitimate and I'm sure it happened many times already. The timestamp needs to be at least the median timestamp of the last 11 blocks.

You should consider making the thread title more descriptive.

Cool (to all the confused observers, we're talking about this).

It's 10**6.