Review general considerations #1

pool2win · 2023-02-24T13:37:05Z

Just a way to send over some comments

Initial go More comments Remove ~ file added accidentally

mcelrath · 2023-03-03T15:14:13Z

braidpool_spec.md

+[kp] We don't need stratum v2 at all. If the grinding machines talk to a
+braidpool controller hosted on their facility, then the need for a secure
+communication layer to a pool operator disappears. [/kp]
+


Correct. But let's imagine a more dynamic scenario with e.g. multiple sites for one entity who runs only one braidpool instance instead of one per facility.

There are lots of considerations in StratumV2 that I want to punt on wherever possible, and establish synergy with them instead of competition.

mcelrath · 2023-03-03T15:16:38Z

general_considerations.md

 miners are not "part of" the pool. In other words, submitting a random sha256
 header to a pool must not count as a share contribution unless the ultimate
 payout for that share, had it become a bitcoin block, would have paid the pool
 in such a way that all other hashers are paid.

+[kp] This example raises too many questions. Maybe it was too early to
+have the example here.  []/kp
+


Why? What questions?

mcelrath · 2023-03-03T15:17:58Z

general_considerations.md

@@ -65,6 +77,9 @@ Transaction` transaction is included in the `Merkle Root`. We assume that this
 [consensus mechansim](#consensus-mechanism), for instance in an `OP_RETURN`
 output.

+[kp] We are getting into too many details here. The reader has no clue
+about why we are using P2TR.  [/kp]
+


Can change that, it just needs to be an address.

P2TR is required by FROST/ROAST.

mcelrath · 2023-03-03T15:20:18Z

general_considerations.md

+miners; 2) doesn't violate the incentives compatible requirements.
+
+[/kp]
+


Consensus in a braid is defined by a graph cut. We can't reason about timestamps with any reliability. If we could, we wouldn't need a consensus algorithm, just time-order everything!

The braid retargets its difficulty in effect definining $\delta F$.

mcelrath · 2023-03-03T15:22:57Z

general_considerations.md

+need to be convinced we need this when we have a DAG and a natural convergence
+to a tip every time a share matching bitcoin difficulty is found.
+
+[/kp]


DAG consensus is defined by the heaviest weighted tip.

The "heaviest weight linear path" is only used to do conflict resolution WITHIN the DAG. -- it can decide between two transactions on opposite sides of a diamond graph, for instance.

mcelrath · 2023-03-03T15:28:10Z

general_considerations.md

+understand the reason for this caveat.
+
+[/kp]
+


Well, this is practically impossible but it comes up a lot in discussion. Progress-free is required for the system to obey the Poisson distribution, among other things, and results in a certain definition of "fairness".

mcelrath · 2023-03-24T13:29:01Z

general_considerations.md

+all have the same coinbase input, so what are they spending?
+
+[/kp]
+


The inputs are all past coinbase outputs "owned" by the pool. These can be rolled into one output by combining the previous coinbase output with each new block's coinbase, so there's only one coinbase output with each block (and its value is the sum total of funds controlled by the pool).

mcelrath · 2023-03-24T13:31:15Z

general_considerations.md

+Address the question: This introduces another consensus protocol, and if an attacker can
+attack this protocol, it is game over again.
+
+[/kptodo]


The withdrawal request is a transaction in the braid, and is mined into beads, so it uses the same consensus as the braid itself and does not use a separate consensus mechanism.

mcelrath · 2023-03-24T13:33:05Z

general_considerations.md

+spec them too.
+
+[/kp]
+


who and how the swap is traded is outside the scope of Braidpool. We don't want to build a DEX here. All Braidpool needs to know is that there's a new address controlling the shares, and that address may have a script, but this is decided privately among the parties swapping shares for BTC.

mcelrath · 2023-03-24T13:36:40Z

general_considerations.md

+surface area, we will be vulnerable to more types of attacks.
+
+[/kp]
+


This is a 51% attack, and yes it's possible. I like to call such DAG solutions "ladder" diagrams because the simplest diagram looks like a ladder, with the tip switching sides of the ladder.

This is also controlled by the difficulty adjustment algorithm (DAA). A "ladder" is a single cohort, so the DAA sees no graph cuts for a long time and adjusts the difficulty upwards (beads become slower/difficulty increases/weak block target decreases)

mcelrath · 2023-03-24T13:38:17Z

general_considerations.md

+
+[/kp]
+
+


This is the "general considerations" doc so that's intentionally left out. But yes a specific proposal needs a specific prescription on how to handle changes in the participant set.

mcelrath · 2023-03-24T13:43:11Z

general_considerations.md

+   rules.
+
+[/kp]
+


I don't think we have any disagreement here. "Tie breaking" in #4 isn't required because the payout happens at the 5th block paying the shares from the DAG from genesis to the 4th block. (Assuming all that is more than 100 bitcoin blocks back) The DAG consensus itself is deterministic.

The rules about who signs the payout for the first few blocks is encoded in the node software, we don't have to ask large miners to do anything except run it (and it's entirely possible one of the set will be a small miner).

I'm confused about what's confusing here...

mcelrath · 2023-03-24T13:51:14Z

general_considerations.md

+to a received share, thus including it in the DAG. Once enough miners have a
+back pointer to a share, it is kind of buried in the DAG and thus gets
+rewarded. That is the general intuition behind reaching agreement with DAGs.]
+


I think you're saying we should do ex-post facto verification of a share's block? I agree but the devil is in the details. The required bandwidth is considerable and I've been thinking about spot-checking and sharing TX set differences using Wuille's algorithm.

e.g. dynamically organize shareholders into random quorums that verify each other's share-blocks. If the quorum size is 4, each miner needs to ensure 4 specific other shareholders receive enough data to verify his share. 3 of those 4 must post a signature (possibly mined into a bead) witnessing that they validated the share.

I assume that all transactions in a share-block are available to verifiers. If there are non-mempool transactions they must be shared with the share-block-validators. (and then I'd say the share validators should broadcast those transactions!)

bernardoaraujor · 2023-10-13T04:12:31Z

while trying to visualize general_considerations.md

I cannot render this equation to Github on firefox:

\[
    \frac{d({\rm hashrate})}{d({\rm BTC}) = \frac{d_1-d_2}{BTC_1 - BTC_2}
\]

mcelrath · 2023-10-16T17:19:28Z

@bernardoaraujor fixed, thanks!

Review general considerations

1c0a8a8

Initial go More comments Remove ~ file added accidentally

mcelrath reviewed Mar 3, 2023

View reviewed changes

mcelrath reviewed Mar 24, 2023

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Review general considerations #1

Review general considerations #1

pool2win commented Feb 24, 2023

mcelrath Mar 3, 2023

mcelrath Mar 3, 2023

mcelrath Mar 3, 2023

mcelrath Mar 24, 2023

mcelrath Mar 3, 2023

mcelrath Mar 3, 2023

mcelrath Mar 3, 2023

mcelrath Mar 24, 2023

mcelrath Mar 24, 2023

mcelrath Mar 24, 2023

mcelrath Mar 24, 2023

mcelrath Mar 24, 2023

mcelrath Mar 24, 2023

mcelrath Mar 24, 2023

bernardoaraujor commented Oct 13, 2023 •

edited

Loading

mcelrath commented Oct 16, 2023

		miners; 2) doesn't violate the incentives compatible requirements.

		[/kp]

		all have the same coinbase input, so what are they spending?

		[/kp]

		surface area, we will be vulnerable to more types of attacks.

		[/kp]

Review general considerations #1

Are you sure you want to change the base?

Review general considerations #1

Conversation

pool2win commented Feb 24, 2023

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bernardoaraujor commented Oct 13, 2023 • edited Loading

mcelrath commented Oct 16, 2023

bernardoaraujor commented Oct 13, 2023 •

edited

Loading