Topic: [ANN][CLAM] CLAMs, Proof-Of-Chain, Proof-Of-Working-Stake, a.k.a. "Clamcoin" - page 338. (Read 1151252 times)

Clam trading is "unavailable" on shapeshift.io at the moment. It's probably a good thing for me since I'm not sure I have the willpower to resist selling a few after the price spike of about 20% in the past hour. But I thought I'd point it out in case it's an issue shapeshift isn't aware of.


Thanks!

I don't do any kind of logging of pushed raw transactions, so I can't check the logs to see what went wrong. I'm glad it worked out for you eventually though.

Edit: since the data is intended to be publicly broadcast I don't see any harm in logging it. So I'll do that going forward. That should help to debug this issue if it happens again.

Thanks for the debugging suggestion, I see "true".  I'm quite confident about the validity of my private key as well.  However, I'l go back and double-check all the steps.

EDIT: I re-pasted and now it says "OK".  It's a little strange because I was using the same rawtransaction data sitting there in the terminal window.  I had double-checked the quotes before I posted, who knows?  Something must have been different.  In any case, I'm sure I'l see the balance show up in my JD account shortly.  Thanks again for making the tool to produce the raw transaction so easily.

x0d is the correct one to use now. It was originally x05 but there was a situation where an old just-dice user sent clams to a multisig btc address, so to avoid any future conflicts it was changed so the leading identifier was 6 when converted to base58.

I will look into the other multisig question for you tomorrow, just on my way to sleep.

When you run the big long command, you should get back something like:


If you see "false" instead of "true", it means it wasn't able to find all the private keys it needed, which in your case should just be one of them.

The private key is meant to be in WIF, starting with a 5 for BTC keys. It will also accept the corresponding CLAM, LTC, or DOGE private keys in the same format.

So that's the first thing: did you see "compete" as true or false? If false, you're giving a valid private key, but the wrong one. If true, you're likely copy/pasting incorrectly. You need to copy just the hex value, without the quotes.

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?

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

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.

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.


Yes, that looks perfect.

It will be added next update.

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

Yep, retro style


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

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

Do you happen to have a little banner or anything?

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 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?

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.

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

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

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 [email protected] warning them of a potential scam site.

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:


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.

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