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

[SuperClam]

Petition Id: 02fde4a4
Link: http://txti.es/02fde4a4


CLAMour Instructions: https://bitcointalk.org/index.php?topic=623147.msg13098673#msg13098673


Chain Analytics


Reasoning:
- It is extremely important that we have thorough and detailed data concerning the block chain and network.
- Detailed and thorough data can be utilized by investors to inform decisions, developers to gain insight and users to identify problems.
- This petition proposes that the client begins to store this important data and make it available to the end user.


Current Network Behavior:
- A small subset of data is available via the 'getinfo', 'getstakinginfo' and other commands.


Proposed Network Behavior:
- The following data should be made available via RPC and UI:
   - Blocks
      - Average block size
      - Average block time
      - Transactions per block
      - Average fees paid per block
   - Transactions
      - Average transaction size(in bytes)
      - Average transaction size(in CLAM)
      - Average fees paid per transaction
      - Average fees paid per byte
      - Average outputs per transaction
      - Average inputs per transaction
      - Average fee paid as a percentage of sent
   - Money Supply
      - Velocity, count of CLAM moved
   - CLAMspeech
      - Average CLAMspeech size in bytes
   - CLAMour
      - Petition identifiers and source links
      - Petition support
   - Mempool
      - Average size of mempool(in bytes)
      - Average size of mempool(in transactions)


Technical Notes:
- This data would be stored 'off-chain' and could thus be optional.
- This data would be stored in reference to the specific block to which it pertains.
- This individual block data could then be iterated to calculate specific results over various time windows.
- This data would be made available via the 'getinfo' command and/or other RPC commands.
- Mempool data would only be relevant to the specific node in question.
- Mempool data would only be relevant during time periods in which the node was actively sync'd.

[Northstar]

Doog was giving me coding 101 advice, though I am sure he has better things to do with his time. Then he fixes a competitor's site without even being asked to do it, even though he could have exploited the shit out of it for personal gain. These kinds of things restore faith in humanity all around. Thank you for being a stand up kinda guy in a sea of greedy assholes, Doog!

While we are on the subject of your technical expertise, what is your opinion on SuperClam's proposal, from a technical point of view? Do you foresee any negative ramifications?

[P-Funk]

Petition Id: 02fde4a4
Link: http://txti.es/02fde4a4

Chain Analytics

Would any of this potentially have a negative impact on the performance of Clamclient?

[SuperClam]

Petition Id: 02fde4a4
Link: http://txti.es/02fde4a4
Chain Analytics

Would any of this potentially have a negative impact on the performance of Clamclient?

Storing a handful of integers once a ~minute shouldn't be horrible.
Complicated queries against that data might be more so, but would be user initiated.

More importantly, under "Technical Notes":

This data would be stored 'off-chain' and could thus be optional.

[dooglus]

** Transaction Fee Pooling to Improve Security

* Petition Reasoning:

To add incentive for nodes to broadcast and share user transactions.

How does this add incentive for nodes to broadcast transactions rather than hoarding them? I don't see it.

Also, you were concerned in IRC that this kind of pooling removes the possibility of a fee market, since individual stakers no longer have an incentive to prioritise transactions based on fee size. I responded that giving out a bigger percentage of the fee pool would solve this.

08:06 < creativeCLAM> So, if you don't do a fee pool, then stakers can include as many bytes as they want into the chain, without cost.
08:06 < creativeCLAM> That is a security issue.
08:07 < creativeCLAM> However, WITH a fee pool, stakers have less incentive to include high-paying transaction with preference, as they are just
                      incrementing the fee-pool, not their personal balance
08:07 < creativeCLAM> ideally, you want a system with limited block space, for bloat security, and to apply market pressure on tx fees.
08:08 < dooglus> you can have an exponential decay type thing:
08:08 < dooglus> the staker gets 50% of the fee, next block gets 30%, 10, 5, ...
08:08 < dooglus> so there's some incentive to include highest fee tx's, but also some incentive not to spam
08:09 < creativeCLAM> Interesting, that comes at the cost of allowing stakers to include bits for "cheaper".
08:09 < creativeCLAM> But, it does somewhat balance the situation.
08:10 < dooglus> yeah, they get it half-price

Did you decide that the fee-market isn't important?

Chain Analytics

- It is extremely important that we have thorough and detailed data concerning the block chain and network.

It strikes me that this isn't a consensus issue, and so you are free to add it to the client any time you like. We don't need to 'vote' on this.

"Patches welcome", as we say... (or even just a github issue would suffice)

For example, I added an RPC call "getsupport" to the client last night. It counts up the support for each petition over a rolling window. I didn't think I had any need to gauge support for the feature, since it isn't consensus-changing.

It looks like this, by the way:

$ clamd getsupport
{
  "window" : 10000,
  "startblock" : 754153,
  "endblock" : 764152,
  "support" : {
    "0000cb61" : 231,
    "02fde4a4" : 3,
    "066b223d" : 3,
    "5afa074c" : 673,
    "7a69a853" : 21,
    "ea06c089" : 298,
    "ff839af9" : 576
  }
}

Doog was giving me coding 101 advice, though I am sure he has better things to do with his time. Then he fixes a competitor's site without even being asked to do it, even though he could have exploited the shit out of it for personal gain. These kinds of things restore faith in humanity all around. Thank you for being a stand up kinda guy in a sea of greedy assholes, Doog!

I earned 3 BTC without having to steal anything too!

Edit: I think Deb may be a little butthurt at your comment. I just noticed this on IRC:

17:27 < Princess> ok, i gotta get off my ass and get work done here
17:27 < Princess> and i need to drag doog away to help me with some of it
17:27 < Princess> i hope humanity will be ok without him for a bit
17:27 < Princess> ffs

While we are on the subject of your technical expertise, what is your opinion on SuperClam's proposal, from a technical point of view? Do you foresee any negative ramifications?

I think it's a reasonable idea, and don't see how anyone could object to it. It's a zero-sum change and smooths the rewards out over time. I'm not sure about the 1% number. I think something higher would help form a fee market.

[Northstar]

** Transaction Fee Pooling to Improve Security

* Petition Reasoning:

To add incentive for nodes to broadcast and share user transactions.

How does this add incentive for nodes to broadcast transactions rather than hoarding them? I don't see it.

Also, you were concerned in IRC that this kind of pooling removes the possibility of a fee market, since individual stakers no longer have an incentive to prioritise transactions based on fee size. I responded that giving out a bigger percentage of the fee pool would solve this.

08:06 < creativeCLAM> So, if you don't do a fee pool, then stakers can include as many bytes as they want into the chain, without cost.
08:06 < creativeCLAM> That is a security issue.
08:07 < creativeCLAM> However, WITH a fee pool, stakers have less incentive to include high-paying transaction with preference, as they are just
                      incrementing the fee-pool, not their personal balance
08:07 < creativeCLAM> ideally, you want a system with limited block space, for bloat security, and to apply market pressure on tx fees.
08:08 < dooglus> you can have an exponential decay type thing:
08:08 < dooglus> the staker gets 50% of the fee, next block gets 30%, 10, 5, ...
08:08 < dooglus> so there's some incentive to include highest fee tx's, but also some incentive not to spam
08:09 < creativeCLAM> Interesting, that comes at the cost of allowing stakers to include bits for "cheaper".
08:09 < creativeCLAM> But, it does somewhat balance the situation.
08:10 < dooglus> yeah, they get it half-price

Did you decide that the fee-market isn't important?

Chain Analytics

- It is extremely important that we have thorough and detailed data concerning the block chain and network.

It strikes me that this isn't a consensus issue, and so you are free to add it to the client any time you like. We don't need to 'vote' on this.

"Patches welcome", as we say... (or even just a github issue would suffice)

For example, I added an RPC call "getsupport" to the client last night. It counts up the support for each petition over a rolling window. I didn't think I had any need to gauge support for the feature, since it isn't consensus-changing.

It looks like this, by the way:

$ clamd getsupport
{
  "window" : 10000,
  "startblock" : 754153,
  "endblock" : 764152,
  "support" : {
    "0000cb61" : 231,
    "02fde4a4" : 3,
    "066b223d" : 3,
    "5afa074c" : 673,
    "7a69a853" : 21,
    "ea06c089" : 298,
    "ff839af9" : 576
  }
}

Doog was giving me coding 101 advice, though I am sure he has better things to do with his time. Then he fixes a competitor's site without even being asked to do it, even though he could have exploited the shit out of it for personal gain. These kinds of things restore faith in humanity all around. Thank you for being a stand up kinda guy in a sea of greedy assholes, Doog!

I earned 3 BTC without having to steal anything too!

Edit: I think Deb may be a little butthurt at your comment. I just noticed this on IRC:

17:27 < Princess> ok, i gotta get off my ass and get work done here
17:27 < Princess> and i need to drag doog away to help me with some of it
17:27 < Princess> i hope humanity will be ok without him for a bit
17:27 < Princess> ffs

While we are on the subject of your technical expertise, what is your opinion on SuperClam's proposal, from a technical point of view? Do you foresee any negative ramifications?

I think it's a reasonable idea, and don't see how anyone could object to it. It's a zero-sum change and smooths the rewards out over time. I'm not sure about the 1% number. I think something higher would help form a fee market.

Lol tell Deb I will sacrifice a Rabbit in her honour also, restoring faith in humanity > cleaning, duh

[smooth]

Petition Id: 02fde4a4
Link: http://txti.es/02fde4a4


CLAMour Instructions: https://bitcointalk.org/index.php?topic=623147.msg13098673#msg13098673


Chain Analytics

Why is it advantageous to have most of this done by the node itself rather than independent chain explorer and analytics type tools, similar to what you get on blockchain.info?

IMO, if it can be done outside the node, it should be done outside the node. The node itself being critical to the functioning of the network. What if a bug is introduced that introduces a crash of every node on the network when some statistics counter overflows? I'm not saying this is likely, but the risk is entirely unnecessary.

Obviously per-node mempool data needs to be collected by each node, but I don't really see the network as even remotely large enough for that to matter. Bitcoin only reached that point recently.

[smooth]

Petition Id: 066b223d
Link: http://txti.es/066b223d


CLAMour Instructions: https://bitcointalk.org/index.php?topic=623147.msg13098673#msg13098673


Transaction Fee Pooling to Improve Security

I do not support due to high potential for various perverse incentives and unintended consequences.

The most natural and robust interpretation of fees is an incentive for block-creators to include truncations in a block (payment for scarce block size). There are better mechanisms to in turn control block size and limit spam, such as a reward penalty. These will naturally pull fees higher via a market mechanism. Trying to go the other direction is akin to pushing on a rope. Reward penalties are especially suitable for CLAM since the block reward is fixed, unlike Bitcoin.

@dooglas you can (and will) still have a fee market if any portion of the fee, even 1%, is kept by the block creator. It will dramatically drive up the price of block space though, probably to levels above the social optimum. Though you still face the issue of hidden fees being paid out of band, and the incentive to do so will be large.

Again, none of this is likely what is intended. Tx fees are a round peg trying to be shoved into a square hole here.

[RHavar]

Petition Id: 066b223d
Link: http://txti.es/066b223d

I don't discount the fact I'm likely missing something. But

As a staker: are you sure I should even bother adding transactions to my block? I mean, the additional money I make for staking a transaction is .. 1% of it's txfees? Hardly seems worth the additional orphan risk? (I guess this can be mitigated by in a block race, by policy you randomly select a block, regardless if it was first seen or not?)


As a sender: If a user is willing to pay a fixed amount for a transaction to be included in a block, it means that if as staker can make 100x as much by accepting a direct payment? So if it ever becomes worth the trouble, the entire fee market is going to move off-chain; probably to centralized services? Already in bitcoin we see some very large mining pools offering prioritization services (which small mining pools can't meaningfuly offer), this seems to have the potential to be 100x worse.

e.g. I can envision a service where you have an account and post a transaction (without tx fees) to it. If they stake the transaction for you, they charge you 50% as much as it would've had to pay on the open network. It would make the staker with the service more money, and would save the sender money, all at the cost of on-network stakers.

[RHavar]

It strikes me that this isn't a consensus issue, and so you are free to add it to the client any time you like. We don't need to 'vote' on this.

There's lot of things that aren't consensus issues, but would be great to have votes on anyway. e.g. Take my earlier idea that in a block-race stakers would randomly select a block (rather than use the first-seen) to minimize the orphan-risk for honest miners who produce big-blocks.  I don't think that's a consensus issue, but seems like it'd be crazy to adopt something without knowing what everyone thought?

(Or another good example is mempool policy in bitcoin (Current vs FSS-BRB, Opt-in RBF, Full RBF) which seems wildly controversial, but with the shilling and censorship around it, it seems impossible to get a feel for support of each)

[smooth]

It strikes me that this isn't a consensus issue, and so you are free to add it to the client any time you like. We don't need to 'vote' on this.

There's lot of things that aren't consensus issues, but would be great to have votes on anyway. e.g. Take my earlier idea that in a block-race stakers would randomly select a block (rather than use the first-seen) to minimize the orphan-risk for honest miners who produce big-blocks.  I don't think that's a consensus issue, but seems like it'd be crazy to adopt something without knowing what everyone thought?

(Or another good example is mempool policy in bitcoin (Current vs FSS-BRB, Opt-in RBF, Full RBF) which seems wildly controversial, but with the shilling and censorship around it, it seems impossible to get a feel for support of each)

Consensus issues don't need to be voted on either, nor is it particularly useful to do so. If there is consensus, it will be obvious. If there is a real need for a vote, there is very likely no consensus.

However, voting on development priorities is useful, as a means for the developers to get some idea what coin owners (somewhat an indicator of coin users) think is important. No one really wants to work on things that aren't wanted.

[dooglus]

However, voting on development priorities is useful, as a means for the developers to get some idea what coin owners (somewhat an indicator of coin users) think is important. No one really wants to work on things that aren't wanted.

I see your point, but I mostly add the features that I want the most. If that happens to correspond with what lots of other people also want then that's nice.

I guess probably more people use the Qt client than the command line but I don't like working on it and so avoid it as much as possible. If lots of people want a better Qt client then I expect one of them will make it happen. If not, I guess it isn't really that important, and if they do that's cool with me - it doesn't affect the client I use, or the network as a whole.

[smooth]

However, voting on development priorities is useful, as a means for the developers to get some idea what coin owners (somewhat an indicator of coin users) think is important. No one really wants to work on things that aren't wanted.

I see your point, but I mostly add the features that I want the most. If that happens to correspond with what lots of other people also want then that's nice.

I guess probably more people use the Qt client than the command line but I don't like working on it and so avoid it as much as possible. If lots of people want a better Qt client then I expect one of them will make it happen. If not, I guess it isn't really that important, and if they do that's cool with me - it doesn't affect the client I use, or the network as a whole.

You're right. A lot of open source gets done (especially when being done by volunteers) because the developer doing it wants the feature. Nothing wrong with that.

[romjpn]

Alright, here we come 1$ !

[ReturnOfTheMAC]

Damn CLAM is doing well this week - just one steady uptrend looking like its about to launch!

[MonsterZeroPrice]

Can anybody imagine to help Jared (dev of digibyte) to get his coin on the right track?

This community has proven to be outstanding. Clams will reach 1 billion market cap no doubt.

[dooglus]

Have a nice day bigfoots. I expect someone to raise this to 0.003, it would be very funny. Anyway, it's not gonna happen, want facts? Here you have one: 0.0025 WAS THE TOP, IT WILL NEVER TOUCH NOR SURPASS IT AGAIN.

I'll just leave this here:

[TheFiendishOne]

How long before my free clams from a wallet import are visible in my wallet?

Am I supposed to import before the client syncs to 100%? Am I supposed to resync?  Did I do this backwards?

[dooglus]

How long before my free clams from a wallet import are visible in my wallet?

Am I supposed to import before the client syncs to 100%? Am I supposed to resync?  Did I do this backwards?

It doesn't matter whether you sync or import first.

You need to be synced up to at least block 10,000 to see your free CLAMs.

And if you import the old privkeys *after* you sync the chain, you need to -rescan before you will see the coins - but I think the import command does that for you.

[TheFiendishOne]

Is it possible that http://clam.makejar.com/ was wrong and I didn't have clams to claim? Rescan didnt work.

**EDIT**

I just moved the blockchain and started a new download.  That worked.

CLAMS FOR ME!