punkrock
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 17, 2014, 10:58:27 AM |
|
@landomata: Sounds intersting.
|
|
|
|
landomata
Legendary
Offline
Activity: 2184
Merit: 1000
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 17, 2014, 11:02:08 AM |
|
@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
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 17, 2014, 11:11:42 AM |
|
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](https://bitcointalk.org/Smileys/default/grin.gif) 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
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 17, 2014, 11:13:21 AM |
|
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
Activity: 2184
Merit: 1000
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 17, 2014, 11:20:03 AM |
|
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](https://bitcointalk.org/Smileys/default/grin.gif) 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
Activity: 2184
Merit: 1000
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 17, 2014, 11:22:03 AM |
|
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
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 17, 2014, 11:22:25 AM |
|
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=524Original 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 33 123 228 375 490 557 655 739 8129 9encode it NXT-ABCD etc if you make a mistake decoding 33 124 223 475 490 657 655 739 8129 9You don't know what the account number should be but your algorithm can expect the check pattern to be correct hope this helps.
|
|
|
|
NxtChg
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 17, 2014, 11:29:32 AM |
|
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.
|
|
|
|
superresistant
Legendary
Offline
Activity: 2142
Merit: 1131
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 17, 2014, 11:31:48 AM |
|
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
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 17, 2014, 11:36:32 AM |
|
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)
|
|
|
|
|
chanc3r
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 17, 2014, 11:40:27 AM |
|
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.
|
|
|
|
|
pastet89
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 17, 2014, 11:46:31 AM |
|
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: Issue assetCreates an asset on the exchange Request 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 ? Transfer assetUsed to transfer a quantity of asset from one account to another 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
Activity: 2184
Merit: 1000
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 17, 2014, 11:47:32 AM |
|
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
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 17, 2014, 11:57:06 AM Last edit: January 17, 2014, 12:10:19 PM by NxtChg.com |
|
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.
|
|
|
|
pinarello
Full Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif) ![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 266
Merit: 100
NXT is the future
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 17, 2014, 12:03:05 PM |
|
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
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 17, 2014, 12:09:47 PM |
|
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
Activity: 51
Merit: 0
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 17, 2014, 12:10:00 PM |
|
|
|
|
|
LiQio
Legendary
Offline
Activity: 1181
Merit: 1002
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 17, 2014, 12:10:12 PM |
|
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)
|
|
|
|
|