Bitcoin Forum
November 05, 2024, 11:13:55 PM *
News: Latest Bitcoin Core release: 28.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 ... 917 918 919 920 921 922 923 924 925 926 927 928 929 930 931 932 933 934 935 936 937 938 939 940 941 942 943 944 945 946 947 948 949 950 951 952 953 954 955 956 957 958 959 960 961 962 963 964 965 966 [967] 968 969 970 971 972 973 974 975 976 977 978 979 980 981 982 983 984 985 986 987 988 989 990 991 992 993 994 995 996 997 998 999 1000 1001 1002 1003 1004 1005 1006 1007 1008 1009 1010 1011 1012 1013 1014 1015 1016 1017 ... 2557 »
  Print  
Author Topic: NXT :: descendant of Bitcoin - Updated Information  (Read 2761602 times)
punkrock
Hero Member
*****
Offline Offline

Activity: 808
Merit: 1011



View Profile
January 17, 2014, 10:58:27 AM
 #19321

@landomata: Sounds intersting.
landomata
Legendary
*
Offline Offline

Activity: 2184
Merit: 1000


View Profile WWW
January 17, 2014, 11:02:08 AM
 #19322

@landomata: Sounds intersting.

CFB mentioned it could be done but:

1) Community would have to agree.

2) We would need someone to code it in.


It would definitely improve usability & save us from SPAM which is why everyone doesn;t want to lower msg fees...I think this solves the problem.
  

EDIT: Its only spammers who send to ramdom accounts....most people msg the same people everyday.

wesleyh
Sr. Member
****
Offline Offline

Activity: 308
Merit: 250


View Profile
January 17, 2014, 11:11:42 AM
 #19323

I will repeat my idea again as a solution for AM to make it easier to send AM while saving us from spam.


You charge 1 nxt as messaging fee to send AM to an account but allow the sender to resend any amount of messages he wants to that same account within 1440 blocks.

1440 blocks after the 1st msg he has to pay 1 nxt msg fee to send AM again.

If he wants to send to a NEW account he must pay 1 nxt msg to send AM to this NEW account.  After paying this 1 nxt fee he can send any amount of messages to this NEW account for 1440 blocks.


WHY THIS IS GOOD:  Grin

It allows you to freely communicate to another account but saves us from spam because its quite stupid to spam the same account & if you want to spam all accounts you have to still pay 1 nxt per msg.

  

Better would be if you can only send messages again after the recipient replies to you. Not before.

Also, this still results in big blockchain.

This also doesn't really stop spam since the situation is the same if you implement this or not; the spammer will have to pay 1 nxt per message (to diff accounts) in each scenario
notsoshifty
Sr. Member
****
Offline Offline

Activity: 378
Merit: 250


View Profile
January 17, 2014, 11:13:21 AM
 #19324

I will repeat my idea again as a solution for AM to make it easier to send AM while saving us from spam.

You charge 1 nxt as messaging fee to send AM to an account but allow the sender to resend any amount of messages he wants to that same account within 1440 blocks.

1440 blocks after the 1st msg he has to pay 1 nxt msg fee to send AM again.

If he wants to send to a NEW account he must pay 1 nxt msg to send AM to this NEW account.  After paying this 1 nxt fee he can send any amount of messages to this NEW account for 1440 blocks.

What incentive is there for a forging node to include a fee-less transaction into a block, especially if doing so would mean excluding a transaction that does come with a fee (due to space issues)?
landomata
Legendary
*
Offline Offline

Activity: 2184
Merit: 1000


View Profile WWW
January 17, 2014, 11:20:03 AM
 #19325

I will repeat my idea again as a solution for AM to make it easier to send AM while saving us from spam.


You charge 1 nxt as messaging fee to send AM to an account but allow the sender to resend any amount of messages he wants to that same account within 1440 blocks.

1440 blocks after the 1st msg he has to pay 1 nxt msg fee to send AM again.

If he wants to send to a NEW account he must pay 1 nxt msg to send AM to this NEW account.  After paying this 1 nxt fee he can send any amount of messages to this NEW account for 1440 blocks.


WHY THIS IS GOOD:  Grin

It allows you to freely communicate to another account but saves us from spam because its quite stupid to spam the same account & if you want to spam all accounts you have to still pay 1 nxt per msg.

  

Better would be if you can only send messages again after the recipient replies to you. Not before.

Also, this still results in big blockchain.

This also doesn't really stop spam since the situation is the same if you implement this or not; the spammer will have to pay 1 nxt per message (to diff accounts) in each scenario

nothing will stop spam it just makes it more expensive to spam...you have to spend Nxt.

we implement Time limit on each msg sent to blockchain....1 month or 10,000 blocks...like snapchat....this would save blockchain bloat.




landomata
Legendary
*
Offline Offline

Activity: 2184
Merit: 1000


View Profile WWW
January 17, 2014, 11:22:03 AM
 #19326

I will repeat my idea again as a solution for AM to make it easier to send AM while saving us from spam.

You charge 1 nxt as messaging fee to send AM to an account but allow the sender to resend any amount of messages he wants to that same account within 1440 blocks.

1440 blocks after the 1st msg he has to pay 1 nxt msg fee to send AM again.

If he wants to send to a NEW account he must pay 1 nxt msg to send AM to this NEW account.  After paying this 1 nxt fee he can send any amount of messages to this NEW account for 1440 blocks.

What incentive is there for a forging node to include a fee-less transaction into a block, especially if doing so would mean excluding a transaction that does come with a fee (due to space issues)?

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


chanc3r
Sr. Member
****
Offline Offline

Activity: 952
Merit: 253



View Profile
January 17, 2014, 11:22:25 AM
 #19327

Anyone here with math background who can help with Reed-Solomon codes problem?

It's needed for the New Address Format: https://forums.nxtcrypto.org/viewtopic.php?f=17&t=524

Original ricot's idea was to use RS codes to auto-correct typos to get superficial, but cool advantage over bitcoin addresses.

But it seems there is a problem. We know that with parity = 4 the algorithm can reliably detect up to 4 errors or correct up to 2.

What isn't mentioned is that those choices seem to be exclusive. You can either detect 4 errors for sure and get general 1/million collision probability (we use 20-bit redundancy) OR you can try to correct errors.

In almost quantum-physics-style weirdness, if you try to correct errors, you cannot use the previous check anymore!

And error correction fails miserably if there are more than 2 errors: it cannot detect that there are more. So it corrects into an incorrect address and there seems to be no way to verify this.

To put it in layman’s terms: you make more than 2 typos and you will almost certainly lose your money. This is unacceptable.

So can anyone either confirm this behavior or tell me what I am missing?


Not an expert in math but one solution I have seen before to this type of problem is to insert a known pattern into the encoded data before encoding, and then check it after decoding.

if the decoder fails the known pattern will fail to be reproduced and then you can trap the error, to my knowledge if the error correcting capability of reed solomon is exceeded then it will always generate an incorrect result but the probability of it maintaining the check data pattern and only corrupting the real data payload should be low - this would need some testing.

e.g. take account number 3323287590575539129
introduce known check pattern for example a progression 3312322837549055765573981299
encode it
NXT-ABCD etc
if you make a mistake decoding
3312422347549065765573981299
You don't know what the account number should be but your algorithm can expect the check pattern to be correct

hope this helps.

NxtChg
Hero Member
*****
Offline Offline

Activity: 840
Merit: 1002


Simcoin Developer


View Profile WWW
January 17, 2014, 11:29:32 AM
 #19328

Not an expert in math but one solution I have seen before to this type of problem is to insert a known pattern into the encoded data before encoding, and then check it after decoding.

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.

Simcoin: https://simtalk.org:444/ | The Simplest Bitcoin Wallet: https://tsbw.io/ | Coinmix: https://coinmix.to | Tippr stats: https://tsbw.io/tippr/
--
About smaragda and his lies: https://medium.com/@nxtchg/about-smaragda-and-his-lies-c376e4694de9
superresistant
Legendary
*
Offline Offline

Activity: 2156
Merit: 1131



View Profile
January 17, 2014, 11:31:48 AM
 #19329

nothing will stop spam it just makes it more expensive to spam...you have to spend Nxt.
we implement Time limit on each msg sent to blockchain....1 month or 10,000 blocks...like snapchat....this would save blockchain bloat.

If spamming messages increase the forging reward, it's a good thing isn't it ?
notsoshifty
Sr. Member
****
Offline Offline

Activity: 378
Merit: 250


View Profile
January 17, 2014, 11:36:32 AM
 #19330

What incentive is there for a forging node to include a fee-less transaction into a block, especially if doing so would mean excluding a transaction that does come with a fee (due to space issues)?

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

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)
DeadlyEskimo
Full Member
***
Offline Offline

Activity: 179
Merit: 100



View Profile
January 17, 2014, 11:38:52 AM
 #19331

Everyone should Vote here:

https://bitcointalk.org/index.php?topic=417125.0

NXT is on top - DO IT!
chanc3r
Sr. Member
****
Offline Offline

Activity: 952
Merit: 253



View Profile
January 17, 2014, 11:40:27 AM
 #19332

Not an expert in math but one solution I have seen before to this type of problem is to insert a known pattern into the encoded data before encoding, and then check it after decoding.

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.

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.

bitcoinpaul
Hero Member
*****
Offline Offline

Activity: 910
Merit: 1000



View Profile
January 17, 2014, 11:41:49 AM
 #19333

Everyone should Vote here:

https://bitcointalk.org/index.php?topic=417125.0

NXT is on top - DO IT!

done.
bananahunter67
Sr. Member
****
Offline Offline

Activity: 392
Merit: 265


View Profile WWW
January 17, 2014, 11:46:31 AM
 #19334

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:

Quote
Issue asset
Creates an asset on the exchange
Request
Code:
Code:
http://localhost:7874/nxt?
     requestType=issueAsset&
     secretPhrase=123&
     name=turtleCoin&
     description=This+is+Turtlecoin+issued+by+Tommy-Turtle&
     quantity=500&
     fee=1000&
     referencedTransaction=65374835678

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 ?


Quote
Transfer asset
Used to transfer a quantity of asset from one account to another
Code:
Code:
http://localhost:7874/nxt?
     requestType=transferAsset&
     secretPhrase=SECRET&
     recipient=ACCOUNT&
     asset=ASSETID&
     quantity=QTY&
     fee=FEE&
     deadline=DEADLINE&
     referencedTransaction=REFTXID

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?

Cryptostats.es
landomata
Legendary
*
Offline Offline

Activity: 2184
Merit: 1000


View Profile WWW
January 17, 2014, 11:47:32 AM
 #19335

What incentive is there for a forging node to include a fee-less transaction into a block, especially if doing so would mean excluding a transaction that does come with a fee (due to space issues)?

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

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)

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.  

NxtChg
Hero Member
*****
Offline Offline

Activity: 840
Merit: 1002


Simcoin Developer


View Profile WWW
January 17, 2014, 11:57:06 AM
Last edit: January 17, 2014, 12:10:19 PM by NxtChg.com
 #19336

I am not explaining myself perhaps, so I'll have one more go

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.






Simcoin: https://simtalk.org:444/ | The Simplest Bitcoin Wallet: https://tsbw.io/ | Coinmix: https://coinmix.to | Tippr stats: https://tsbw.io/tippr/
--
About smaragda and his lies: https://medium.com/@nxtchg/about-smaragda-and-his-lies-c376e4694de9
pinarello
Full Member
***
Offline Offline

Activity: 266
Merit: 100


NXT is the future


View Profile
January 17, 2014, 12:03:05 PM
 #19337

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

chanc3r
Sr. Member
****
Offline Offline

Activity: 952
Merit: 253



View Profile
January 17, 2014, 12:09:47 PM
 #19338

I am not explaining myself perhaps, so I'll have one more go

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.

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

arafel71
Newbie
*
Offline Offline

Activity: 51
Merit: 0


View Profile
January 17, 2014, 12:10:00 PM
 #19339

done
LiQio
Legendary
*
Offline Offline

Activity: 1181
Merit: 1002



View Profile
January 17, 2014, 12:10:12 PM
 #19340

I am not explaining myself perhaps, so I'll have one more go

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.

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


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)
Pages: « 1 ... 917 918 919 920 921 922 923 924 925 926 927 928 929 930 931 932 933 934 935 936 937 938 939 940 941 942 943 944 945 946 947 948 949 950 951 952 953 954 955 956 957 958 959 960 961 962 963 964 965 966 [967] 968 969 970 971 972 973 974 975 976 977 978 979 980 981 982 983 984 985 986 987 988 989 990 991 992 993 994 995 996 997 998 999 1000 1001 1002 1003 1004 1005 1006 1007 1008 1009 1010 1011 1012 1013 1014 1015 1016 1017 ... 2557 »
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!