[ANN][CLAM] CLAMs, Proof-Of-Chain, Proof-Of-Working-Stake, a.k.a. "Clamcoin"

[SuperClam]

I added CLAM to my explorer/PoS analyzing site. clam.presstab.pw (once it propogates) or http://www.presstab.pw/phpexplorer/CLAM/
Let me know any feedback. Took some custimization to get clams working

That's quite impressive. Here are my initial observations:
I like that there are charts of address balances over time. Would like to be able to set the range of the x-axis (maybe just links for last day, last week, last month, etc. would do for starters.
When I look here, the 'total change' column is missing the transaction fees. Block rewards are 1 CLAM plus fees, and so are often 1.0001, 1.0002, etc. That's getting rounded to just '1'.
The transaction view doesn't tell me whether each output is spent or not. It would be nice to have that information, along with a link to the spending transaction for each spent output.
This address shows large amounts being 'minted'. Each block only mints around 1 CLAM, but you're showing it minting 9 through 16 CLAMs per transaction.
The rich list takes quite a while to appear. Maybe you're computing it every time the page is hit rather than serving cached results.
The 'claim' feature is nice, but the column displaying the claimed name is too narrow to display much text.
The 2nd biggest address is the CLAM burn address, and shouldn't counted as part of the money supply. Those coins aren't spendable. cf. http://blocktree.io/richlist/CLAM
You might want to remove 'PoW difficulty' from the charts page - CLAM doesn't have any PoW and hasn't since before it was launched to the public.
The PoS difficulty looks better on a log y-axis chart, because at some point the difficulty rose by a factor of a million or so. On a linear y-axis chart all history before that time appears as if the difficulty was zero.
The 'weight' chart would be better relabelled as 'weight spent'. I was hoping for a chart of the network staking weight when I saw "weight", but didn't get it.
The 'coin supply' chart would be better if it plotted the 'active supply' number (see clamd getinfo / clamd getblock). There are 15 million CLAMs still waiting to be claimed, the majority of which will probably never be claimed. The active supply is a more interesting number, since it only counts coins that have ever moved.
It's hard to tell what 'Annual Stake Rate' chart is showing. A splke back around block 75k makes the scale too small for any recent blocks to show up at all. When I zoom in on the chart, the y-axis doesn't rescale. It would be useful if it did.

Definitely still is a lot of work to do. Built it from the ground up, and only really been live for about two weeks. Definitely not made specifically for clams and still yet to be determined how much time I will spend on applications that are specific to one coin. The richlist I do need to work over it queries it live and for clams which has a shit load of addresses it doesn't work well, I will go to a list that updates a few times a day. Annual stake rate shows the Apr of the stake. Small inputs on clams are staking for an obsurd return on value that is why this spike is so large, might see if canvas js has some settings I can tweak in this regard... But however it is in fact that rate. My indexing does not index per output and doing such for clams would not exactly be good for my resources, and adding this to my server out of my own pocket I am not exactly thrilled to add more resources to it.
I will look into the rewards that you think are out of whack and see what I can figure out there. Still plenty of additional features and analysis that I would love to add over the next few weeks.

dooglus is "special"

Believe it or not; that post was a compliment.

Notice the:

That's quite impressive.

He doesn't say that very often

[presstab]

I added CLAM to my explorer/PoS analyzing site. clam.presstab.pw (once it propogates) or http://www.presstab.pw/phpexplorer/CLAM/
Let me know any feedback. Took some custimization to get clams working

That's quite impressive. Here are my initial observations:
I like that there are charts of address balances over time. Would like to be able to set the range of the x-axis (maybe just links for last day, last week, last month, etc. would do for starters.
When I look here, the 'total change' column is missing the transaction fees. Block rewards are 1 CLAM plus fees, and so are often 1.0001, 1.0002, etc. That's getting rounded to just '1'.
The transaction view doesn't tell me whether each output is spent or not. It would be nice to have that information, along with a link to the spending transaction for each spent output.
This address shows large amounts being 'minted'. Each block only mints around 1 CLAM, but you're showing it minting 9 through 16 CLAMs per transaction.
The rich list takes quite a while to appear. Maybe you're computing it every time the page is hit rather than serving cached results.
The 'claim' feature is nice, but the column displaying the claimed name is too narrow to display much text.
The 2nd biggest address is the CLAM burn address, and shouldn't counted as part of the money supply. Those coins aren't spendable. cf. http://blocktree.io/richlist/CLAM
You might want to remove 'PoW difficulty' from the charts page - CLAM doesn't have any PoW and hasn't since before it was launched to the public.
The PoS difficulty looks better on a log y-axis chart, because at some point the difficulty rose by a factor of a million or so. On a linear y-axis chart all history before that time appears as if the difficulty was zero.
The 'weight' chart would be better relabelled as 'weight spent'. I was hoping for a chart of the network staking weight when I saw "weight", but didn't get it.
The 'coin supply' chart would be better if it plotted the 'active supply' number (see clamd getinfo / clamd getblock). There are 15 million CLAMs still waiting to be claimed, the majority of which will probably never be claimed. The active supply is a more interesting number, since it only counts coins that have ever moved.
It's hard to tell what 'Annual Stake Rate' chart is showing. A splke back around block 75k makes the scale too small for any recent blocks to show up at all. When I zoom in on the chart, the y-axis doesn't rescale. It would be useful if it did.

Definitely still is a lot of work to do. Built it from the ground up, and only really been live for about two weeks. Definitely not made specifically for clams and still yet to be determined how much time I will spend on applications that are specific to one coin. The richlist I do need to work over it queries it live and for clams which has a shit load of addresses it doesn't work well, I will go to a list that updates a few times a day. Annual stake rate shows the Apr of the stake. Small inputs on clams are staking for an obsurd return on value that is why this spike is so large, might see if canvas js has some settings I can tweak in this regard... But however it is in fact that rate. My indexing does not index per output and doing such for clams would not exactly be good for my resources, and adding this to my server out of my own pocket I am not exactly thrilled to add more resources to it.
I will look into the rewards that you think are out of whack and see what I can figure out there. Still plenty of additional features and analysis that I would love to add over the next few weeks.

dooglus is "special"

Believe it or not; that post was a compliment.

Notice the:

That's quite impressive.

He doesn't say that very often

Maybe I worded my post poorly, I do very much appreciate all the feedback. It has me searching through my code at this very moment seeing how I can make it more efficient, as well as adjust some of the settings to display the information more properly. For example I have already customized the richlist code (other coins it is fine to calculate on the fly because the address count is not quite so high, and people really do like to see themselves move up this list in real time), the transaction input number so you can see exactly which input is being spent, address zoom, and a few other things as well. Its a work in progress and I do hope to be able to make as many people and coin communities as happy with the data analysis as possible. One thing that seriously has me bothered is the address that is sending outputs on coinstake transactions... I will need to perhaps reindex my db to deal with that.

Feel free to shout out any more bugs or suggestions.

[dooglus]

Maybe I worded my post poorly, I do very much appreciate all the feedback. It has me searching through my code at this very moment seeing how I can make it more efficient, as well as adjust some of the settings to display the information more properly. For example I have already customized the richlist code (other coins it is fine to calculate on the fly because the address count is not quite so high, and people really do like to see themselves move up this list in real time), the transaction input number so you can see exactly which input is being spent, address zoom, and a few other things as well. Its a work in progress and I do hope to be able to make as many people and coin communities as happy with the data analysis as possible. One thing that seriously has me bothered is the address that is sending outputs on coinstake transactions... I will need to perhaps reindex my db to deal with that.

Feel free to shout out any more bugs or suggestions.

I figured you wanted feedback, so I gave it. I'm not good at sugar-coating it. I think your tool is good, and found a bunch of possible ways to improve it. That's all.

I figure with the rich-list you can keep a database table of address balances, and update it each time a new block is added to or removed from the chain. Then you can query it very quickly, esp. if there's an index on the balance column. See how blocktree does it - they have it always up to date and quick to query.

[presstab]

I have the richlist updating every 12 hours at the moment, so it should be temporary patch for the problem until I can redesign a bit of my code. I updated the richlist claim name length to display more text (and prevent user from recording a name that will be cutoff due to max size), and am not displaying the burn address... if its not part of the supply should it be included on a richlist? Up to you guys. Will play around with some of the other code tomorrow.

[tspacepilot]

But I'm not finding the libdb packages which the readme says I should find:

I use libdb5.3++-dev. It complains that the wallet.dat won't be compatible with those from official builds, but I don't care about that.

Edit: and I think I had to run:

  ./configure --with-incompatible-bdb

to tell it that I don't care.

Thanks, Dooglus, make now running

[dooglus]

I have the richlist updating every 12 hours at the moment, so it should be temporary patch for the problem until I can redesign a bit of my code. I updated the richlist claim name length to display more text (and prevent user from recording a name that will be cutoff due to max size), and am not displaying the burn address... if its not part of the supply should it be included on a richlist? Up to you guys. Will play around with some of the other code tomorrow.

I think hiding it is fine. It's an artifact of the initial distribution method.

[Trent Russell]

I'm experimenting with multisig in clams. The first part worked (creating a p2sh and sending clams to it), but the second part (spending the funds) didn't do what I expected. I found a workaround, but it's possible there's a bug in signrawtransaction. Or I made a mistake, of course. Here's more detail:

1. I used "addmultisigaddress" and created a 2-of-2 address: 6WnV4Jhe7iNQLDekwr31h9zeoK1eaDMjAw

2. I sent 0.1 clams there (small enough that it's OK if I lose it). It's txout 0 of the transaction 21db92347e153a6afdddca7f96d444d81d7daa19674ed3101e50de72cb387b19. khashier shows this transaction, but is confused by the multisig address.

3. I used "createrawtransaction" to create an unsigned tx spending this back one of my ordinary addresses.

I had one private key in my wallet and the other on paper. Using "signrawtransaction" it would sign with the one in the wallet, as expected. But then if I tried to sign with "signrawtransaction" giving the other private key explicitly in the command line, it failed. (By "failed" I mean the partially signed transaction wasn't changed.)

To be more explicit, I did this:

Code:

signrawtransaction <unsignedrawtx>
<partiallysignedrawtx>
signrawtransaction <partiallysignedrawtx> [] ['SecondPrivateKey']
<partiallysignedrawtx>

After that I just used "importprivkey" to put the second private key into the wallet, and "signrawtransaction" fully signed the transaction and it worked. If someone knows an easier way I should've been doing this, please let me know.

[cloverme]

I would be very careful with that service. I only just heard of it, but some things just don't add up.

Pretty sure this is nothing but a scam.

The private registration doesn't invoke the warm and fuzzies either.  Everything is hosted from namecheap... website, email, etc.

Domain Name: CLAMSTAKER.NET
Registry Domain ID: 1939815611_DOMAIN_NET-VRSN
Registrar WHOIS Server: whois.enom.com
Registrar URL: www.enom.com
Updated Date: 2015-06-18T03:54:36.00Z
Creation Date: 2015-06-18T10:54:00.00Z
Registrar Registration Expiration Date: 2016-06-18T10:54:00.00Z
Registrar: ENOM, INC.
Registrar IANA ID: 48
Reseller: NAMECHEAP.COM
Domain Status: clientTransferProhibited https://www.icann.org/epp#clientTransferProhibited
Registry Registrant ID:
Registrant Name: WHOISGUARD PROTECTED


I sent an email to abuse@namecheaphosting.com warning them of a potential scam site.

[gjhiggins]

Believe it or not; that post was a compliment.

I restrained an impulse to post a one-liner of my spontaneous applause but now that you bring it up explicitly, I can agree that it's a gem of a post.

Cheers

Graham

[dooglus]

One thing that seriously has me bothered is the address that is sending outputs on coinstake transactions... I will need to perhaps reindex my db to deal with that.

I forgot to address that.

I created those weird staking transactions yesterday as an experiment.

There has been talk recently of porting Bitcoin's p2pool distributed staking pool code to CLAMs. p2pool pays its miners directly in the coinbase transaction, and I was wondering if that was even possible with CLAM. I was aware that there was some kind of check in place to make sure that the input and output were for the same address. It turns out that it's only checking the first (actually second, since the first is always zero) output's address, and so we are free to add extra outputs to pay other miners their reward.

So you won't find too many of those weird transactions in the blockchain so far, but if p2pool ever happens for CLAM you can expect to see lots of them.

I was intending to experiment with multiple input sources in staking transactions too, but didn't do that yet.

Edit: OK, so I tried it and it worked. You can have multiple inputs from different addresses, and multiple outputs to different addresses, just so long as the first input address is the same as the first output address:

http://khashier.com/tx/2d621c452eef8f3f8e260f949488ff015007303d2c04669f619c11a0a766d172

[presstab]

One thing that seriously has me bothered is the address that is sending outputs on coinstake transactions... I will need to perhaps reindex my db to deal with that.

I forgot to address that.

I created those weird staking transactions yesterday as an experiment.

There has been talk recently of porting Bitcoin's p2pool distributed staking pool code to CLAMs. p2pool pays its miners directly in the coinbase transaction, and I was wondering if that was even possible with CLAM. I was aware that there was some kind of check in place to make sure that the input and output were for the same address. It turns out that it's only checking the first (actually second, since the first is always zero) output's address, and so we are free to add extra outputs to pay other miners their reward.

So you won't find too many of those weird transactions in the blockchain so far, but if p2pool ever happens for CLAM you can expect to see lots of them.

I was intending to experiment with multiple input sources in staking transactions too, but didn't do that yet.

Edit: OK, so I tried it and it worked. You can have multiple inputs from different addresses, and multiple outputs to different addresses, just so long as the first input address is the same as the first output address:

http://khashier.com/tx/2d621c452eef8f3f8e260f949488ff015007303d2c04669f619c11a0a766d172

We had quite a lengthy conversation about this on the clams irc channel. I don't believe it quite makes sense, although if you think it does maybe I am missing part of it. Although you can include multiple inputs to the coinstake transaction, only one of them is part of the proofhash (the others are just along for the ride) and with a fixed reward of 1 clam including more inputs to the coinstake transaction would just reduce the return on investment, seeing as it does not alter the proofhash, thus it would actually be detrimental to your returns rather than creating more value. If you were in fact able to change your proofhash based on how many inputs you include this would be a significant security risk because it will allow stake grinding and computation attacks.

Also is the the type of chart that you clammers are looking for? I can also add 'total supply' on the y2 axis, but its boring and makes it sort of ugly.

[Trent Russell]

I added CLAM to my explorer/PoS analyzing site. clam.presstab.pw (once it propogates) or http://www.presstab.pw/phpexplorer/CLAM/

Let me know any feedback. Took some custimization to get clams working

I also find your site impressive.

On the pages for transactions, you could include the "clamSpeech" part. Both my test transactions involving multisig included clamSpeech saying they were tests:

http://www.presstab.pw/phpexplorer/CLAM/tx.php?tx=21db92347e153a6afdddca7f96d444d81d7daa19674ed3101e50de72cb387b19
http://www.presstab.pw/phpexplorer/CLAM/tx.php?tx=92306e09cafe1bb860572047a019cdf4d6136e8e4c7e89fc07be51ded5de9c2a

About multisig addresses, the good news is that you do properly display the transactions (khashier doesn't at the moment). Both the transactions above are listed at:

http://www.presstab.pw/phpexplorer/CLAM/address.php?address=3J5fBSKLSGfPnkY4kVNTp9pMmGx6soN1ek

By the way, in my clam client the multisig address is showing as 6WnV4Jhe7iNQLDekwr31h9zeoK1eaDMjAw. It's the same 20 byte address, so it's not a problem. The difference seems to be whether the leading byte is x05 or x0d.

@Clam experts: What's the leading byte for clam p2sh addresses supposed to be? x05 or x0d?

[presstab]

I also find your site impressive.

On the pages for transactions, you could include the "clamSpeech" part. Both my test transactions involving multisig included clamSpeech saying they were tests:

http://www.presstab.pw/phpexplorer/CLAM/tx.php?tx=21db92347e153a6afdddca7f96d444d81d7daa19674ed3101e50de72cb387b19
http://www.presstab.pw/phpexplorer/CLAM/tx.php?tx=92306e09cafe1bb860572047a019cdf4d6136e8e4c7e89fc07be51ded5de9c2a

About multisig addresses, the good news is that you do properly display the transactions (khashier doesn't at the moment). Both the transactions above are listed at:

http://www.presstab.pw/phpexplorer/CLAM/address.php?address=3J5fBSKLSGfPnkY4kVNTp9pMmGx6soN1ek

By the way, in my clam client the multisig address is showing as 6WnV4Jhe7iNQLDekwr31h9zeoK1eaDMjAw. It's the same 20 byte address, so it's not a problem. The difference seems to be whether the leading byte is x05 or x0d.

@Clam experts: What's the leading byte for clam p2sh addresses supposed to be? x05 or x0d?

I will start adding more CLAM specific things (such as speech display) and the chart I screen shotted above, once my site is linked to from the OP and the website and such in the explorers sections.

[BayAreaCoins]

I also find your site impressive.

On the pages for transactions, you could include the "clamSpeech" part. Both my test transactions involving multisig included clamSpeech saying they were tests:

http://www.presstab.pw/phpexplorer/CLAM/tx.php?tx=21db92347e153a6afdddca7f96d444d81d7daa19674ed3101e50de72cb387b19
http://www.presstab.pw/phpexplorer/CLAM/tx.php?tx=92306e09cafe1bb860572047a019cdf4d6136e8e4c7e89fc07be51ded5de9c2a

About multisig addresses, the good news is that you do properly display the transactions (khashier doesn't at the moment). Both the transactions above are listed at:

http://www.presstab.pw/phpexplorer/CLAM/address.php?address=3J5fBSKLSGfPnkY4kVNTp9pMmGx6soN1ek

By the way, in my clam client the multisig address is showing as 6WnV4Jhe7iNQLDekwr31h9zeoK1eaDMjAw. It's the same 20 byte address, so it's not a problem. The difference seems to be whether the leading byte is x05 or x0d.

@Clam experts: What's the leading byte for clam p2sh addresses supposed to be? x05 or x0d?

I will start adding more CLAM specific things (such as speech display) and the chart I screen shotted above, once my site is linked to from the OP and the website and such in the explorers sections.

I'lll ring a phone and get you on Clamcoin.org.  

Do you happen to have a little banner or anything?

[presstab]

I also find your site impressive.

On the pages for transactions, you could include the "clamSpeech" part. Both my test transactions involving multisig included clamSpeech saying they were tests:

http://www.presstab.pw/phpexplorer/CLAM/tx.php?tx=21db92347e153a6afdddca7f96d444d81d7daa19674ed3101e50de72cb387b19
http://www.presstab.pw/phpexplorer/CLAM/tx.php?tx=92306e09cafe1bb860572047a019cdf4d6136e8e4c7e89fc07be51ded5de9c2a

About multisig addresses, the good news is that you do properly display the transactions (khashier doesn't at the moment). Both the transactions above are listed at:

http://www.presstab.pw/phpexplorer/CLAM/address.php?address=3J5fBSKLSGfPnkY4kVNTp9pMmGx6soN1ek

By the way, in my clam client the multisig address is showing as 6WnV4Jhe7iNQLDekwr31h9zeoK1eaDMjAw. It's the same 20 byte address, so it's not a problem. The difference seems to be whether the leading byte is x05 or x0d.

@Clam experts: What's the leading byte for clam p2sh addresses supposed to be? x05 or x0d?

I will start adding more CLAM specific things (such as speech display) and the chart I screen shotted above, once my site is linked to from the OP and the website and such in the explorers sections.

I'lll ring a phone and get you on Clamcoin.org.  

Do you happen to have a little banner or anything?

Yep, retro style


I'll be throwing the updates on my server tonight hopefully. Thanks for you quick response bayareacoins

[BayAreaCoins]

I also find your site impressive.

On the pages for transactions, you could include the "clamSpeech" part. Both my test transactions involving multisig included clamSpeech saying they were tests:

http://www.presstab.pw/phpexplorer/CLAM/tx.php?tx=21db92347e153a6afdddca7f96d444d81d7daa19674ed3101e50de72cb387b19
http://www.presstab.pw/phpexplorer/CLAM/tx.php?tx=92306e09cafe1bb860572047a019cdf4d6136e8e4c7e89fc07be51ded5de9c2a

About multisig addresses, the good news is that you do properly display the transactions (khashier doesn't at the moment). Both the transactions above are listed at:

http://www.presstab.pw/phpexplorer/CLAM/address.php?address=3J5fBSKLSGfPnkY4kVNTp9pMmGx6soN1ek

By the way, in my clam client the multisig address is showing as 6WnV4Jhe7iNQLDekwr31h9zeoK1eaDMjAw. It's the same 20 byte address, so it's not a problem. The difference seems to be whether the leading byte is x05 or x0d.

@Clam experts: What's the leading byte for clam p2sh addresses supposed to be? x05 or x0d?

I will start adding more CLAM specific things (such as speech display) and the chart I screen shotted above, once my site is linked to from the OP and the website and such in the explorers sections.

I'lll ring a phone and get you on Clamcoin.org.  

Do you happen to have a little banner or anything?

Yep, retro style


I'll be throwing the updates on my server tonight hopefully. Thanks for you quick response bayareacoins

It will be added next update.

There will also be a new Gaming section under the services.

[dooglus]

Although you can include multiple inputs to the coinstake transaction, only one of them is part of the proofhash (the others are just along for the ride) and with a fixed reward of 1 clam including more inputs to the coinstake transaction would just reduce the return on investment, seeing as it does not alter the proofhash, thus it would actually be detrimental to your returns rather than creating more value. If you were in fact able to change your proofhash based on how many inputs you include this would be a significant security risk because it will allow stake grinding and computation attacks.

Right. The only reason I can see for including extra inputs is if you have a bunch of dust outputs and want to combine them. The CLAM client will do this automatically for outputs at the same address that is currently staking, but the protocol will even allow you to combine outputs from different addresses if you want to. I'm guessing the client doesn't do this because it can cause confusion in the accounting system.

Also is the the type of chart that you clammers are looking for?

Yes, that looks perfect.

[dooglus]

I guess p2pool would improve things, as follows:

Currently if you are staking 10 CLAMs, you can expect to stake 1 CLAM every 50 days or so. If there are 100 people staking 10 CLAMs each, they each get that same very irregular reward for staking.

With p2pool, those 100 people can expect to get the same return, but with much lower variance. They each get to stake 0.01 CLAM about twice per day. Their expectation is the same (still 14% lost due to orphans) but their income is much steadier.

Thinking about it more, p2pool works by making shares much easier to find than real blocks. 1000 times easier, say. That way, the guy who currently expects to stake a real block over every 10 days gets to contribute a share 100 times per day, or once every 15 minutes.

But there's a problem with that. If JD stops solo-staking and joins the p2pool network, that's almost all the network weight that will be on p2pool. That means p2pool will be staking about once per minute, and so its members will be contributing 1000 shares per minute. Thos shares need to be added to the share chain. So we have a distributed blockchain adding 16 blocks per second. And we thought the orphan rate was bad now!

So that doesn't work. What can we do to fix it?

Do we make the '1000' vary per miner? So JD still only submits full block solves, bitdice works on shares that are 10 times easier than standard, and the little solo-staking guy works on shares that are 1000 times easier? But isn't there a problem there too? If bitdice is only going to submit shares which are 10 times easier than a full block, surely it will get 100 times as much 'credit' for each share as the small solo miner does for each 1000x easier share he submits. Because their shares are 100 times harder. But what is to stop bitdice from selling their too-easy-to-publish shares to the little guy for him to publish on the share-chain and get credit for? This is probably something that has come up with the Bitcoin p2pool already. I've not been able to find anything very in-depth written about how p2pool works however.

Maybe p2pool only works well for Bitcoin because 1) the blockchain targets 10 minute blocks and 2) not a very large percentage of the hashrate is using it. With CLAM we have neither of these - the blocks are very fast already, and JD would want to use it.

[chriswen]

P2Pool would also probably not work well with Bitcoin if a majority of the Bitcoin network was using it.

[tspacepilot]

Well the why not is that it's an address I was using for cold-storage and since I don't want to keep my savings in an address that I've given away the private key for then I'd have to first move the coins that are there.  I'd do it if CLAM is high, but not worth the trouble if CLAM is low.  But hey, I thought all the addys that were funded were funded at the 4.6 level.  What other level is there?

There's only the 4.6 level. I guess he means if it's only one address maybe it's not worth it, but if it's 100 addresses it is...

You don't have to give away the private key. I recently added a command to Just-Dice that will allow you to 'dig' your CLAM by signing a transaction on an offline machine.

For example, if I type this in the chat box:

/dig 1CrPRwBkwZdEejXusCbh8o35YMN7g7ffKf offline

It tells me:

00:21:40 INFO: run the following on an offline Linux machine, then broadcast the resulting hex value using https://just-dice.com/pushtx
00:21:41 INFO: the addr= part tells it where to send your CLAMs; the default is your Just-Dice deposit address
00:21:41 INFO: when prompted, type your private key:
00:21:41 INFO: echo -n "privkey: "; read privkey; addr=xMYvd61airRrnSUmV2oE1JhEqvzLdFWP7r; val=4.60535574; txid=b45c2a20731f8a88ba980f9cc9ce1d43cd7913d9c26ee3e8002ba1d08676b3de; vout=0; pubkey=76a91482007d41eec3a28b66b1ba726721d95577eb5a7688ac; output='"txid":"'$txid'","vout":'$vout; clamd signrawtransaction $(clamd createrawtransaction '[{'$output'}]' '{"'$addr'":'$val'}') '[{'$output',"scriptPubKey":"'$pubkey'"}]' '["'$privkey'"]'

ie. it gives me a command that I can run on an offline machine that will sign a transaction that (when broadcast) sends the dug up CLAMs to an address of my choosing.

For more information, see this post that I made when I first implemented the command.

Heya Doog, I gave this a try tonight and I ended up getting the message from the just-dice.com/pushtx page "transaction rejected".  This made me wonderi if I gave the private key in the wrong format.  I was using wallet import format (key starts with a 5), is that right?