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

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

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.


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:


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:


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.

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":

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

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?

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

---

CLAMour Instructions: https://bitcointalksearch.org/topic/m.13098673

---

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.

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

---

CLAMour Instructions: https://bitcointalksearch.org/topic/m.13098673

---

Transaction Fee Pooling to Improve Security


Petition Reasoning:

• To prevent block creators from executing chain size attacks.
• To make transaction fees earned, and thus block reward, more predictable, constant and smooth.
• To add incentive for nodes to broadcast and share user transactions.

Current Network Behavior:

• Transaction fees are awarded to the node creating/staking the block.
• The block creator essentially pays the fee to themselves, and thus may avoid transaction fees entirely.
• A block creator can potentially attack the network by creating nearly free spam transactions.
• This adds incentive for nodes to not broadcast the transactions it is aware of, in the hope of keeping the fee for blocks they stake.

Proposed Network Behavior:

• Transaction fees are awarded into a 'transaction fee pool'.
• When a block is created, the creator increases the pool balance by the amount of fees paid by transactions in that block.
• When a block is created, the creator awards themselves 1% of the new pool balance and simultaneously reduces that balance by 1%.

Technical Notes:

• An integer would be added to blocks in order to store the amount of CLAM currently in the fee pool.
• The change would be consensus enforced by requiring blocks properly attribute the pool to be valid.
• The change would become active when 95% of staked blocks report a version indicating support for the change.

LOL. Voted.

Thats better than stamp of solvency, EVEN dooglus loses at our casino!

Thank you dooglus for your honesty. We are glad we were able to fix it quickly with a minimal impact. You are welcome back any time

It is still a really nice bounty for such a serious issue. Ofc the 12 BTC would have been excellent, but seems "You don't always win "
Still congraz on the bounty well deserved.

After he fixed the exploit I carried on playing and built the 6.2 BTC up to 12 BTC, then lost it all.

Just as my balance hit zero I got a PM, thanking me for reporting the exploit and saying I could keep whatever I had won using it.

What is it the kids say? fml?

He ended up tipping me 3 BTC which is better than I was expecting. (But worse than the 12 BTC I could have had).

Sounds like adding Clam was a great decision, alterdicecom. It could have been someone with less integrity finding that vulnerability.

$2400, not a bad days work dooglus!

Yeah, I expect the bug bounty will be massive!

Also:


15% of 1% of 1 BTC per roll is 0.0015 BTC per roll, coming to 0.015 BTC over all.

The example is off by a factor of 10.

I was just about to see what the new site is about when i got an error "Can't establish a connection to the server" and looks like the answer why it happened is right here.
That was a really fast find, well done doog. You most likely saved the owner a lot of headache.

That's great. I just tried the site out and was able to turn 400 satoshis into over 6 BTC exploiting a bug that a lot of new dice sites have.

Here's the relevant line from your provably fair verification code:


Stringing the client seed together with the roll number like that lets me make the same rolls twice: "x1"+"2" == "x" + "12"...

(I reported this to the owner privately and he already shut the betting down to implement a fix, so don't bother trying to exploit it).

Hello,

Clam has been added to https://alterdice.com for betting and recently to our new exchange. Bringing us to 12 supported currencies.

Clam will also be featured in our latest project coming in the next few weeks, along with a few other strong proof of stake blockchains. Check us out and let us know what you think, any feedback is welcomed.

https://bitcointalksearch.org/topic/m.13181620

John,
[email protected]

The data is being fetched here:


cc is clamd. It's using 'clamd getblockhash' to get the hash of each block, and 'clamd getblock' to get data about each block.

Both of those commands are talking to a fully-synced local instance of the CLAM client.

When I used to run Windows I mostly used "cygwin" (I think it was called) when I wanted to run bash scripts (which is what that first script above is). There was "MinGW" or something too, which I think did something similar. It's been a long time though, so I don't know what people use these days.

https://www.cygwin.com/ -- "Get that Linux feeling - on Windows"
http://www.mingw.org/ -- "Minimalist GNU for Windows"

Of course!

Waiting for the compiled version of the new client with all of the new bells and whistles.