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 ...
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.
@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 ...
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 ...
I did find the following information:
Some information about the history you can find here.
It is part of the so called 'epee' library.
The creator is a Russian programmer called Andrey N. Sabelnikov, who seems to be well known for creating a botnet.
The original code is located on Github.
It doesn't seem to be used anywhere else besides some ...
I do not know the exact number of lines of Monero source code, but there are a few methods to calculate it, which are described here.
Monero is not based on the Bitcoin code base and is rather complex. Because of this there has been a major effort to document and cleanup Monero source code:
There are over 70,000 lines of source in the src/ folder alone, ...
There were several changes:
This patch splits block and transaction data getters in two: one which retrieves the data, and the other also doing some parsing and reconstruction of the block or transaction. This allows skipping all the parsing (and reserializing) where it is not needed, which is mainly when ...
Things to keep in mind:
The field's location within transaction data is defined by the transaction's structure. Currently (protocol v12) the transaction version is v2, and 'extra' lives between 'vout' (outputs) and 'rct_signatures' (ringct data).
The field is interpreted as an array of bytes with little endian order (indexed 0, 1, 2). Its content is ...
0x01: transaction public key...
Incorrect. 0x01 is a public key. Not specifically a transaction public key. The wallets may stuff other public keys in extra, as an example, for multi-sig needs.
Open question(s): If e.g. there are two transaction public keys with tag 0x01, how will the core implementation interpret this?
Tag 0x01 is not defined as "...
In addition to the comments from user36303 and JollyMort see this answer to my recent question about the difference between ring size and mixin. The distinction is clarified below:
Ring size = 'mixin' (number of foreign outputs) + 1 (your output)
I agree with the advice above that this task is not urgent and should be left to someone very familiar with ...
If the core Monero daemon gets to a point where it's particularly secure and particularly stable (eg. the code has been formally verified).
Sounds like an idea rather than a particular plan with dates and methods intended for verification. When Monero is particularly secure and particularly stable, then they will probably start discussing methods of ...
Using David A. Wheeler's SLOCcount (http://www.dwheeler.com/sloccount), the canonical tool for counting such things, Monero appears to be about 65k lines of C++ code and 5k lines of C code (src and contrib/epee), as well as about 17k of crypto code, most of it derived from Daniel Bernstein's crypto code.
Ancillary libraries not counted (unbound, lmdb, etc).
Daemons (nodes) talk to each other using the epee levin protocol.
Both the wallet and daemon also expose JSON-RPC servers (so JSON sent over HTTP).
The methods are documented at:
The monero: scheme allows sending payment information. The main piece of data that's included is an address. Optionally, you can also include payment id, a comment, the name of address owner, and an amount.
This is meant to be used in cases where you are expecting a particular payment, and send this URI (either directly, or via QR code) to a client, who ...
sc_add - scalar add - is taking two big numbers, which are stored as binary in byte (char) arrays and returning the result of adding them together in another byte array, mod the order of the base point.
The function has to use byte arrays because the largest type for native numbers in C/C++ is 64 bits, hence if you want to add two 256 bit numbers you need ...
Each 3 words gets converted to 4 bytes of the secret key.
This particular line is calculating those 4 bytes (the unsigned integer at w) in the loop which is taking 3 words at a time. It's essentially the reverse of the 4 bytes to 3 words in the function bytes_to_words.
First of all a disclaimer, I have no idea about the simplewallet.cpp and the monero client source code, but since this is a general coding question, let me get you started.
First of all you need a library (or write your own class) which knows how to compute a sha256 hash. I would recommend the free Crypto++ library. Here's a sample for HMAC.
Or, you can ...