SIP-0008 Stackathon #Stackchain Dashboard

[von-Hodl]

SIP-0008 (draft)
Stackchain Dashboard

The Stackchain Dashboard is an application that allows Stackchainers to organize, access, and use stackchain data.

It's functions may include

1 Assisting in Stackjoins and Mempool Management
2 Displaying The Tip
3 Displaying Stackchain statistics
4 Organizing and displaying memes (The MemePool)

The most desired function of the Dashboard is Stackjoins and memepool management

Fucntion 1
Stackchain Stackjoin

It is well known that Stackjoins are the future of Stackchain.

What is a stackjoin?

A stackjoin is a stack of Bitcoin contributed to the stackchain that is less then the required amount to stack the current tip.

Example

If the currant stackheight is $1731 but a Stackchainer has only $100 to stack they can not stack $1732 because they are short $1632 but they can still participate by adding their $100 stack with the stacks of others until they collectively reach $1732. At which point the "Stacks" are "joined"

The currant process for a stackjoin is approximately

• Stackchainer makes a Bitcoin purchase taking a screen shot of the receipt.
  -Stackchainer posts their stackjoin with the $amount and the hashtag #Stackjoin
• A node that has selflessly agreed to managing stackjoins adds the stack to the Mempool.
  (The Mempool is a community created document edited by volunteer Stackchainers)
• The nodes that manage the Mempool then build a stack (block) when the Mempool has a sufficient combination of stacks that equal the necessary dollar amount to stack the next stack on the stackchain.
• The node then posts the receipts of all stacks in a new "stackjoined" block on the stackchain.

There are variations. Some stackjoiners may choose to build a stackjoin themselves without submission of their stacks to the Mempool.

Problem to be solved

Currently the process is labor intensive and relies on a small number of nodes.

As the stackheight increases the difficulty adjustment of solo mining a stack also increases. The result is:

• fewer miners will be able to solo mine
• more stacks will be stackjoins that involve greater numbers of smaller stacks.

Dashboard Stackjoins

The stackjoin functionality is proposed as this.

• Stackchainers can enter stacks into the dashboard that are designated for stackjoins.

• Bots could be used to enter stacks into the Dashboard by searching for #Stackjoin

• The Dashboard will not accept duplicate stacks and notify users that the stack was already entered.

• The dashboard will organize the stacks that have been entered and present them in a way where Stackchainers can validate

• If requested the Dashboard can organize the stacks into a desired block height. And format a stackjoin so it can be posted to the tip by a user.

Design considerations

It should always be a Stackchainer that posts a stackjoin to the tip. This is crucial part of the PoW of Stackchain.

Function 2
*** Displaying The Tip***

Dashboard can Display the Tip. Tip data can be gathered from @StackchainSig account on Twitter which will use the hashtag #Stackchaintip when the newest stack is added.

Fucntion 3
Stackchain Stats

Fucntion 4
Stackchain MemePool

[derekross]

SIP-0004 already exists. This would need to be SIP-0008.

[derekross]

Renamed to SIP-0008

[von-Hodl]

Changed the name of this SIP to Stackathon Stackchain Dashboard

[von-Hodl]

Added a technical concept to the SIP-0008

[PsyduckSpyduck]

I think the system should be automatic with regards to collecting stackjoin information but manual with regards to posting. I want bots feeding a database nodes access through the dashboard to verify amounts, receipts, etc.

A bot would need to listen for the event #stackjoin, extract and store the URL & text in the database. The dashboard queries the table and displays the tweets chronologically. Nodes use the dashboard to select and unselected tweets that fit the criteria for a proper stackjoin and manually input the stackjoin amount after validating the receipt.

[von-Hodl]

I agree.

The dashboard is for collecting and organizing data.

Stacks should always be stacked by Stackchainers.

[FREEBORN-MAN]

Right now we have individuals running/organizing the mempool of stackjoins. This has got to change in some way to allow anyone to pool the stacks together. More decentralization will be important if the StackChain wants to live as long as the dollar.

[PsyduckSpyduck]

I like your thinking. One issue I want to keep in mind is the threat of malicious actors. I think view and edit permissions should be separate. Anyone should be able to view it, anyone should be able to apply to edit it but only participants approved with permissions should be able to edit.

That leaves us with the problem of how to manage and control permissions though which feels very unbitoin to me. I think the solution may be to set things up in layers. Twitter node layer is permissionless and open for anyone to participate. Dashboard data layer is permissionless so anyone can at anytime can view, copy and even use the data but cannot make changes to the database. Dashboard edit layer is permissioned because it's a tool we're building for ourselves that's not going to be easy and will suck balls if some rando attacks it.

[von-Hodl]

Agreed.

A design goal of the SCD should be increasing accessibility to stackjoins, the Mempool, and other stackchain data and tools.

[von-Hodl]

The language has been added.

A design Goal is to make stackjoins and the memepool more accessible to Stackchainers.

[chewybtc]

I read Anthony SIP 008

I think it looks great… The only change that I would love to see… Is that the memepool is not accessible to anyone… Fully automated. When someone does a StackJoin that completes a Stack, they get a DM message from the Stack Chain computer telling them they have completed a Block… And then they are allowed to bring that to the tip. That’s my two cents

this would allow for any stacker to have as good a chance as anyone else to post to the tip

[PsyduckSpyduck]

While the system collects these stackjoins how are they being validated?
What if the person who last contributed doesn't want to post it, doesn't know how to post it, doesn't see the message or doesn't trust the message?
If our system is DMing people, how do we handle fakers targeting our plebs?

[von-Hodl]

Increasing automation and accessibility to the memepool and stackjoins is a goal of the dashboard.

Perhaps I should add that language.

[von-Hodl]

Language added.

A design goal is to make stackjoins and Mempool access more accessible to Stackchainers

[derekross]

The issue comes down to the whether the bot and/or application is able to gather data from a reputable data source. If the bot and/or application is watching Twitter Hashtags, it will find invalid data due to people posting incorrectly, spammers, etc. While this could be a datapoint, this is not sustainable or good datapoint without some sort of validation or management method.

Solution 1) Keeping it all on Twitter

The bot and/or application would watch a specific hashtag, for example #Stackjoin. The bot/application would seek validation from a list of "well known validators". This list would consist of i.e. 10 Stackchainers. Once 6 out of 10 Stackchainers reply to the #Stackjoin post with USD amount and #ValidStackjoin i.e. 100 #ValidStackjoin, the bot /application adds that amount to the mempool.

Follow #Stackjoin
If Reply is 100 #ValidStackjoin from [Validator List] = VALID
If #ValidStackjoin = 6/10 = Add to 100 Mempool and link to previous Tweet

Solution 2) Using the Stackchain Mempool Dashboard

The only place to submit a Stackjoin is on the official Stackchain Mempool Dashboard. All submissions here must be validated by a human for authenticity. A group of Stackchainers would have access to the dashboard and be permitted to validate Stackjoins as valid or invalid, similar to the above Twitter scenario. Once 6/10 Stackchainers approve the Stackjoin in the app dashboard, it gets added to the mempool. A bot could then send a DM to the Twitter user letting them know that their Stackjoin for XXX amount has been successfully submitted. Once used, the bot would send a DM again letting them know it was used and which block it was used in.

Required fields here would be Twitter username, USD amount of Stackjoin, and link to Tweet containing their screenshot.

Solution 3) A combination of both of 1 and 2.

[PsyduckSpyduck]

I need to learn to write like you. I really like the #ValidStackJoin solution for validating. It lets us scale for growth by adding validators when needed. Would the data be available for all to view or just the dashboard users?

Regarding solution 2
The only place to submit a Stackjoin is on the official Stackchain Mempool Dashboard
Does this mean nodes would need to reject blocks made by users without dashboard access?

I think we'll probably end up with a combo approach.

[von-Hodl]

I assume the dashboard would be a publicly available reasource, where anyone can see the data.

It's probably best that validators be known Stackchainers.

[derekross]

In my vision, I would see the dashboard application as publicly accessible and viewable data, so that anyone can build a Stackjoin. The validation portion would be the only part that's private. I also believe it's preferable to see whomever validated the Stackjoin to be displayed on the dashboard as well, so if there's ever any questions, we can ask those validators about the decision for future references. Nodes would be able to view the dashboard since it's public and verify for themselves if needed.

[George-StackChain]

I assume the dashboard would be a publicly available reasource, where anyone can see the data.

It's probably best that validators be known Stackchainers

It might be good to have a few minimum requirements to qualify "known StackChainers" for validators such as participation in previous stackjoins and node validation of stacks.

[von-Hodl]

Agreed.

How ever it is developed, it will start off with a few core dev Stackchainers.

They will know who contributes and hand them keys. Then those people will know who else is good, and so on.

[George-StackChain]

You probably all have this sorted, but I like to see it bullet-pointed out, so if this is redundant you don't have to read it.

Goals of SCD

• Collect StackJoin posts into a database
• Auto Calculate the database into Blocks
• Allow human Validator StackChainers to validate the collected database to ensure accuracy.
• Once validated, the SCD will auto compile a Block into a post-able formate
• Notify the last StackJoin contributor that a Block is ready in the dashboard.
• Have the Dashboard find the StackJoined block to verify that the StackJoins have been spent.

Did I get that right or miss anything?

[von-Hodl]

Sounds good. I'll take another look tonight if I can and add it into the proposal.

[von-Hodl]

I think I've included most of your ideas.

[peterdurham]

it might be good to store the proofs as tweets to avoid needing a static image host.

We would need a database, presumably to store login credents and data for the next stackblock.

Wondering if we could setup lightning invoices to signup, somewhere between 100-50,000 sats for various permissions. we could also just forward the sats to a subsidy that could be claimed on the site as well.

Human validators would be good but we shouldn't let just everybody edit, we could setup an account system that requires 100 sats over lightning to sign up.

if we have data in one source we could export to csv as well as display in the UI. We would just need a backend + frontend

Notifications could be done best with email, but also if we have the UI as sort of an active queue, we could make the block claimable as soon as sufficient proof of enough $ is uploaded.

Finding the latest block will require access to the Twitter API, which i've heard is not easy to get. We could also have an upload page on the app for any chain historians willing to input data, that way the website would update regularly without needing the twitter API. Definitely open to ideas on this one.

[von-Hodl]

So keep in mind we always want Stackchainers to be stacking. So we don't want that part automated.

In discussions that we had. It was agreed that human validators would be needed to verify that #Stackjoins that had been grabbed we're actual stackjoins and not spam.

I hadn't considered notifications. I just assumed whoever was interested in participating in stackjoins would do so in The Dashboard and have access to the necessary functions. But notifications may not be a terrible idea. Perhaps a Twitter bot that announces when a new Stackjoin has been grabbed? I dunnno.

As far as finding the latest block could we have The Dashboard grab it from @stackchainsig when the account tweets #Stackchaintip ? That was an idea that was mentioned. But if there's a better way don't let me stand in the way.

As far as Lightning invoices for permissions. I don't know. Maybe. My only criticism is do we want permissions to be accessible by anyone who can pay? Or inaccessible to people who can't pay?