Proposal: A decentralized transaction BBS using a merge-mined sidechain

Development and Technical Discussion
1

Proposal: A decentralized transaction BBS using a merge-mined sidechain.

Summary: I believe it would be possible to use a sidechain to grins blockchain as a transaction BBS. The basic idea is that there is a sidechain that can be mined and submitted shares will follow the same consensus rules as Grin but would include users slate/tx data, use a lower POW difficulty, have a faster block rate, and be pruned to a fixed number of blocks. It would NOT generate any new coin or token to compete with Grin.

Benefits would include:

  • Provide an opt-in decentralized BBS for communicating transactions using traditional-style addresses
  • Would not require wallets to be on-line
  • As a sidechain it wouldnt bloat the main chain
  • It would support the mining security and decentralization of the main chain
  • In addition to a transaction BBS it would be a decentralized, trustless, feeless Grin mining pool with (small) regular and immediate payouts.

How it could work - Users View:

Note: there are many possible configurations, for this example I will assume the Grin node and wallet have built-in support for the Sidechain-BBS. The process would be similar if it were not built-in but would need to be started as a separate command and the wallet would need minimal support to connect through its API.

A Grin user could generate a public/private key pair as part of creating a new wallet. The public key would be used as the “receiving address” (similar to traditional crypto address) and would also be used as a public key for encrypting the slate data. As with traditional crypto addresses they would need to communicate the public key (address) to the sender.

The sender would use the Grin wallet to create a transaction using the receivers public key as a destination address. The wallet would generate a slate using the existing process and that slate data would be encrypted using using the receivers public key. The wallet would recognize the address format and would know to submit the encrypted slate to the sidechain-BBS. The wallet would have a Cuckatoo32 solver built-in. The wallet would need to create a low-difficulty C32 POW (as spam protection) and submit that “share” along with the encrypted slate data to the grin-bbs-sidechain. The C32 “share” would be a valid Grin blockchain block including transactions but would be accepted by the sidechain at a much lower difficulty.

Note: The sidechain-BBS would have a much faster block time (blocks every 5 seconds for example) but would not need to retain full history so it would be very small and fast to sync. For this example lets say
the sidechain retains 7 days of blocks.

The receiver would have up to 7 days to start her wallet and sync the sidechain data. The receivers wallet would scan each block looking for slate data addressed to her. It would be able to decrypt the slate data using the private key. The wallet would then (optionally prompt for confirmation and) sign the slate
and first attempt to return it through the senders tor listener, or if that failed could encrypt it using the senders public key and submit that to the sidechain-BBS (also requires the wallet to solve a low-difficulty C32 POW).

The sender would then have up to 7 days to start his wallet and sync the sidechain data and scan blocks to find the signed slate. When found his wallet would decrypt the slate data, finalize it, and submit itto the Grin p2p network to be included in the next Grin block.

Bonus: Its possible that the sender or receiver would generate a (merge-mined) C32 POW share that is of sufficient difficulty to qualify as a valid Grin block. In that case the solved Grin block would also be submitted to the grin blockchain and the coinbase reward would be granted. The sidechain could give the entire coinbase to the finder, or it could act as a decentralized mining pool and distribute the coinbase between all recent participants using PPLNS.

References:

  1. Merge Mining: hashpower - How does merged mining work? - Bitcoin Stack Exchange
  2. Sidechain: An Introduction to Sidechains
  3. P2Pool: GitHub - SChernykh/p2pool: Decentralized pool for Monero mining
  4. Beam SBBS: https://beam.mw/beampedia-item/sbbs
  5. Satoshi comments on merge-mining: BitDNS and Generalizing Bitcoin
6 Likes
2

I like the idea of a P2Pool implementation for Grin and a BBS solution. I hadn’t thought of combining the ideas together, but I see now its a good fit to combine the two (several overlapping design goals).

I’m curious, how do you plan on constructing the merged block, such that the sidechain can have its extra data committed to, without requiring an extension to the Grin block format? Do grin blocks have any extra fields which can be used or dual-purposed to commit to the sidechain’s data?

Thanks for sharing.

3

That seems impractical, due to the large resources needed to process one C32 graph. The current CPU mean miner doesn’t even handle C32; topping out at C31 instead. That one takes over a minute single threaded and 10GB of memory on my Core i5 iMac. C32, if implemented, would take at least twice as long. And you expect to process 42 graphs to find a solution (of any difficulty). With just a little bad luck you may have to search over a hundred graphs before finding any solution. Which could take several hours. Lean mining, while using vastly less memory, is over 4 times slower.

How can the receiver sync if they don’t already have a recent (at most 7 days) state?