Some more:

0:26 "anymore" should be two words: "any more"
0:30 after pausing it to write the above line, I saw:



I reloaded the page, but it still stops at that point, with the same error.

I downloaded the video file to watch it in a standalone player. Then:

1:18 "it's not by accident to be here" is ungrammatical. "it's not an accident that you are here" would be better
2:02 "find the combination" - he says it like com-BYE-nation, but it should be com-BI-nation, with a short 'i' sound - think "bit" not "bite".

I've used 'gcc' for as long as I can remember. Years ago I aliased 'bc' to 'bitcoind', then 'dc' to 'dogecoind', so clamd had to be cc really.

(And I know bc and dc are calculators, but I use Python as my command-line calculator, so that's not a problem either).

It appears he doesn't wish to remain anonymous:


So you can deal with him directly. I'm of course willing to escrow trades.

I can also recommend BayAreaCoins as an escrow.

I can reproduce the exact same behaviour. I'll investigate, and fix it if possible. It seems to not be using the private key provided in the signtransaction RPC call.

Thanks for the report.

The problem seems to be related to the fact that signrawtransaction decides whether to use information from the wallet, or from the RPC command arguments. It won't use both.

Here's an example where I make a transaction with two simple inputs. One's private key is in the wallet, and the other's is provided in the RPC command. signrawtransaction is unable to sign it fully:


But if I call signrawtransaction twice, once providing the private key on the command line and once not, it is successful:


Edit2: here I'm able to sign a transaction spending a multisig input (2 of 2) where one key is in the wallet and the other is in $privkey. I had to provide the scriptPubKey which isn't easy to get hold of:


To get the scriptPubKey, I started with the multisig address, 6SA5Wh49HnS12U3zZLvYGdFb9kDXUGx7ye, and did this:


0xa9 is OP_HASH160
0x14 is 20, the length of the script hash in bytes
0x87 is OP_EQUAL

The redeemScript is from here:


I made a pull request to fix this issue: https://github.com/nochowderforyou/clams/pull/194

Now I can sign a 2-of-2 transaction without having to look up the scriptPubKey or the redeemScript for the multisig address:


I do still need to run signrawtransaction twice, since it will still only take private keys from EITHER the wallet OR the RPC parameters, not both at the same time.

Edit3: I thought I made this edit yesterday, but I don't see it now, so I'll make it again...

I made a better pull request which lets signrawtransaction use all available private keys and multisig scripts:
  https://github.com/nochowderforyou/clams/pull/195

I also tagged a new release:
  https://github.com/nochowderforyou/clams/releases/tag/v1.4.12

And so now you can sign your 2-of-2 multisig transaction all at once, using 1 key from the wallet and one in WIF:

Was it something I said?



Unintentional pump is unintentional.

It's been a while since I posted weekly return data.

Here's an update, showing weekly and cumulative returns, for a 1x and a 100x investor:

I was approached today by somebody wanting to buy a large number of CLAMs for BTC.

Does anyone have CLAMs they would be willing to sell in bulk (say 1000 or more at a time) for BTC? We didn't take about price but I'm guessing he'd be willing to pay a little over market price.

Let me know.

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.

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.

I'm already using PoS with CLAM. It makes about 0.2% per day which is nothing to turn your nose up at.


I obviously tried searching before posting, but neither of those searches turns up anything useful. I was asking whether anyone had anything to say about the idea since I wasn't able to find anything using Google. A lot of the results are either saying how p2pool doesn't work with staking, or they're people talking about using p2pool for the PoW half of PoW/PoS hybrid coins. I'm looking to use for a pure PoS coin.

Edit: to fill in the blanks a little, I'm staking CLAM, effectively running a staking pool. I have around 80% of the actively staking coins under my control, and so stake most of the blocks. That's not a great position for a coin to be in, since if I "turn evil" I am in a position to 51% the coin, reversing transactions, shutting out competing stakers, and all that good stuff. The problem is that even though I charge a 10% fee on staking rewards, the pool is so big that it orphans something like 14% of blocks found by competing stakers, just because in the event of a network fork each staker picks their own fork as the "true" one until the next block is found. And so a new staker is better off paying me the 10% fee than solo-staking and paying an effective 14% "orphan fee.

It has been proposed that p2pool could solve this problem, but I'm not convinced and so I'm looking into it. CLAM has a 1 minute target block time, and so I'm assuming the sharechain target time would need to be much shorter than that, which may well mean p2pool isn't a good fit. Is that right? Can I get any feedback about these thoughts?

I usually only need one address at a time, but occasionally I need two. 20 is way more than I have ever needed or can foresee needing.

Is it worth splitting my previous comments up into a bunch of separate github issues, or do the developers read this thread?

So you are borrowing money at a rate of 1.75% per day and trying to make at least 20% monthly from it.

1.75% per day times 30 days is 52.5% monthly. Or if compounded, it's 68.28%. So if you make 20% monthly you won't even be able to pay off the interest.

I'm sure you can find cheaper ways to borrow than paying 50% interest per month, so why don't you?

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.

I used to run a p2pool node a few years back but have lost touch with developments recently. I have some questions:

1) is p2pool still actively developed?

2) where can I find the most active git repository for it?

3) is it feasible to use p2pool with a proof-of-stake coin?

4) did anyone ever try that?

5) if not, what challenges might I face in porting p2pool to a PoS coin?

Thanks!

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 think hiding it is fine. It's an artifact of the initial distribution method.

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.