Devcoin

[markm]

What is happening with pool.devcoin.org?

I thought it was supposedly merged mining BTC and NMC as well as DVC, but I still only see DVC in my balance waiting to withdraw. I didn't withdraw yet as I was expecting to see figures for the BTC and NMC portions also show up at some point but I see no sign of them yet?

It might be useful if hacking at the code to plan that there could be umpteen more chains to merged mine too, since bitparking hasn't shown any sign yet of adding to its repertoire. (It already merges more than pool.devcoin.org does though which is why I pointed my hashing power there for now, but I hope to see pools competing on number of alt chains they merge... Would be nice to see GRouPcoin (GRP) included somewhere for example, plus of course Martian BotCoins (MBC), United Kingdom Britcoins (UKB), Canadian DIgital Notes (CDN), CZech Bitcash (CZB), General Mining Corp aka Galactic Mining Corp (GMC), General Retirement Funds aka Galactic Retirement Funds (GRF), [Galactic] United Nations Scrip (UNS), bitNicKeLs (NKL) and so on and so on are still waiting in the wings (and meanwhile being traded on the Digitalis Open Transactions Server)...

-MarkM-

[1713897849]

1713897849

[doublec]

Would be nice to see GRouPcoin (GRP) included somewhere for example, plus of course Martian BotCoins (MBC), United Kingdom Britcoins (UKB), Canadian DIgital Notes (CDN), CZech Bitcash (CZB), General Mining Corp aka Galactic Mining Corp (GMC), General Retirement Funds aka Galactic Retirement Funds (GRF), [Galactic] United Nations Scrip (UNS), bitNicKeLs (NKL) and so on and so on are still waiting in the wings (and meanwhile being traded on the Digitalis Open Transactions Server)...

A quick search produced no information on these coins with regards to where to get source, clients, how merge mining capable they are (chain id's etc). Do you have any further details? Where are they used?

[cablepair]

What is happening with pool.devcoin.org?

I thought it was supposedly merged mining BTC and NMC as well as DVC, but I still only see DVC in my balance waiting to withdraw. I didn't withdraw yet as I was expecting to see figures for the BTC and NMC portions also show up at some point but I see no sign of them yet?

It might be useful if hacking at the code to plan that there could be umpteen more chains to merged mine too, since bitparking hasn't shown any sign yet of adding to its repertoire. (It already merges more than pool.devcoin.org does though which is why I pointed my hashing power there for now, but I hope to see pools competing on number of alt chains they merge... Would be nice to see GRouPcoin (GRP) included somewhere for example, plus of course Martian BotCoins (MBC), United Kingdom Britcoins (UKB), Canadian DIgital Notes (CDN), CZech Bitcash (CZB), General Mining Corp aka Galactic Mining Corp (GMC), General Retirement Funds aka Galactic Retirement Funds (GRF), [Galactic] United Nations Scrip (UNS), bitNicKeLs (NKL) and so on and so on are still waiting in the wings (and meanwhile being traded on the Digitalis Open Transactions Server)...

-MarkM-

I am a lot of things but unfortunately a programmer is not one of them, I hired someone to add the statistics but the work is coming along very slowly. If you log into your account you can see the beginnings of the stats being added, but for some reason this person is incredibly slow.

The reason I have not been pushing my programmer is because I recently discovered that poolserverJ does not actually work with more than one aux chains (although its supposed to) and the developer has pretty much disappeared and apparently abandoned the project, pushpool is very inefficient and archaic and not something I want to work with, maybe doublec wants to share his pool back end with me? (I doubt it)

so due to these issues things are kind of up in the air right now, not sure what I am going to do yet.

[markm]

GRouPcoin is in same sourceforge downloads directory as DeVCoin ( http://sourceforge.net/projects/galacticmilieu/files/ ), it was what we used to experiment with before settling on how to implement DeVCoin. It is a perma-flation coin, 50 coins per block forever, with adapative difficulty, timetravel fix (I think anyway; same fixes for adaptive difficulty as DeVCoin and I think those included fix for timetravel) but maybe too low fees depending on what value it ends up trading at. So might need anti-dustspam fixes similar to what was added to DeVCoin to force multi-output transactions to always have a fee and more fee the more outputs. It is MM capable with next ID after DeVCoin, so I think that is 0x0005 as I think DVC was 0x0004.

I only see connections with it occassionally so I think whoever out there is mining it is only doing so from time to time when they happen to think of it.

The others were only ever used with private friend to friend connections, then they moved all their accounting to manual accounting pending merged mining, then with perceived problems even for merged mining startups they have been moving to Open Transactions pending figuring solutions to how to make using blockchain approach affordable and secure. (Mutually exclusive goals maybe hmmm...) So recent plan has been to get transaction volumes built up first before trying blockchain deployment again since without enough actual transactions there won't be much pay for mining them.

-MarkM-

[markm]

Digitalis Open Transactions Server is basically working now, so we are starting to work out implementation details for some DeVCoin-based "corporations" aka "companies" to trade stocks/shares of.

I am making scripts for doing conservative valuations of such companies, basically by adding up the liquidation value of all their assets, but that gets complicated if you try to express the value in terms of just one type of asset since the value of assets relative to each other can change.

For example I can say company X is worth Y devcoins plus Z bitcoins plus A groupcoins plus B united kingdom britcoins plus C martian botcoins plus D general mining corp plus E general retirement fund but unless all the components of its value have relatively stable trading prices how much can that really tell you? Especially in the case of companies who hold much of their value in stocks/shares of other companies. That starts to look somewhat circular, like hmm, what is the value of companies A, B and C if A's portfolio is 10 each of B and C shares, B's portfolio is 10 each of A and C's shares, and C's portfolio is 10 each of A and B's shares? Hmmm.

So far in looking at scenarios with a bunch of investors saying they would put in this that or the other if a company to be formed was going to buy and/or do this that or the other it looks like "companies that are not merely holding companies but actually do something or invest in something other than simply shares of other companies or piles of various currencies" will tend to have a "conservative valuation" less than their IPO release price.

This happens because the "conservative evaluation" looks basically at what it could get right now if it liquidated the company. Thus it takes no account of goodwill, future earnings, privileged positions such as first move or first to market, basically it just adds up all the cash and stocks and bonds and shares and easily-sellable assets. So for example if a company wants to invest in mining rigs, there is an instant appearance of loss of value if they buy new since even new computer gear tends not to have a resale value equal to the bought-new price one paid for it. Similarly if employees are hired they do not always brining in enough money by paycheque time to cover their paycheque, and if the company wants things like post office boxes, hosting, bandwidth, desks, filing cabinets or whatever, just general operating stuff, that too tends to make the initial liquidation value look lower than the IPO initial release price.

Maybe this is not really a problem? Or maybe it is caused by figuring the total capital raised by the IPO will be the total capital of the company? Maybe we are looking at this wrong, and the companies should be figured as first having some amount of capital before IPO time, so that the IPO is only increasing the capital not constituting the whole of it?

Even then though, basically unless the capital brought in is spent only on cash-type things, like actual cash or very-liquid assets that resell for the same price you buy them for, it seems inevitable that an IPO is going to create a company that is not going to be able to be liquidated immediately for the full amount of capital that was put into it.

Maybe the thing to do is simply not shout the actual liquidation value around in marketing the thing?

-MarkM-

[markm]

Okay, I have drawn up an initial stab at a "standard boilerplate stock-type-asset contract":

Code:

<?xml version="1.0"?>
<digitalAssetContract version="1.0">

<entity shortname="GFCstock"
longname="General Financial Corp stock" 
email="markmetson@sourceforge.net"/>

<issue company="General Financial Corp"
email="GFCstock@MI5ius.M5"
contractUrl="http://contracts.MI5ius.M5/GFCstock.contract"
type="share"/>

<currency name="GFCstock" tla="sGFC" symbol="sGFC"
type="decimal" factor="1" decimal_power="0" fraction=""/>

<!-- CONDITIONS -->

<condition name="backing">
  General Financial Corp stock is backed by the assets,
  activities, bylaws, goodwill etcetera of the actual
  Corp, which is registered as a limited liability
  company by the administration of and under the laws
  of the Martians of the planet known as M5. Its offices
  on that planet are located in the city known as MI5ius.
  The company also operates under the name Galactic
  Financial Corp.
</condition>

<condition name="audit">
  General Financial Corp stock is primarily secured by
  the assets of the Corp and, where the Corp operates
  legally under local laws of various civilisations,
  of course by such provisions as local civilisations
  might have regarding ownership of property, defense
  of property and so on. Where what passes for or
  pretends to be local civilisation fails to provide
  such protections, General Financial Corp takes such
  measures itself as it deems prudent under the
  prevailing conditions and circumstances.
</condition>

<condition name="purchase">
  In order to obtain General Financial Corp stock you
  must utilise an Open Transactions server supporting
  the use of said asset.
</condition>

<condition name="redemption">
  Redemption implies failure of the Corp, inasmuch as
  stock is not normally considered a redeemable asset
  but, rather, a tradeable asset. Redemption in the
  event of the failure of the Corp would presumably be
  administrated by the bankruptcy departments of the
  regions in which the company still has any assets
  at the time of the failure / bankruptcy.
</condition>

<condition name="rate">
  It is not yet contemplated that this will be
  dividend-paying stock, thus no rate of payment,
  calculation or release of dividends applies.
</condition>

<condition name="buyback">
  The Issuer reserves the right to buy back all
  outstanding stock, thereby terminating the use of
  this instrument.
</condition>

<condition name="liability">
  The Corp is not liable for any damages use of
  this contract with your software or on your
  computing equiment might cause, nor for any
  loss or inconvenience you might experience due
  to the performance of stock markets, trading
  platforms, brokers, or acts of man woman child
  god or natural force(s) or events. In any event
  liability is limited to the terms and conditions
  specified in this contract.
</condition>

<condition name="mint">
  Float - the total quantity of General Financial
  Corp stock outstanding - is created by a Mint
  account, specially set by the Operator.

  Disbursements from the Mint account are to be made
  on receipt of duly signed and public authorization
  from MI5ius.  All disbursements from the Mint
  account are to be made to the single Currency
  Comptroller account identified by the authorization.

  From time to time, the Currency Comptroller may
  direct the Currency Manager to return General
  Financial Corp stock to the Mint for the express
  purpose of reducing the float. Such directions
  should be ignored; stock, once issued, remains
  in existence until and unless the entire issue
  is disolved, which itself is also not contemplated.

  This issue of stock consists of 100,000 (One
  Hundred Thousand) individual integer units of
  stock, no more and no less. Any not in the
  possession of an entity other than the Corp
  are implicitly and explicitly in the possession
  of the Corp.
</condition>

<condition name="privacy">
  The purchase and trading of General Financial Corp
  stock normally are done on the basis of strong
  privacy. By purchasing or trading this stock you
  agree that your purchase, trading, use, ownership,
  possession and material interest in this stock are
  governed by the laws and customs of the city of
  MI5ius on the planet known as M5 and that such laws
  and customs overrule any local laws or customs any
  civilisation, purported civilisation, government,
  barbarian horde, gang of thieves, outlaws, bandits,
  lawyers, politicians, pirates, thugs, muggers,
  cutthroats, militia, military, police, babysitter,
  parent, nanny or other entity might pretend,
  claim, or promulgate.
</condition>

<!-- KEYS -->

<key name="contract">
- -----BEGIN CERTIFICATE-----
***CERTIFICATE OF ISSUING NYM WILL GO HERE***
- -----END CERTIFICATE-----
</key>

</digitalAssetContract>

This example / sample contract is contemplating being used by/for General Financial Corp.

-MarkM-

[Shattienator]

Is there everything right with the devcoin blockchain?
Starting from block 28000 there is just 2500 generation reward indicated and there are no any other payments to receivers.

Block 28004

Transaction      Fee   Size (kB)   From (amount)            To (amount)
031f84cfa4...   0   0.135      Generation: 2500 + 0 total fees   1APKoqYxg4Yc5uZKZ6nFSsa1MXjWgGJS9g: 2500

and nothing else.

[markm]

Hmm maybe it is not seeing the receiver files. I wonder who is mining those blocks, and whether everyone is accepting other people's blocks and so on...

...I don't see receiver_7.csv in my ~/.devcoin/receiver directory. It should have grabbed that receiver file at some random point before block 28000 actually arrived, but somehow has failed to do so.

When there are not receivers, miners get even less coins than usual if I recall correctly, thus they aren't getting 10% for divvying up the rewards to the receivers, they are getting only 5% because they are not divvying rewards to receivers.

Putting the receivers_7.csv into ~/.devcoin/receiver directory will probably get the rewards flowing again but WFT prevented the file from being grabbed? Maybe the merged mining patch somehow interfered with the get-the-receivers-file code. Maybe even the stuff about thread-safe might be involved, maybe instead of the file-getting clobbering things due to not being thread-safe the threads [prevented the getting of the files to protect the threads against not-thread-safe operations? I dunno. But manually putting the receiver_7.csv in place should give us a couple of thousand blocks to figure it out.

-MarkM-

[Unthinkingbit]

Looking at the three receiver files, I found that they are all slightly different. I think I see why one is different and will try to figure out the whole story by tomorrow. In the meantime, please upload:
https://raw.github.com/Unthinkingbit/charity/master/receiver_7.csv

to galactic files. Hopefully that will fix everything.


EDIT:

By galactic files I mean:
http://galaxies.mygamesonline.org/receiver_7.csv


Edit2:
After I uploaded the latest receiver_7 file, copied from Shattienator's:
 http://devcoinblockexplorer.info/receiver/receiver_7.csv

to my github space, there were then two identical receiver files and devcoin miners started generating the full 50,000 devcoin amount:
http://devcoinblockexplorer.info:2750/chain/Devcoin?count=100

So the problem is solved for devcoin nodes which can download both without problems, but to be on the safe side, still upload:
https://raw.github.com/Unthinkingbit/charity/master/receiver_7.csv

to:
http://galaxies.mygamesonline.org/receiver_7.csv

to add file redundancy.

[markm]

Okay, done. Does this mean that anyone downloading the block chain from scratch will see the blocks from 28000 on that do not match the corrected receiver_7.csv files as invalid? If so maybe we should force the mining nodes to go back over those blocks otherwise they will likely just keep going from where they had gotten to won't they?

Even doing a rescan might only look to update the wallet and not really check the blockchain is correct?

If so then maybe the only way to get mining nodes producing blocks new downloaders will accept will be to have them re-download a blockchain so they will go through the same checking new nodes will go through?

-MarkM-

[Unthinkingbit]

Is there everything right with the devcoin blockchain?
Starting from block 28000 there is just 2500 generation reward indicated and there are no any other payments to receivers.

Block 28004

Transaction      Fee   Size (kB)   From (amount)            To (amount)
031f84cfa4...   0   0.135      Generation: 2500 + 0 total fees   1APKoqYxg4Yc5uZKZ6nFSsa1MXjWgGJS9g: 2500

and nothing else.

Thanks for alerting us to the problem. Because you caught it early only 88 blocks were not big enough.

[Unthinkingbit]

Okay, done.

Thanks.

Does this mean that anyone downloading the block chain from scratch will see the blocks from 28000 on that do not match the corrected receiver_7.csv files as invalid?
..

Since those blocks payout 5% of the default generation they are valid, no rescan or code change is necessary.

[doublec]

Thanks for alerting us to the problem. Because you caught it early only 88 blocks were not big enough.

The advantage for those on a PPS pool - you get paid the full amount per share even though the actual block values were less. Bad luck for the pool though!

[doublec]

explorer.devcoin.org has been dead for a while - is it going to be fixed or replaced?

[Unthinkingbit]

Note, I meant to post this before the post:
https://bitcointalk.org/index.php?topic=34586.msg722688#msg722688

but I passed it over by accident.

Hmm maybe it is not seeing the receiver files. I wonder who is mining those blocks, and whether everyone is accepting other people's blocks and so on...

...I don't see receiver_7.csv in my ~/.devcoin/receiver directory. It should have grabbed that receiver file at some random point before block 28000 actually arrived, but somehow has failed to do so.

Everyone should of seen the receiver_7 file by at the latest block 27,800.

When there are not receivers, miners get even less coins than usual if I recall correctly, thus they aren't getting 10% for divvying up the rewards to the receivers, they are getting only 5% because they are not divvying rewards to receivers.

Yup, without the receiver file it switches over to the 5% mining only payout.

[Unthinkingbit]

After looking at the three different receiver files, here's the background leading to the problem and what may of happened.

At the time the receiver 7 files were being generated, the switchover to merged mining was made, so the file generation was delayed. Also, Cablepair became an administrator at the time of the file generation and he changed his receiver address. Finally, a bit later I decided to change to receiver ordering to make it more fair when there were more than 3,000 receiver lines.

First Mark generated the file, uploaded it, then I uploaded his file. Then Cablepair changed his address, and because time was short because of the delays from merged mining, I generated the files and messaged Mark and Shattienator to upload them from my github. Then Shattienator uploaded the file, then I added Cablepair administration to the bounty file and regenerated the receiver file, then Mark uploaded the now different receiver file. After Mark and Shattienator messaged me back saying they uploaded their files, I tested downloading receiver 7 with receiver.h and because two out of three were the same it worked. Then I posted that the round 7 receiver files were up. Then a bit later I changed the receiver ordering from reversing every odd round to starting at the golden ratio times the round number modulo the number of files. This was done because if there were more than 3,000 receiver lines the reversing every odd round would leave people in the middle of the order with less generation share on average. I tested the new generation ordering, in so doing creating a receiver 7 file with the new ordering. To backup changes, I uploaded all the files in the charity folder to github, at which point the receiver 7 file at my github was different from Mark's and Shattienator's version. So now all three were different. Then at around block 27,000 some devcoin nodes tried to upload receiver 7, they silently failed to upload a new consensus receiver file because the versions were all different. By block 27,980 all the devcoin nodes kept trying at each new block, but kept failing. At block 28,000 they switched over to the round 7 file, because there was no consensus file they defaulted to the reduced mining only generation. Then Shattienator noticed the problem and posted, then Mark posted. Then I saw Shattienator's and Mark's post, tested receiver.h and saw that it said there were not enough identical files, so I uploaded a copy of Shattienator's version just before round 28,088. At that point there were two identical files and the nodes got a majority match and generated accordingly.

To prevent this problem from happening again:

1) The receiver files will be copied from Mark's file, even if file generation is delayed and we're in a hurry.
2) When I test downloading the new receiver file I'll look at the output to check that all the files, not just a majority, are identical.
3) I will be careful to test any changes to the receiver generation on the new receiver file, not the one being downloaded.
4) When there are enough administrators I'll stop being a file administrator and will only check the files.

[markm]

So we need at least one more file-administrator, maybe doublec or cablepair would like to become one?

Or maybe both of them and not retire Unthinkingbit to checking-only until we get yet another file-adminstrator?

I am glad it wasn't a code problem, being as how it was I who applied the merged mining patch.

By the way folks, things are going well with the Open Transactions Server, we could use more people over there actively trading though. Also we are about to start issuing shares of dDVC-based corps, some of you who are receivers might like to pick up some of those shares as soon as they are issued? The main purpose of them is to create value in DeVCoins by having something that should over time be profitable that operates in DeVCoins. Of course people can ask any currency supported by the server in return for shares they wish to sell, so when others start selling them they might be available in any currency, but the initial issue, and the main focus of the corps being issued, is DeVCoin.

The corps can of course invest in other currencies in various ways if they choose to, however it is General Financial Corp aka Galactic Financial Corp that is supposed to focus on that kind of thing, the others do not have  dabbling in other currencies as part of their main concept/focus/intent.

DeVCorp, of course, has as its main mission helping to maintain and increase the value of DeVCoin relative to other currencies. It is probably the one that will try hardest to obtain FPGA hardware to merged mine with so it can use the other currencies merged-mined to buy DeVCoins with to bolster the value of DeVCoins.

-MarkM-

[Unthinkingbit]

So we need at least one more file-administrator, maybe doublec or cablepair would like to become one?

Or maybe both of them and not retire Unthinkingbit to checking-only until we get yet another file-adminstrator?

A few more administrators would be better, but we don't require another file administrator. Cablepair is on standby to be another file administrator, when we get a fifth he'll handle the receiver file, when we get a sixth I'll retire from file administration. I think in the normal course of devcoin/devtome growth we'll get a few more administrators within several months. The different version problem happened only because of a perfect storm of problems, and it just takes one check to notice and fix it.

[cablepair]

thats cool

hey Unthinkingbit

I wanted to tell you this man, I was listening to Science Friday on NPR last friday and they had this scientist on and he was talking about how he wants to make science open source, he said he tried to create a wiki but he does not have time to post articles and he wishes there was something in place to pay people for posting wiki articles!!!

I tried so hard to call in - I wanted to tell them about devcoin/devtome - but I could not get connected, busy busy busy

oh well, it was crazy though everything they were saying devcoin/devtome could answer their problems...

[Unthinkingbit]

explorer.devcoin.org has been dead for a while - is it going to be fixed or replaced?

Block explorers seem do die every several days. It may be necessary to automatically reboot them daily, or something.

There is a remaining 1 generation share bounty for making another devcoin block explorer, when its working it also gets a 1/5 of a generation share each round.