I just imagine, that node do number of requests in loading thread, and between that requests peer can change tail of it's blockchain. Just because there's no such entity like "locading session". In best case it just add new block. In worst case it can switch to another fork below common block. It's too late here, so I refuse to analyse what we get in that case  To protect "loading session" we can add response parameter "lastBlockHash" to all requests since the "getCumulativeDifference", and if it is changed - abandon all blocks and changes we got from that peer already. |
|
|
|
How can you block alias which is just a part of transaction in blockchain?
It's a feature of client software (again) - to protect user from internet danger. Like child/parent control in AV software, white/black lists and so on. You can setup service and sell it to Nxt'ers, but it's not a part of decentralized Nxt network.
You can add rank to each alias on the blockchain, which clients can use. If reliable voting can be implemented. Hmmm... Yes, voting can help. |
|
|
|
Google is centralized.
Well, there has to be a solution. Would voting system help? Several users will vote an alias down... Actually, maybe a full-blown alias rating? For scammers, who don't trade honestly and stuff like that? Something like a democratic Google Page Rank How can you block alias which is just a part of transaction in blockchain? It's a feature of client software (again) - to protect user from internet danger. Like child/parent control in AV software, white/black lists and so on. You can setup service and sell it to Nxt'ers, but it's not a part of decentralized Nxt network. |
|
|
|
Насколько я понял опытным путем -даже перекачивать ничего не нужно. Просто выйти и войти опять.
Перекачивать давным давно ничего не нужно. Бывает, из bak-файлов восстанавливать приходится. |
|
|
|
I'd like to see spending limits. For example so that I could only spend a maximum of 100 NXT/day from an account. Trying to steal this account would be less profitable. Btw, there can be arbitraty time limits, not only daily. There's no difference in processing any time ranges at software. |
|
|
|
He definitely has an agenda and strong knowledge of Java, I think we could give him a collective group hug and try to bring him on board with Nxt.
I see he have knowledge in Java, but do not see any proof that it is strong. He doesn't found any actual problem except well-known "one big file", "no unit tests", "empty catch blocks", "we all will die". |
|
|
|
Нигде. Вот как дойдем до сложности в тыщу - так сразу Пока что "difficulty" : 370.90909091. |
|
|
|
Brainstorming
I'd like to introduce a concept of a new feature called Account Control. This feature will allow to do different things with ur accounts. For example, u will be able to set a lock on an account to prohibit any outgoing transactions until a special condition met (e.g. an incoming transaction from a predefined account). Another example is Pooled Forging, when an account leases its forging power to another account.
Please, post here what u would like to see in Account Control.
Can we set it so that outgoing transactions are enabled only in specific hours, or in some interval of time ( for example only between 11:30 p.m. and 11:50 p.m., or only on 1st January?) It start to looks like "account setup transaction". I like the idea: 1. Block all coins from spending. 2. Block some coins from spending. 3. Set blocking time. 4. Allow to send coins only to specified account. 5. Combine that settings, so in different time there can be different number of coins blocked. |
|
|
|
Seems like there's vector of attack. Not very deadly, but... When some peer ask attacker's node for cummulative difficulty, nothing prevents this node to ask that peer's difficulty at the same time, and return some greater number. Then on request for milestone from same peer, attacker will return just one milestone block id, 720 ids lower than latest block. Than on request of next blocks attacker will return just one block, keep itself free from big traffic. Note, that this attack doesn't broke attacked node, it's blockchain and even cumulativeDifficulty, which is calculated dynamically from blockchain. It's just shrink blockchain on attacked node, strip last 720 blocks from it. On the next second attacked node do the same loop and asks another, good peer for that 720 blocks, generating some amount of traffic between good nodes. Attacker's node will not be blacklisted. This attack will almost not be visible in clients. There will be some jumps in last blocks for a seconds, no more. Not very danger attack Just some thoughts. |
|
|
|
Спасибо тебе, добрый человек, а можно своими словами для тех, кто в школе учил китайский, например ? А я не пользовался У меня и VPS нету. Я просто знаю, что народ тащится от этой методики. А переводить - нет уж, увольте. Я лучше ещё в сырцах поковыряюсь. |
|
|
|
The problem I try to note is that on step 2 and 3 we produce a lot of unnecesary traffic. Yes, most time it stops on step 1, but when new block is arrive, network start to move a lot of bytes. And this traffic can be lowered.
Let's rewrite the algo. What's ur proposal? 1. Add lowestHeight to "getMilestoneBlockIds" request. int lowestHeight = Math.max(0, Block.getLastBlock().height-720); Just because we will not download blocks deeper anyway. 2. In response for "getMilestoneBlockIds" use another logic and send first block ids tightly: int lowestHeight=...;
int jumpLength=1;
int maxJumpLength = block.height * 4 / 1461 + 1;
while (block.height>=lowestHeight) {
milestoneBlockIds.add(convert(block.getId()));
for (int i = 0; i < jumpLength && block.height>=lowestHeight; i++) {
block = blocks.get(block.previousBlock);
}
jumpLength=Math.min(jumpLength*2, maxJumpLength);
}
milestoneBlockIds.add(convert(block.getId())); // just to be sure... It gives us 12 ids in milestone request and 2-4 ids in getNextBlockIds request most time. |
|
|
|
And let me know about it before.  Yep, closed circle of initiated ones. But still decentralized, as BCNext entrusted. U also could join the circle. Just let BCNext to bite u... I am Immortal one. It doesn't work for Us. Are BCNext's bites are decentralized? |
|
|
|
Yes, I'm failed with elementary math  int jumpLength = block.height * 4 / 1461 + 1; It returns 365 blockIds everytime, so when one year will pass, milestone ids will be one for each day. So we have more or less the same response for "getMilestoneBlockIds", but longer and longer for each "getNextBlockIds". Are all rest assumptions correct? I see a lot of unnecessary traffic, every second. If u catch blocks from genesis block then yes, more and more traffic will be required. Hmmm... Let's "debug" it step-by-step. 1. Get peer's cumulativeDifficulty. Okey, let's assume that peer have higher difficulty, so it have more blocks, then we are. And assume simplest case: we are on same chain, but peer has newer block or two. 2. Get milestones. We get the array of ids. The first id from array is the latest block id from peer. We definitely have no such block, just because we have lower cumulative difficulty. But next block id is common for our node and peer. For today it is about 100 blocks down to chain. 3. Get next block ids starting from common. We get about 100 ids in response. Then find that common one is 98th. Or 99th. 4. Get new block or two from peer. The problem I try to note is that on step 2 and 3 we produce a lot of unnecesary traffic. Yes, most time it stops on step 1, but when new block is arrive, network start to move a lot of bytes. And this traffic can be lowered. |
|
|
|
Brainstorming
I'd like to introduce a concept of a new feature called Account Control. This feature will allow to do different things with ur accounts. For example, u will be able to set a lock on an account to prohibit any outgoing transactions until a special condition met (e.g. an incoming transaction from a predefined account). Another example is Pooled Forging, when an account leases its forging power to another account.
Please, post here what u would like to see in Account Control.
I want to assign an automatic payment on any date. For example, if I have to constantly make payment for some days. It's feature of client software. |
|
|
|
опять все упало, блоки от ноября, -2600, хотя версия 0.5.3
Аналогично, падает. Это место не чинят. Приходится перезапускать. Такое ощущение, что когда браузер не запущен, то так не падает никогда. Из бэкапа поднял. Но возникает вопрос - как такие вещи автоматизировать ? Если локально вылезает сообщение что плагин браузера крашнулся, и можно начать телодвижения, то как народ мониторит на удаленных серверах это дело ? Я свой вот-вот ставить собрался, а тут такое. |
|
|
|
Panic buying is going on @dgex Hell, next time I should buy before announcing new features... (kidding)And let me know about it before. Yep, closed circle of initiated ones. But still decentralized, as BCNext entrusted. |
|
|
|
Panic buying is going on @dgex Hamsters smelled something in the air... BUY!!!11111 |
|
|
|
опять все упало, блоки от ноября, -2600, хотя версия 0.5.3
Аналогично, падает. Это место не чинят. Приходится перезапускать. Такое ощущение, что когда браузер не запущен, то так не падает никогда. |
|
|
|
Yes, I'm failed with elementary math int jumpLength = block.height * 4 / 1461 + 1; It returns 365 blockIds everytime, so when one year will pass, milestone ids will be one for each day. So we have more or less the same response for "getMilestoneBlockIds", but longer and longer for each "getNextBlockIds". Are all rest assumptions correct? I see a lot of unnecessary traffic, every second. |
|
|
|
Brainstorming
I'd like to introduce a concept of a new feature called Account Control. This feature will allow to do different things with ur accounts. For example, u will be able to set a lock on an account to prohibit any outgoing transactions until a special condition met (e.g. an incoming transaction from a predefined account). Another example is Pooled Forging, when an account leases its forging power to another account.
Please, post here what u would like to see in Account Control.
Both features you mentioned are Great. The locked account can be a saving account. Or it could be used as a escrow monitored account as the escrow account is the predefined account. Tremendously helpful. Can a locked account forge ? Yes, it must be able forge or this feature have no meaning. |
|
|
|
|
Show Posts
