fee transactions would take the 1st spot....its the same way now higher fee transactions always get included before lower fee transactions.

Interesting idea, but it won't work in this case.

The RS algorithm treats the whole message as a polynomial, so you can't just arbitrary insert values in it, it will be the same as introducing more errors.

And if we insert this pattern into addresses before sending, it will be the same as just increasing the parity and will make addresses longer.

So, the initial transaction with a 1nxt fee goes onto the blockchain. But why would nodes choose to put subsequent AMs (without fee) into blocks, if it earns nothing (and especially if it means excluding a transaction that would earn it a fee)?

(I'm assuming all AMs go on the main blockchain, rather than being handled separately e.g. by some service provider)

I am not explaining myself perhaps, so I'll have one more go
RS is used in data sending....
The data blocks are pre-encoded with a known check pattern which is ALWAYS there
If the decoder fails because of too much noise then the encoded block is rejected because the check pattern is corrupted too.

They are not arbitrary values but a pattern defined in the encoding standard (i.e. not added by the user but your software) that is always added into an account number before encoding and must always be present and intact after decoding otherwise you reject because the input was too corrupt to reproduce.

The user never sees it or knows it.

Anyone, please put some light on this:

I am trying to understand how the asset exchange works and how a decentralised exchange can be built on the current API, but I am not sure I am getting everything correct. Please, help me:


Q: Only the "seller" creates the asset and pays for it minimum of 1000 NXT. Correct?

Q: In this asset, the asset creator (seller) is selling 500 units of Turtlecoin.
Correct ?



Q: Transfering asset means to transfer some of the turtle coins (product) from the main asset with total quantity, which represents the market, to the account which has placed an acceptable bid price. Correct?

Q: Only the seller (asset creator) can do this only for his assets. Correct?

Q: When this transfer is performed, there is a difference from the initial quantities, the main market assets quantity decrease with the bought amount from the bidder, and the bought amount is transfered to buyer transfer account. But how is represented the added quantity of product to the buyer account and where can be checked this new balance of "item" ? As we know, account has only one property of balance, and these are NXT's.

Q: Using the "reference transaction", seller can make an insurance, that if the buyers payment for the item is still not confirmed to be sent to his account, the adjusting of the quantity item also will not be processed. So, if the buyer does not pay, he does not get the product. However, how can the buyer get protection? He can send money and then get nothing, because, for example, if the seller is selling BTC, BTC transactions are out of the NXT protocol and can not be tracked and confirmed within the exchange asset?

Q: As price is expressed only in NXT, does this mean, that on exchange asset you can do only one-way deals? For example, you can sell BTC for NXT, however, you can not sell NXT for BTC?

Adding any sort of check pattern is just increasing redundancy. You suggest to add about 32-bit more redundancy to what's already there (20-bit).

This will make addresses 6 characters longer:

DM-MTZUD-G9LBC-VQELG

DM-MTZUD-G9LBC-VQELG-FJWKJD

just to save the superficial error correction, which is only useful in those rare cases where you actually have to type the address.

Without error correction we already have both short addresses and a pretty decent collision ratio of 1 in a million. It means there are million times more possible addresses than valid addresses.

And error correction is very limited too. For example, if you forget to type just one character - it won't help you. If you type just one extra character - it won't help you.

So the most reasonable solution here is probably to just drop the error correction.

I would have to agree based on this example but the concept is essentially verifying the decoder output by adding an error detection to the output of the decoder - see below

NxtChg.com did you run the testcode (https://github.com/RicoTilgner/NxtReedSolomon) ricot provided in his initial post?
I'm asking, because he described it in such detail, that I have a hard time understanding, that it shouldn't work as described (https://forums.nxtcrypto.org/viewtopic.php?f=17&t=524#p2149)

(no intention to offend, just asking)

Persistent

The concept is essentially verifying the decoder output by adding an error detection to the expected output before encoding, my first example was a bit primitive and therefore expensive.

This could also be done with a smaller number of bytes by appending a Luhn check digit and then recalculating this after decoding - that would reduce the risk and the overhead.

After all the error correction is part of the AWESOME bit isn't it - we should try to keep it.

nxtBay.com - we sell T-shirts, cups, buttons and other merchandise with Next logo and accept NXT.

How to order:
- Add items to the shopping cart and place an order
- Receive an email with the order confirmation and shipping rate
- Send NXT to 17981222901451781753
- Get your order!