I heard the term thrown around here and on Reddit, but I haven't found its definition anywhere. Could someone please clarify?
Add a comment
|
3 Answers
The way blocks are currently propagated, every transaction is sent even though a node might have many, if not all transactions already.
The idea is to just send the block header and transaction IDs, and if necessary, any missing transactions.
The ultimate achievement is a reduction in data sent over the wire, which translates to lower bandwidth requirements to run your own full-node.
It's work done by revler1082, to introduce the Monero variant of compact blocks.
As to what it's supposed to do, here's a quote from the github discussion which pretty much sums it up.
fluffypony wrote:
@NanoAkron @revler1082 I think let's stick to Compact Blocks for now, XThin isn't massively well-specced, and there are other issues with it. Here's a good write-up where @gmaxwell responds to that presentation.
Also, this is security software - simpler is better. All we're really trying to accomplish is for a node to say "here's the header, what transactions do you need?" - no bloom filter, no complexity
-
-
Fantastic! So that is just thin blocks, as suggested for Bitcoin? If so, that is great news, and shows how this community and devs are superior and more agile to implement nice improvements such as this.– user141Commented Nov 9, 2016 at 2:50
-
> "Bloom filters are complex?" I've seen it mentioned that bloom filters on ring signature transactions are complex. Commented Nov 9, 2016 at 2:54
-
Jolly Mort and revler1082 already provided a nice description of the Monero Compact Blocks (fluffy blocks) concept. Below is some background for the ideas origination, development and nickname, which serves as a great model for new developers interested in joining the Monero community.
Four months ago the developer revler1082 appeared on r/monero asking for resources/proxies to track user growth. Two months later, revler1082 asked an initial question on Stack Exchange, this time about compact blocks. The answer provided by fluffypony inspired a 2nd Reddit post describing his implementation plans for what would soon be known as "fluffy blocks". After some developer discussion on the first pull request, a new pull request was submitted in attempt to address feedback to that point.
According to revler1082 about the new PR:
Pretty much same as #1242, but fixed up the p2p stuff so that it works with current release nodes.
Work is ongoing but fluffypony expressed interest on October 29th for including this pull request in the January fork:
Should we make this part of the January hard fork? Let's discuss it in tomorrow's meeting, @revler1082 will you be attending?
