Automatic consensus-based checkpoint

[Miguel Freitas]

Ok, time for a good controversy ;-)

This idea has been proposed before in Bitcoin and while it was not
accepted, i couldn't really find out what are the arguments against
it:

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

As Amir nicely explained in other post, he is mostly concerned with
the reversal attack, specially due to the fact that our hash power is
still very small compared to the currencies. So this "soft" checkpoint
was proposed to avoid the reversal attack by automatically
checkpointing a somewhat recent block (post says 6 blocks, but that
could be anything, a hundred, whatever).

Applied to bitcoin I think it would be a kind of strange to trust in
some semi-anonymous wallet, but since twister accounts might be mapped
to real and different people (if they want to) i think it could make
more sense here.

It is interesting to read the Ripple's description on consensus and UNL lists:

https://ripple.com/wiki/Consensus

I think this is something which could be easily implemented in
twister, given a group of people willing to participate. By
participating they would lose some of the "privacy" because the
twister network would know that their daemons were online at a given
time. No big deal, imho, my daemon is online doesn't mean much whether
i'm online or not.

Ok, so suppose we hardcode a list of known users in source (i will
call it UNL to keep the same Ripple nomenclature). Those users were
created before the last "hard" checkpoint.

If twisterd detects that you have a key in your wallet that is present
in UNL, then twisterd will automatically broadcast your vote for the
block to be checkpointed. Let's say this is performed for block "i"
when (i % 100 == 0) and currentBlock > i + 100. Whatever.

Nodes can only rebroadcast votes for users present in UNL. Nodes will
count votes and with 51% of UNL then a "soft" checkpoint is considered
valid.

New nodes joining the network may ask which is the last soft
checkpoint. They would then receive the checkpoint together with the
signature of those 51%+ of the UNL. The node may decide to trust the
checkpoint himself (or not).

Comments?

regards,

Miguel

[Miguel Freitas]

Another interesting reference:

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

However Feathercoin's "Advanced" Checkpoint is, in fact, centralized
checkpoint - only different that it is not hardcoded to the source.

regards,

Miguel

[Amir Taaki]

Yep this is actually quite common in altcoins because they get attacked and destroyed a lot.

(will answer OP later instead of a knee-jerk response)

[Amir Taaki]

Bitcoin's blockchain offers a hard consensus whereas Ripple's UNL offers a soft consensus. That's why we say Bitcoin is primarily a value store, not a payment system (the blockchain is a scarce expensive resource) whereas Ripple is a payments system, not a value store.

It depends on how you view Twister identities, and what guarantees you think will be needed in the future. The thing about Ripple is that it's been in development a while now and we don't know if it works. If you have 1000s of nodes, it's possible that the network forms because you don't reach a consensus and islands form (for instance if communication doesn't happen for some time). That's why Ripple emphasises being federated and using gateways - to reduce the number of nodes and make it easier for consensus to form (they also must constantly be online to participate and joining is more difficult).

What I like about Bitcoin is the simplicity of the concept. Bitcoin is an example of worse is better. Before Twister, I wanted to embed nicknames directly into the blockchain because I couldn't see how to incentivise others to do that for you. With spammers however we have them absorb that cost while keeping nickname registration free. Blocks can have a fixed window of 10 mins. You can even demote the visibility of spam (to say another tab) since the cost doesn't need to be so high of generating it (simply a Bitcoin tx fee). If the window is big enough (say 30 mins), since we're only embedding a small amount of data this might even be done voluntarily in the future if Twister becomes valuable enough as a service to be kept alive. So then it isn't a problem if spam becomes hidden.

[Amir Taaki]

It comes down to how valuable Twister identities will be in the future and what guarantee will be needed to enforce their security (among other things).

There's this concept in Bitcoin of fungibility, and people often phrase how they reason about things like anonymity, security .etc in Bitcoin in terms of it:

https://en.wikipedia.org/wiki/Fungibility

It's worth reasoning about Twister nicknames along the same sorts of lines - guaranteeing their immutability and integrity. I think it's possible that Twister identities become very very valuable especially if we start combining it with contracts, different financial applications, resource management, and integral communications (i.e messaging between critical individuals).

[Miguel Freitas]

Amir,

I agree with your value store x payment system comparison. I wouldn't
argue about the Ripple's consensus model alone as being any better
than Satoshi' blockchain, in fact, i think it is worse.

Satoshi's blockchain is a brilliant contribution to the computer
science in general. Perhaps at some point in future we might reach an
academic consensus about some of it's limitation, for example, that
the model can only be securely applied to a single chain (where most
of the world's hash power is going). This is not obvious atm or there
wouldn't be so many altcoins out there. Even for that principal chain
(which currently happens to be Bitcoin) the oligopolization by a few
pool miners may still cause a lot of concern.

So, what I liked about the "checkpoint consensus" idea (very well
defended by jl2012 in the thread i've mentioned) is that it may work
complementary to the Satoshi mechanism. If we are worried about
reversal attacks on small chains, the "checkpoint consensus" might be
a way to persist a given state of the network, a state where all the
peers agreed on what the recent past of blockchain looked like.

Do you think current twister's network may fail to reach a consensus
about what was the hash of the block one hour in the past? I don't see
that happening. The nodes I check usually agree exactly on what the
latest block is.

Of course persisting what peers believe to be the network state is
vulnerable to all kinds of Sybil attacks (peer forging).

So the idea of Ripple's consensus is to rely on independent but
existing entities who would not collude to defraud the system. You
don't trust in any user in particular, but if we map some usernames to
a bunch of real people, it is reasonable to suppose they will not
collude to attack twister network (even if one of them is trying to do
so).

I'm very interested in hearing any good arguments against this idea,
since it would spare me a lot of time of not having to code a flawed
mechanism ;-)

regards,

Miguel

> --
> You received this message because you are subscribed to the Google Groups
> "twister-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to twister-dev...@googlegroups.com.
> To post to this group, send email to twist...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

[Miguel Freitas]

On Fri, Jan 17, 2014 at 7:13 PM, Miguel Freitas <mfre...@gmail.com> wrote:

complementary to the Satoshi mechanism. If we are worried about
reversal attacks on small chains, the "checkpoint consensus" might be
a way to persist a given state of the network, a state where all the
peers agreed on what the recent past of blockchain looked like.

It seems it just happened:

REORGANIZE: Disconnect 325 blocks; b43180eb326f54a5164b18d762b84e44cd5c3899438c343ed5add6a28084290b..

REORGANIZE: Connect 326 blocks; ..25bdd49721e4603f954d1f74d03f674da072061723dc25546c8acb34c0f05cd6

So probably all registrations past 01 / 16 / 14 @ 8:41:39am UTC have been reverted.

Someone must be finding this very funny...

regards,

Miguel

[Giacomo Lacava]

On Saturday, 18 January 2014 21:22:00 UTC, Miguel Freitas wrote:

It seems it just happened:

REORGANIZE: Disconnect 325 blocks; b43180eb326f54a5164b18d762b84e44cd5c3899438c343ed5add6a28084290b..

REORGANIZE: Connect 326 blocks; ..25bdd49721e4603f954d1f74d03f674da072061723dc25546c8acb34c0f05cd6

And it seems to be crashing the service on my box.  

[Giacomo Lacava]

It seems the "new" chain is malformed...? My Twister tries hard to reorganise and eventually overflows something. OSX here.

DisconnectBlock: restoring old txid user: jamesaxl height: 20561

ERROR: ConnectBlock() : tried to overwrite transaction

InvalidChainFound: invalid block=70dfd943067d44b2756d02ee99f86ae39a7b3b4682f7b969b4a8fb829bf53518  height=20568  log2_work=36.719132  date=2014-01-18 22:06:29

InvalidChainFound:  current best=8f6683fda7875a79d632b58d262b305d828ae38da55e5141328e98e7a3b1cb09  height=20567  log2_work=36.718289  date=2014-01-18 22:37:25

InvalidChainFound: invalid block=4298570603e035bad3b38bf052b22242af439d8d41a9aa5ce6d903494af3f543  height=20562  log2_work=36.714067  date=2014-01-18 21:47:59

InvalidChainFound:  current best=8f6683fda7875a79d632b58d262b305d828ae38da55e5141328e98e7a3b1cb09  height=20567  log2_work=36.718289  date=2014-01-18 22:37:25

REORGANIZE: Disconnect 11 blocks; 2c0edbfd058ae3101460f9703a7d88f6af38de19a6191f3741bbf2ecd51a00e7..

REORGANIZE: Connect 12 blocks; ..70dfd943067d44b2756d02ee99f86ae39a7b3b4682f7b969b4a8fb829bf53518

DisconnectBlock: restoring old txid user: jonathan height: 20565

DisconnectBlock: restoring old txid user: loreal height: 20565

DisconnectBlock: restoring old txid user: slobodnyvysielac height: 20565

DisconnectBlock: restoring old txid user: morph height: 20565

DisconnectBlock: restoring old txid user: jamesaxl height: 20561

ERROR: ConnectBlock() : tried to overwrite transaction

InvalidChainFound: invalid block=70dfd943067d44b2756d02ee99f86ae39a7b3b4682f7b969b4a8fb829bf53518  height=20568  log2_work=36.719132  date=2014-01-18 22:06:29

InvalidChainFound:  current best=8f6683fda7875a79d632b58d262b305d828ae38da55e5141328e98e7a3b1cb09  height=20567  log2_work=36.718289  date=2014-01-18 22:37:25

InvalidChainFound: invalid block=4298570603e035bad3b38bf052b22242af439d8d41a9aa5ce6d903494af3f543  height=20562  log2_work=36.714067  date=2014-01-18 21:47:59

InvalidChainFound:  current best=8f6683fda7875a79d632b58d262b305d828ae38da55e5141328e98e7a3b1cb09  height=20567  log2_work=36.718289  date=2014-01-18 22:37:25

REORGANIZE: Disconnect 11 blocks; 2c0edbfd058ae3101460f9703a7d88f6af38de19a6191f3741bbf2ecd51a00e7..

REORGANIZE: Connect 12 blocks; ..70dfd943067d44b2756d02ee99f86ae39a7b3b4682f7b969b4a8fb829bf53518

DisconnectBlock: restoring old txid user: jonathan height: 20565

DisconnectBlock: restoring old txid user: loreal height: 20565

DisconnectBlock: restoring old txid user: slobodnyvysielac height: 20565

DisconnectBlock: restoring old txid user: morph height: 20565

DisconnectBlock: restoring old txid user: jamesaxl height: 20561

Bus error: 10

[Marc G.]

Giacomo Lacava :

It seems the "new" chain is malformed...? My Twister tries hard to reorganise and eventually overflows something. OSX here.

Got the same state, I started again with a new ~/.twister and it worked again.

But I somehow lost my username (registered initially after the 2014-01-16 08:41:39) in the process and can't import it again as it is already present in the blockchain :/
Did someone found funny to register it before me or is there a more general problem in the blockchain ?
 

[Giacomo Lacava]

On Sunday, 19 January 2014 00:44:36 UTC, Marc G. wrote:

Got the same state, I started again with a new ~/.twister and it worked again.

mhh, guess i could try that... am still not happy that I'll end up on what is likely the result of malicious actions.

 

But I somehow lost my username (registered initially after the 2014-01-16 08:41:39) in the process and can't import it again as it is already present in the blockchain :/ 
Did someone found funny to register it before me or is there a more general problem in the blockchain ?

Someone forced a rebranching of three days of chain, this sort of thing does not happen by accident... they must have applied a nontrivial amount of computing power to do it (not comparable to what it would take to hijack the bitcoin chain, but also not "just a laptop" so to speak). Your ID was just a casualty of this attack.

[Giacomo Lacava]

On Sunday, 19 January 2014 00:44:36 UTC, Marc G. wrote:

But I somehow lost my username (registered initially after the 2014-01-16 08:41:39) in the process and can't import it again as it is already present in the blockchain :/
Did someone found funny to register it before me or is there a more general problem in the blockchain ?
 

Miguel just posted on the official blog: http://twister.net.co/?p=236

Deleting the blocks seems to fix my crash. Still, it sucks.

[Miguel Freitas]

On Sat, Jan 18, 2014 at 10:35 PM, Giacomo Lacava <g.la...@gmail.com> wrote:

REORGANIZE: Disconnect 11 blocks; 2c0edbfd058ae3101460f9703a7d88f6af38de19a6191f3741bbf2ecd51a00e7..

REORGANIZE: Connect 12 blocks; ..70dfd943067d44b2756d02ee99f86ae39a7b3b4682f7b969b4a8fb829bf53518

DisconnectBlock: restoring old txid user: jonathan height: 20565

DisconnectBlock: restoring old txid user: loreal height: 20565

DisconnectBlock: restoring old txid user: slobodnyvysielac height: 20565

DisconnectBlock: restoring old txid user: morph height: 20565

DisconnectBlock: restoring old txid user: jamesaxl height: 20561

Bus error: 10

It is pretty bad to see the client crashing like that. This is a infinite recursion problem (the same function is called from itself to the infinite) causing a stack overflow and therefore a crash.

What I find most disturbing here is that i didn't played with that "best blockchain choosing logic" at all. We use exactly the same code as bitcoin's of a few months ago. Our errors (duplicated username registration) are supposed to map exactly the same as a bitcoin's invalid transactions errors.

That is, it is obviously quite possible that i've messed with something in twister. But at the same time, i'm not entirely convinced that bitcoin couldn't be attacked the same way. That is a theoretical attack where 51% is still required, but combined with some bad block generation, may the client be remotely crashed? I mean, worse yet: may we simultaneously crash all the clients? I don't know.

Anyway. I have just commited a patch to github which I expect to fix future problems of this kind. I know you erased your blocks already, but for anyone who didn't erase them, please give a try. Version is now 0.9.7.

regards,

Miguel

[Giacomo Lacava]

On Sunday, 19 January 2014 03:20:32 UTC, Miguel Freitas wrote:

That is a theoretical attack where 51% is still required, but combined with some bad block generation, may the client be remotely crashed? I mean, worse yet: may we simultaneously crash all the clients?

Guess so. Bitcoin has now reached dimensions such that they can probably wave away a lot of these scenarios because "nobody will ever have 51% anyway".

[Pieter Wuille]

(bitcoin developer here)

Nonetheless, it would be a very serious bug.

May I ask which version of the twister code you were running when this happened? It seems commit 77d1a4fb introduced a change that could cause this infinite loop (though it was intented to fix one?), but it was reverted in 4c25acc.

-- 

Pieter

[Giacomo Lacava]

On Sunday, 19 January 2014 15:20:20 UTC, Pieter Wuille wrote:

May I ask which version of the twister code you were running when this happened? It seems commit 77d1a4fb introduced a change that could cause this infinite loop (though it was intented to fix one?), but it was reverted in 4c25acc.

On or just before 19ff320d24ad4926a90b778d95ecbccb843d1d1d . I recompile daily on my laptop, so it sure wasn't a week old. 

In fact, it would be nice to have the last commit noted down somewhere at build time, so I can track what I was running when.

[Miguel Freitas]

On Sun, Jan 19, 2014 at 1:20 PM, Pieter Wuille <pieter...@gmail.com> wrote:

(bitcoin developer here)

Hi Pieter, nice to meet you and thanks for dropping by! :-)

I'll try to describe the issue so you may evaluate if it may be relevant to bitcoin as well.

 

Nonetheless, it would be a very serious bug.

May I ask which version of the twister code you were running when this happened? It seems commit 77d1a4fb introduced a change that could cause this infinite loop (though it was intented to fix one?), but it was reverted in 4c25acc.

This is the second time I encounter the same issue, so it is definitely reproducible with both ba43f10e and 19ff320d twister revisions.

Using yesterdays' block numbers:

- As the program starts, BestBlock = 20567a (using 'a' to differentiate the branches).

- The highest known block is 20568b.

- Block is 20562b is good in context-independent checks (CheckBlock) but fails ConnectBlock's transaction processing. Let's forget for a moment how a bad block like this came here, it is probably due to a buggy old miner.

- Fork point is 20556, that is, 20556a = 20556b.

1) So program starts, AppInit2 will call ConnectBestBlock. Block 20562b doesn't have any BLOCK_FAILED_* flags (suppose we have never tried to connect it) yet.

2) ConnectBestBlock calls SetBestChain(state, pindexSwitch =20568b).

3) SetBestChain finds the pfork = 20556 correctly. It will try to do:

   REORGANIZE: Disconnect 11 blocks;

   REORGANIZE: Connect 12 blocks;

4) Disconnect works fine. While connecting the longer branch, ConnectBlock fails with pindex=20562b.

  ERROR: ConnectBlock() : tried to overwrite transaction

5) InvalidChainFound is called with (pindexNew = 20568b). we see this:

  InvalidChainFound: invalid block=70dfd943067d44b2756d02ee99f86ae39a7b3b4682f7b969b4a8fb829bf53518  height=20568  log2_work=36.719132  date=2014-01-18 

22:06:29

  InvalidChainFound:  current best=8f6683fda7875a79d632b58d262b305d828ae38da55e5141328e98e7a3b1cb09  height=20567  log2_work=36.718289  date=2014-01-18 

22:37:25

6)  InvalidBlockFound is called with (pindex = 20562b). 20562b is set with status BLOCK_FAILED_VALID. This block is removed from from setBlockIndexValid.

7) InvalidBlockFound calls InvalidChainFound. we see this:

  InvalidChainFound: invalid block=4298570603e035bad3b38bf052b22242af439d8d41a9aa5ce6d903494af3f543  height=20562  log2_work=36.714067  date=2014-01-18 21:47:59

  InvalidChainFound:  current best=8f6683fda7875a79d632b58d262b305d828ae38da55e5141328e98e7a3b1cb09  height=20567  log2_work=36.718289  date=2014-01-18 22:37:25

8) Now this is where infinite recursion starts. I don't know what is supposed to stop it, but ConnectBestBlock() is called again, just like going back to step 2.

I know that 20562b is now marked as FAILED, but that doesn't seem to prevent ConnectBestBlock from calling SetBestChain again with 20568b. Note that 20568b is still supposedly good, has no BLOCK_FAILED_CHILD status and is still present in setBlockIndexValid.

So, what do you think?

regards,

Miguel

[Miguel Freitas]

Hey guys,

How do you feel about testing a highly experimental feature? Are you feeling lucky? ;-)

I believe we can't get much worse than this last attack, reverting 3 days of usernames (and registering them) was quite bad.

So if you want to try something different, i'm doing some last polishing on this patch. I may be ready to commit within a couple of minutes...

regards,

Miguel

--

[Miguel Freitas]

Hi everybody,

twister-core is now updated with new soft-checkpoints!

comments are welcomed ;-)

btw, if it doesn't cause twister network to crash into a great havoc, in the next phase i'll be looking for volunteers:

- volunteers are users who run their twisterd 24x7 (preferably).

- their usernames will be hardcoded into twister codebase.

- it doesn't need to be the username they use to post messages though, in fact, it is better not. the more anonymous the better since they are supposed to not collude to attack the network. so it is best if it is just a private key left on your wallet, doing nothing there...

- volunteers don't need to do anything at all. twisterd will detect the name is on the list and does the rest.

- username should be registered before the last twister "hard" checkpoint (although i may just advance the checkpoint for that)

As we must avoid identity forging in this list i have the following suggestion: volunteers should email me privately with the username they want me to add to the "Unique User List" (UUL, equivalent to Ripple's UNL). only users registered to twister-dev or twister-users will be accepted for now.

regards,

Miguel

[胡金宝]

I noticed that  registrations start from  16.1.14 8:41 am utc are discarded ,but, would you tell me what's the excatly end time point?
as a twister user ,i am very confused with such rollback stuff.

在 2014年1月20日星期一UTC+8上午9时05分59秒，Miguel Freitas写道：

[Dan Ballance]

Hi, I'm happy to help with this. I am running twisterd on  a vps I rent at the moment and would like to contribute to the network. It seems okay-ish in terms of resource usage. I have monit running and not receive any alarms. My only concern is security - I don't want my box to get pwned. Is there anyone pen-testing twisterd?

[Dimitri Vasdekis]

Hi Miguel,

If you're looking for people to easily add 24x7 twisterd clients with specific usernames to the network, may I suggest creating an Amazon Machine Image? It would allow people to use the Amazon Free Tier to contribute this capacity easily, for a year for free.

Secondly, with this update on the 20th, does that mean the android client is currently out of date?

Thanks!

[Miguel Freitas]

Dan,

I'm trying to code safely, but obviously i'm not infallible. So the thing with free software is that there will be thousands of eye balls checking for any mistakes in the code, but i don't know if there is anybody specifically pen-testing twisterd to tell me. I know there is somebody specifically trying to f... with the network, that's for sure.

I will try to write some comments about the soft checkpoint later today. But just to make something clear: being a "volunteer" for the soft checkpoint consensus won't make you any more prone to being attacked as anyone else. It just means that twisterd will use your private key to sign some block hashes, every couple of blocks it receives. The difference is negligible. I'm just asking because the usernames will be public listed.

regards,

Miguel

[Miguel Freitas]

On Mon, Jan 20, 2014 at 8:10 PM, Dimitri Vasdekis <dvas...@headsonic.com.au> wrote:

Hi Miguel,

If you're looking for people to easily add 24x7 twisterd clients with specific usernames to the network, may I suggest creating an Amazon Machine Image? It would allow people to use the Amazon Free Tier to contribute this capacity easily, for a year for free.

Sure, that's a good idea. No objections from me.

 

Secondly, with this update on the 20th, does that mean the android client is currently out of date?

The change is backward compatible. If twisterd connects to an older client it won't try to send the new message to it. But the more widespread the new version the better for everybody.

Anyway, I have already updated the ARK earlier this morning. I just didn't had a chance to update the website mentioning it.

regards,

Miguel

[Miguel Freitas]

Any more usernames for soft checkpoint (running twisterd 24x7)?

I have already updated hard checkpoint to block 20988 so recent
usernames are ok.

(send me a private message with the username to use for soft checkpoint)

regards,

Miguel

[Dan Ballance]

Hi guys,

Sorry to be a bit slow but these protocols are not something I know much about. I have a desktop install that I boot when I want to go online and post etc ( @proplus ). I have also done another installation on my vps which is running 24/7. Now I haven't registered on the vps server. If I tail the log, I can see network activity. I had (maybe wrongly) assumed that this would be contributing to the processing power of the network?

Anyways, I am keen to help in the way requested but I'm not 100% sure what you need me to do. Sorry!

On 26 Jan 2014 18:26, "David Stark" <idle...@gmail.com> wrote:

Hey Miguel

I think soft checkpointing is an excellent idea and its cool to see someone experimenting with it so count me in.
I will setup a VM for this tonight will DM a name once done.. (I'm @stark )

-d

--
You received this message because you are subscribed to the Google Groups "twister-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to twister-user...@googlegroups.com.
To post to this group, send email to twiste...@googlegroups.com.

[David Stark]

Hello

You need to start mining to help I believe.. On default you will simply be assisting with the network side..

To set it to always mine add the following to your  "$HOME/.twister/twister.conf" file:
######
gen=1
#genproclimit=1
#^^genproclimit limit how many processes/cores you want to use.. default will be 1x Process / 1x CPU core
######

#STOP
twisterd -rpcuser=user  -rpcpassword=pwd  -rpcallowip=127.0.0.1 stop
#START DAEMON
twisterd -rpcuser=user  -rpcpassword=pwd  -rpcallowip=127.0.0.1 -deamon
#CHECK IT IS MINING ( generate = true/false? )
twisterd -rpcuser=user  -rpcpassword=pwd  -rpcallowip=127.0.0.1 getmininginfo

This is much the same for bitcoin and other altcoins.. hope it helps

[胡金宝]

I don't agree with you,  "Unique Node List" is centralized . Who decide thoses accounts on the list? The creator youself. So you are the "center". The point is that , the spirit of decentralization is, twister don't  trust anybody , including the creater himself . Whatif the creater controls all thoses accounts ? He will control the whole twister network! So ,can we decide thoses accounts by randomly sampling? Can we  try to make a algorithm for every node to judge himself "if i am qualified for Unique Node List?"on the fly .If qualified, then this node can provide some infomation(i.e. all hashs of his blockchain) to  his neighbour to assist him to identify "reversal attack".

在 2014年1月17日星期五UTC+8上午6时40分40秒，Miguel Freitas写道：

[Miguel Freitas]

On Tue, Jan 28, 2014 at 6:03 AM, 胡金宝 <fxx...@gmail.com> wrote:

I don't agree with you,  "Unique Node List" is centralized . Who decide thoses accounts on the list? The creator youself. So you are the "center". The point is that , the spirit of decentralization is, twister don't  trust anybody , including the creater himself . Whatif the creater controls all thoses accounts ? He will control the whole twister network!

I hate to break your illusion man, but original Bitcoin's checkpoint is already centralized.

Soft checkpoint is actually *less* centralized than original checkpoint.

 

So ,can we decide thoses accounts by randomly sampling? Can we  try to make a algorithm for every node to judge himself "if i am qualified for Unique Node List?".If qualified, then this node will provide some infomation(i.e. all hashs of my blockchain) to  his neighbour to assist him to identify "reversal attack".

No, we can't let the nodes decide. Try reading about Sybil attacks.

http://en.wikipedia.org/wiki/Sybil_attack

regards,

Miguel

[胡金宝]

I have got an idea for anti sybil attack.
One may have super computing power to fake
tons of twister clients,but he can't control the IPs location spread over the
whole world.IP and location bindings are public available.So we may add a feature to client
"set trusted IP location pattern (TILP)".(who have the right to vote for me).
TILPs examples:
TwisterA set "i only trust 10 random ips located in 10 random diffrent contries(cities)"
TwisterB set "i only trust 10 random ips located in specific 10 contries(cities)"
and so on...
TILPs are secret and various from client to client.
Will twister's ips ditribution meet the needs?
I think so,if people trust twister,twister will spread over the whole world rapidly.
What do you think about this strategy?

[Miguel Freitas]

You won't be able to forward the votes you receive.

And different clients may reach different consensus, you split the network.

--
You received this message because you are subscribed to the Google Groups "twister-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to twister-dev...@googlegroups.com.
To post to this group, send email to twist...@googlegroups.com.

[胡金宝]

I only trust these 10 ips not mean i only communicate with these 10ips, i  conmmunicate with all peers as usual ,i just
read votes from these 10ips , if anyone choose to trust me and ask for  vote , i will send it to them.
will this help resolving problem?

[Paweł Kosiński]

> One may have super computing power to fake
tons of twister clients,but he can't control the IPs location spread over the
whole world.

Someone having super computing power may also have a neat botnet.

[胡金宝]

51% attack applys to both twister and bitcoin.
If so , it's destiny .One can suppose anything, nonthing is perfect.
It's about belief.I beleve twister is safe enough to survive, if it deploy TILP strategy.
Good news is
1. twister has many times of potential audience of bitcoin.
2. twister has less security level needs than bitcoin, cause it's not about money.
3. such a huge botnet  should be detected by the countless of security institutes on the internet,
before it grow to be huge enough to beat twister.
So if bitcoin is there, twister should be safe.