CudaMiner-twister now available:

https://github.com/miguelfreitas/CudaMiner-twister

Compile with ./configure; make

Tested with: ./cudaminer -D -o http://127.0.0.1:28332/ -O user:pwd

Make sure your twister-core is up-to-date!

Here is what a lot of people have been asking for: twister for Windows!

Download Page

A bundle of twister for win32 + twister-html is provided as example, but it is still highly recommended that you compile your own executable.

By creating your own executable you can easily update to the newest version, without depending on anybody to do another bundle for you. If you are concerned about security, give it a try and help improving the compilation instructions.

Note: windows users are reporting problems to bootstrap the network (no connections). Try to manually add peer from one of the following seeder (try both “add peer” and “add dns”)

seed.twister.net.co
seed2.twister.net.co
seed3.twister.net.co
dnsseed.gombadi.com

twister is featuring in Die Tageszeitung newspaper (Germany):

twister – Etwas Bitcoin, etwas Twitter

and if have missed Wired coverage, here it is:

Out in the Open: An NSA-Proof Twitter, Built With Code From Bitcoin and BitTorrent

I’d like to add some notes about the new “soft checkpoints” feature that was commited yesterday. Let’s try a FAQ format.

• What is this “soft checkpoint” thing?

Checkpoint is a standard feature of original Bitcoin where a given block number (height) is associated to a certain hash. That means that the main block chain MUST include this specific block at that height since any alternative chain or branch will not be accepted. These checkpoints are hardcoded into the client’s source code, so i will refer to them as “hard” checkpoints. Hard checkpoints require users to update their clients to become effective.

The new “soft” checkpoint is not coded into the client code but is rather received from the network (from other peers).

• What is it good for?

Having more frequent checkpoints mean that we can resist reversal attacks better. The reversal attack of 01/18/2014 reverted about two days of user registrations but the attacker couldn’t go further in the past because we had a “hard” checkpoint as of 01/16/2014.

• So can’t we just keep using “hard” checkpoints?

No, this is not a viable solution. Updating “hard” checkpoints takes time, it is a manual intervention by developers (therefore centralized), it requires users to recompile their clients etc.

• Does it mean we are immune to reversal attacks now?

Sorry but no, soft checkpoint is no silver bullet. However I expect it to work as a nice harm reduction mechanism: instead of being able to revert days or even months of user registrations by submitting an alternative (longer) block chain to the network, the attacker will be able to revert just 6 blocks. This is about one hour of user registrations.

This is also a very clear win for twister users. Now, instead of being always worried about the real possibility of losing their usernames at any time without further notice, they will be able to trust that their usernames are permanent if 6 blocks have passed since their registration.

• How do we fix it permanently?

That’s simple: we need more hash power. Any block chain to be secure needs people “mining” the chain, trying to generate blocks. Start generating blocks yourself and help securing twister!

• So a 51% attack is still possible?

Yes, but it won’t be able to revert more than 6 blocks. The powerful attacker is still able, however, to prevent any new registration to the twister network. He just needs to keep attacking twister all the time, preventing new registrations… But then, by attacking the network all the time, it will be much easier to find out who he is…

• Is this the same as Feathercoin’s Advanced Checkpointing?

No, Feathercoin is a totally centralized solution, the checkpoints are still manually defined by their lead developer. Feathercoin developers have just created a faster delivery of centralized checkpoints to the clients. I don’t see why should we call it “advanced” by any standard.

• So how is twister’s soft checkpoint decentralized?

The idea is not new, it has been proposed before in Bitcoin forum (Feb 2013) but was mostly ignored. twister is, AFAICT, the first project to implement this.

Instead of relying on a single developer to decide what the checkpoint is, the twister’s soft checkpoint is automatically obtained by consensus, following Ripple’s consensus model. Users are suggested to read these links if they want to learn more about the concept.

• Unique Node List? A fixed list? Do we trust these people?

No, the nice thing about this consensus model is that we don’t need to trust these people individually. Some of them might even be trying to attack the network in some way, but the premise is that they will not collude to undermine twister security. It is their interest (at least for the majority of them) that twister user registration is trustful.

• Why can’t we let every username to vote for a checkpoint?

The username is not necessarily tied to different individuals. One would be able to generate arbitrary usernames and then fake the votes. It would only make the attack easier.

• You asked for volunteers to enter this user list, why?

Because their usernames will be publicly available. To this end, I have also suggested using a different username than the one they use to post messages. We just need to twisterd running with that given username’s private key in the wallet, preferably running 24×7. The daemon detects the username and does the rest (signing block hashes to cast votes).

• How is the new soft checkpoint accepted?

A new soft checkpoint is accepted whenever we have verified the signatures for votes of 51% of the Unique Node List. So it is important these people to have their nodes running most of the time, otherwise some votes will be missing.

• Does it replace the standard block chain decision algorithm?

No, proof-of-work based block chain is the same. We just want to persist an existing consensus among the nodes of the network about the recent past of the block chain. We do still allow branching/forking as usual, but the older (deep) history of the block is not allowed to change.

There is no good reason to allow deep history rewrites of the block chain, it is just that there is no good method to algorithmically forbid this. Limiting the size of rollback is not an option as it allows the attacker to create permanent chain forks among the nodes.

• Should I update my twister-core?

Yes, please. Soft checkpoint is available since 01/19/2014 changeset 102d172. This is twisterd version >= 0.9.8.

• I have something to say…

Then post it here.

Apparently today we had the second attack against twister.

But this time we are seeing the long anticipated “reversal attack”, which is when a new branch is quickly produced in order to overtake the original block chain sequence. Since this branch may start in a certain time in in the past, all registrations past the forking point are reverted and discarded. It seems the attacker has used our last checkpoint as a fork point (01/16/14 @ 8:41:39am) as he couldn’t have gone farther in the past (otherwise twister nodes would have rejected his blocks).

While this is a very unfortunately thing (except for him, who might find it very funny), I don’t think it is reason for much concern. I’m sure that we will be able to secure against this kind of attack using some ideas that are currently being discussed in twister-dev:

https://groups.google.com/forum/#!topic/twister-dev/tH3HlVQ_wmo

If you want to join the discussion, this is a good time.

For people who registered past 01/16/14, my apologies. Please try to resend your the registration to the network with the following command:

./twisterd sendnewusertransaction “username”

Then let us know if it works or not. I’m listening @twister or @mfreitas.

PS: One reason it is currently easy for digital coin miners to attack twister is the currently small hashrate of our network. So if you want to help making this attack harder for them, start generating blocks yourself!

Update (2014-01-21)
Comment by buhtig314 in github issue #111: “Then why the author susggested us to register previous usernames again? After all ,he knows the system best.I supposed,he can roallback the whole database to previous state by some way.(now i know ,maybe i misunderstand the author’s suggestion, he suggested us resend registration but not use previous usernames). If you’r conjecture is true,after twice’s attack ,attackers may posses almost all usernames registered by all of us by simply replacing the public keys with his own public keys. If so, it is ridiculous. By the way, if it’s due to twister’s weak computing power,why not make the “generating blocks” as a default option in twister client?”

Yes, this is due to our low computing power. And no, i’m not fond of the idea of using the user’s CPU without their consent. If someone builds a list of the blocks generated by the attacker we might think of an alternative to recover those usernames. This would not be simple or risk-free though.

Some twister-core and twister-html recent updates:

- New twister-core build system using GNU Autotools (added 01-17)

- Fix long standing bug of dhtget ceasing to work (issue #32). When daemon was left running for long periods it would eventually stop processing the dhtget rpc requests. This caused the UI to become very sluggish, failing to acquire new data from the DHT network. (fixed 01-17)

- twister-html now caches the mentions results locally (html5 local storage is used). This should greatly improve user’s experience, since mentions modal now opens much faster. (added 01-18)

- New twister-html i18n branch available for translators. Thanks @toyg for maintaining it!

- Vagrant build support (thanks @kmpm)

Have fun!

Another twister-core update is available today in github. User’s are suggested to update (git pull) to improve twister network in two aspects:

- More connections: a change introduced earlier this year unexpectedly limited the number of twisterd connections to a maximum of 23. The downside is that it was difficult for new users to enter the network, as most of the other clients were already at their maximum.

- Persisted mentions: the posts including mention to @somebody were not previously refreshed in DHT network. This resulted in mentions getting lost as network topology changes (eg. the increased interest we have seen in last few days added a lot of new nodes). By refreshing this DHT resource, it is expected that mentions should get more reliable (at least for 2 weeks since they are posted). The exact tuning of some expiration parameters is still subject for future research.

Note: twisterd version is now 0.9.5.

New bugfixes are available in github for twister-core, please update your client.

I’d like to apologize for this extra trouble, i’ve found some problems in blockchain validation rules that caused clients to reach different number of blocks (some of them completely stuck). The latest changes are important to fix this, so the faster people update their clients the best for everybody.

Not to mention that the amount of computing power in twister network has seen quite some variation in the last few days (since the attack). Maybe we will need to add a “mining rig” ourselves to stabilize the network, so that a single player entering/leaving the net shouldn’t be able to make such a big change in block generation times.

Let’s see if we can have a more stable twister network over the next few days.

There is another important bugfix in github for twister-core, please update your clients.

This is another unintended consequence of yesterday’s attack. Because some registrations were added to the invalid chain and then discarded, they were already included into the transaction index (txindex was originally used in bitcoin for monetary transactions, here this is the user registration but the name “transaction” was kept).

The problem happened when an innocent user tried to register again. Then a fork occurred: for those who erased their “blocks” directory it was a completely new user registration (correct). However, for those who didn’t, the txindex reported the user was already known, therefore both the transaction and the block were rejected. A new branch was created.

The fix included proper checking for user registration existence. That is, it must not only exist in index but it must also be mapped to a block in the main chain. With the updated client both users will agree, no matter if “blocks” directory was erased or not.

Sorry for the inconvenience. This is a very interesting learning process

Ok, so it happened.

Some joker is producing 1MB blocks which are filling everybody’s hard drives. It seems to have started at block 17926 (01 / 09 / 14 @ 4:30:01am UTC).

He also announced the famous “DON’T PANIC” message within the block. Ok, very funny. You have proved your point.

I’m considering to create a hardfork of the blockchain with the test to refuse the bad-sized transactions. This will cause newly registrations (past 4:30am) to be discarded.

Well, I think it’s fair for an alpha-version, right? I mean users have been warned.

So I will take a look at this. If you have any other idea please let me know.

regards,

Miguel

See this thread in google groups