Topic: NXT :: descendant of Bitcoin - Updated Information - page 1590. (Read 2761647 times)

I see, would PM ricot

Yes, I understand your idea: add another checksum to verify the error correction.

But:

a) If we just add a single Luhn digit we will get 1/10 probability that if user makes more than 2 typos he will lose money. It's unacceptable. So we need to add more.

b) This makes addresses longer and it's important to keep them short.

c) Error correction is not awesome: for example, it can't handle deletions and insertions, which are very common types of errors.

I just watched the vote total for NXT go up 16 in a couple minutes after posting that link, w00t but we need more!

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!

Unknown yet. 3M is taken only coz it's 25%. If we had 16M then 4M would be taken.

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.

Yes, I've tested it (I presume it's the same version, which runs on his site).

You can test it yourself:

https://nxtnotify.appspot.com/convert

NXTDM-MTZUD-G9LBC-VQELG <- correct address
NXTDM-KTZUD-G9KBC-VQZLG <- make 3 typos
NXTDM-KTZUD-G9K6C-VQZGG <- it corrects it to an incorrect, but valid account. Boom, money lost!

And as I said, error correction is very limited: if you forget to type just one character or type just one extra character - it won't help you anyway.

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)

done

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

CfB, J-L

What will be achieved with the funds set aside for development?

and what is the overall status of these projects, can you give comment on

for example:
Fund: OK or NOK        progress:complete,started,n/a            needs: development client


- Decentralized Alias System / DNS
Register names and assign them to URIs.  
URIs can be anything from web addresses to Nxt account numbers.  
These aliases will be tradeable in the near future.

Fund:          progress:            needs:

- Basic DDoS Protection

Fund:          progress:            needs:

- Decentralized Asset Exchange / Colored Coins
This allows gateways to issue assets on the Nxt network.  
These assets can include cryptocurrencies (BTC, LTC, etc), fiat currencies (USD, EUR, RMB, etc), stocks and other assets.

Fund:          progress:            needs:

- Transparent Mining
Transactions are encrypted.  
Only PoS block generator can decrypt transactions.

Fund:          progress:            needs:

- Arbitrary Messaging

Fund:          progress:            needs:

- Instant Transactions

Fund:          progress:            needs:

- Decentralized Marketplace / Auction
Buy or sell goods/services in a distributed manner.  
All listings are broadcast to all nodes on the network in P2P fashion.

Fund:          progress:            needs:

- Distributed Storage

Fund:          progress:            needs:

- Multi-signatures

Fund:          progress:            needs:

- Blockchain Shrinking

Fund:          progress:            needs:

- Two-phase Payments
Software supported escrow transactions

Fund:          progress:            needs:

- Voting System

Fund:          progress:            needs:

- Reputation System
Will be implemented after Voting System
Account trust rating system.  Check if sellers on the distributed exchange have a good history, if stock issuers pay dividends and if gateways honor their asset redemptions.

Fund:          progress:            needs:

- Decentralized Mixing Service

Fund:          progress:            needs:

- Distributed Computing

Fund:          progress:            needs:

- Smart Contracts

Fund:          progress:            needs:

- Hardware Wallets

Fund:          progress:            needs:

- Advanced DDoS Protection: Project Kharon

Fund:          progress:            needs:


Pin

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.

As I said before higher fee transaction always get precedence over lower fee transaction...seeing how blocks will soon be forged at a constant 60 second rate....it argues that their will be room inside those block for these non-fee AM's....

If his msg is soooo important that it has to get inside the current block then he can chose to pay a msg fee....10, 20 maybe 100 Nxt....that option should be there.  

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?

done.

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.

Everyone should Vote here:

https://bitcointalksearch.org/topic/poll-which-coin-do-you-want-to-see-added-to-httpcryptokopeneu-417125

NXT is on top - DO IT!

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)

If spamming messages increase the forging reward, it's a good thing isn't it ?

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.