Yeah. They are taking a risk and really I'm shocked to see some of these prices. But it is a free market (other than Nefarios random regulations, more about his newest one later).

I think p would need to be the weighted average price to be fair to the issuer. It will mean that some buyers still lose, if they paid more than p, whereas others would gain, if they paid less than p. Using a weighted average, rather than a simple numerical average, will ensure that amount gained by winners = amount lost by losers and the issuer is no better or worse off.

This makes more sense now

buy back price = p*(1+0.01*x)/1.28,

where p is 1.00 and x is 0

In the event of BST changing the interest rates lower that triggers the event, the bond buy back price would be:

1.00 * (1 + 0.01*0 ) / 1.28 = 0.78125

Am I missing something here?  This will always have the effect of lowering the bond price because in the case of a drop in the BST the bonds will be called at the p*(1+0.01*x)/1.28 buy back price and the bondholder will always lose money on the bond.

You think 1+0.01x would keep the bond price low, p*(1+0.01x)/1.28 is even lower.

Here is a whole table.  The buy back price is in the matrix for its respective p and x value.

...

What would increase the price of the bonds at issuance and thus lower the return to bondholders is if the issuers took on more risk.  The higher the risk then the higher the potential return should be.  The issuers would need to guarantee the daily 0.01 increase in par value up to 1.28 BTC.  If there is a lowering of interest rates by BST then the loss of value by the PPT team would have to be made up with the insurance deposits that PPT keeps.

Other than that I think the current plan is sound.

The wording was intended to be tighter than simply "below expectations".  It is to cover the event where Pirate stops and winds up the whole thing, or changes the interest rate scheme materially so that we cannot pass through the intended 1%/day rate.  It does not give us the right to issue the bonds on day 1 at a premium and then immediately buy them back.  

It is a nice graph. It is per block and not per time though, on the X-axis, so it's basically the same as ours. But the Y-axis is number of shares instead of CDF, and they have a running average for the pool shown in addition to each individual block. Might be an idea adding such an average. Not sure about shares vs. CDF though.


Yeah, I changed most of the database stuff in the pool backend. I put in some stuff to make parallel updates safe and added automatic retries in case a database operation fails.


That's due to parallel database transactions conflicting and one being rolled back and retried. When a database transaction is rolled back everything you did is reset to how it was before the transaction started except sequences. When a number is allocated from a sequence the same number won't be given out again, even after a rollback. Already there are many gaps in the user IDs. Now with the new database code there are gaps in the block numbers. Looks a bit ugly. I think maybe I'll switch to not showing the internal ID. The table is also sometimes too wide, so that may help with that problem. Or is a block ID of some sort useful?


170838 was stale on the NMC side unfortunately. I checked the logs and we received a new namecoin block from the namecoin P2P network 5 seconds before we attempted to create ours. Let's just be glad that was a new NMC block just ahead of ours, and not a BTC block.

170495 and 46281 were created from a single proof of work from kjakman. They were created at the same time, but one had trouble getting registered in the database. It took a full 5 minutes from it was created until it was successfully registered in the DB. I was watching and cursing as the database transactions were being retried.

Also this database code is putting 10x to 20x the load on the database, compared to earlier. While that's not a problem for the server, I don't like it. I am already working on a new solution that should run much smoother. On my test server the load was much lower and conflicting transactions happened very rarely. Back to the drawing board!

Did you check your leased shares count?  Pir8 mentioned a purchase interregnum.  No purchases means check your f/o pool.

Just keep posting (eg. reply to this) to get your post count at 5 or more, and troll the forum for 4 hours.  You'll be out in no time.  I took the day off yesterday to get outta this newbie-jail ;P

Yes painful but they prbly have a good reason