Promoted messages and attacks on the Twister blockchain are not a problem

277 views
Skip to first unread message

Amir Taaki

unread,
Jan 9, 2014, 5:43:39 AM1/9/14
to twiste...@googlegroups.com
If later the Twister blockchain became a problem, it's possible to switch to a merged scheme where people can register identities in the Bitcoin blockchain. There are many great innovations in Twister which provide a basic toolkit of functionality that can be used to make highly usable yet scalable crypto services. Thanks for this great piece of software.

(the blockchain + promoted messages is the big critique I keep hearing about Twister)

Klaus Alexander Seistrup

unread,
Jan 13, 2014, 3:01:39 PM1/13/14
to twiste...@googlegroups.com
I am one who thought that the promoted messages would be a problem.  But only until I saw how rarely they appear on my postboard.  I generally only see a promoted message when I open the web interface, i.e. once a day.  So far I'm not annoyed.

Miguel Freitas

unread,
Jan 13, 2014, 3:41:44 PM1/13/14
to twiste...@googlegroups.com
Crazy idea: what if we pay someone to run a basic twister mining rig?

Just to increase the minimum hash/sec level, so people with big hardware wouldn't be disrupting the average block times so easily?

Btw, people with big hardware wanting to disrupt twister just for fun would be actually losing money as they could put their hardware to mine more valuable things...

Too crazy?

regards,

Miguel


On Mon, Jan 13, 2014 at 6:01 PM, Klaus Alexander Seistrup <kl...@seistrup.dk> wrote:
I am one who thought that the promoted messages would be a problem.  But only until I saw how rarely they appear on my postboard.  I generally only see a promoted message when I open the web interface, i.e. once a day.  So far I'm not annoyed.

--
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.
For more options, visit https://groups.google.com/groups/opt_out.

Amir Taaki

unread,
Jan 13, 2014, 11:31:09 PM1/13/14
to twiste...@googlegroups.com
Lets do a thought experiment:

* Twister starts to employ special hardware to maintain the network.
* Twister gets big.
* Critical applications get built depending on Twister.
* Twister Foundation is born.
* Massive hardware requirements needed to protect the network from attack. Money needs to come from somewhere.

It's a bit extreme, but what I like about mining is the idea of outsourcing the infrastructure maintenance to the community rationalised by some personal benefit. In Twister this is the promoted posts.

If we're going to start talking about paying, then it might make sense that Twister block hashes are embedded in the Bitcoin blockchain. This way only the people who want to make promoted posts pay a small tx fee, and users still get to create free usernames. I can help code up such a prototype for you if this interests you. Twister clients could query a blockchain server for this info, and anyone can run these services. It adds an additional requirement to the Twister blockchain. We might even just do it for checkpoints (every 10 blocks or something) although with the low tx fees, I don't see why not do it for all blocks.

Amir Taaki

unread,
Jan 13, 2014, 11:33:45 PM1/13/14
to twiste...@googlegroups.com
So just to clarify: making a promoted post would cost you the memory/cpu and an additional tx fee for the bitcoin miners.

Amir Taaki

unread,
Jan 13, 2014, 11:47:44 PM1/13/14
to twiste...@googlegroups.com
Also the person who mines the block, the person who embeds the hash need not be the same person.

We could make a service that registers blocks for Twister users (first come, first served) which would ensure that for now, mining blocks in Twister doesn't cost BTC (because we absorb the cost).

Miguel Freitas

unread,
Jan 14, 2014, 6:00:23 AM1/14/14
to twiste...@googlegroups.com
Hi Amir,

Thanks for your thoughts. I follow your reasoning and I agree it is easier to get people to contribute their computer time (even if that costs them the electric bill at the end of the month) than sending money to a foundation.

Let me try to understand this bitcoin idea. So you suggest that the twister's hash would be embedded into a single tx in bitcoin, ok, that part i follow.

But what do you suggest next, the twisterd will need to check if the hash appeared at the bitcoin blockchain before accepting the block to it's own blockchain?

Querying a blockchain server sounds strange to me, isn't it a single point of attack?

regards,

Miguel

Cathal Garvey (Phone)

unread,
Jan 14, 2014, 6:32:13 AM1/14/14
to twiste...@googlegroups.com
Better idea: before Twister hits 1.0, make an urgent change to a blockchain that combats the escalation to hardware: Litecoin. Using scrypt over sha256 means mining is more democratic, there is less ability for a wealthy person to get disproportionately greater power over Twister than the average user's PC has.

Another long term problem with no obvious solution is the "mining pool" problem, where people gang up to get smaller but more guaranteed rewards. This is even more dangerous because people relinquish power entirely to a trusted third party and network integrity is lost. Worth considering carefully. The only thing I've seen so far is a P2P bitcoin mining overlay but it looks too hackish to be a real solution.

Also to reduce network load and therefore costs of maintenance, any plans for hashcash on posts to reduce the ease of spamming? Maybe this is implemented already but I see no mention of it..
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Miguel Freitas

unread,
Jan 14, 2014, 7:18:26 AM1/14/14
to twiste...@googlegroups.com
On Tue, Jan 14, 2014 at 9:32 AM, Cathal Garvey (Phone) <cathal...@cathalgarvey.me> wrote:
Better idea: before Twister hits 1.0, make an urgent change to a blockchain that combats the escalation to hardware: Litecoin. Using scrypt over sha256 means mining is more democratic, there is less ability for a wealthy person to get disproportionately greater power over Twister than the average user's PC has.

Can you guess what hash function twister uses for block POW? ;-)


Also to reduce network load and therefore costs of maintenance, any plans for hashcash on posts to reduce the ease of spamming? Maybe this is implemented already but I see no mention of it..


hashcash on posts? what is that?

regards,

Miguel

Amir Taaki

unread,
Jan 14, 2014, 7:21:52 AM1/14/14
to twiste...@googlegroups.com, cathal...@cathalgarvey.me
Cathal, Twister already is using scrypt from Litecoin.

Miguel, yep. The way I'd personally do it is to have a hardcoded secret in Twister. Then you would poll the history for ripemd_hash(secret + twister_block_height) in the Bitcoin blockchain. You'd order the credits to that address in the Bitcoin blockchain by Bitcoin block height, and fetch the transaction for the first entry. Then lookup the second output of that tx to see if it matches the current block.

Using a blockchain query server is not such a big deal as:

1) you can setup your own anytime.

2) it adds additional security to Twister (you'd need to hack the sever *and* twister blockchain).

3) I see twisterd as a server piece of software like your persistent email daemon. I don't like that the daemon hosts people's keys and seek to change it so that twisterd is doing the resource intensive parts, but you're managing the keys. In such a scenario, you'd host your own Bitcoin blockchain too.

For getting a new Twister block accepted:

1) Take block_key = ripemd_hash(twister_secret + twister_block_height)

2) Take block_id = ripemd_hash(twister_block_hash)

3) Construct a valid BTC transaction with 2 outputs: [block_key, block_id] and get it accepted by miners.

It could even be a sort of checkpoint too that comes into play after sometime so that it doesn't delay name registrations (soft checkpoint), although I prefer the hard checkpoint route.

Cathal Garvey

unread,
Jan 14, 2014, 7:24:11 AM1/14/14
to twiste...@googlegroups.com
> Can you guess what hash function twister uses for block POW? ;-)

Excellent! Sorry, like I said I haven't looked through code yet so I'm
only going by what's written, and everything says "Bitcoin". :)

> hashcash on posts? what is that?

AKA Proof-of-work. So every post has a timestamp (so POW can't be forged
in advance) and must come with a nonce so that it hashes to below a
certain value, usually chosen to take less than a second.

It needn't be even long enough to be noticeable to the average user, but
if it makes it take 1000x longer to send a message, then it reduces the
spam-load on the network by 1000x, too.

So, how long does it take to craft and send a message right now? Choose
a POW threshold that brings it up to about a second (less time than it
would take to write the next post anyway) and you've got a passive,
baked-in anti-spam measure.

It was proposed years ago as a system to increase the cost of spam in
email, but none of the major email servers/systems adopted it, sadly, so
it never took off. Spamassassin will give you +10 free points on your
mails if you include a hashcash header that passes muster, though, so if
you run your own email server and sometimes end up in spam filters, it's
perhaps worth trying. :)

I hacked up a (terrible) P2P twitter clone months ago as a demonstration
of the fruitlessness of censoring twitter, and included hashcash as a
core feature to prevent spam:
https://github.com/cathalgarvey/tinystatus

(Warning: Unreadable. :))
0x988B9099.asc
signature.asc

Miguel Freitas

unread,
Jan 14, 2014, 1:22:38 PM1/14/14
to twiste...@googlegroups.com
Amir,

About this bitcoin idea, why can't we do it in just one direction? That is: for a new block in twister blockchain to be accepted it would need to include not only the hash of the previous twister block but also the hash from a recent bitcoin block. Would it be enough?

While both ideas seem to prevent attacks like generating blocks too fast (faster than bitcoin's chain growth), they also seem to mess with ability to adjust network difficulty. If every twister block needs to be notarized somehow in bitcoin's chain, how would we detect an increased computation power (as we are lower-bounded by the other network)? 

One bitcoin checkpoint every 10 twister blocks may allow some difficulty adjusting. I'm not entirely convinced that it wouldn't open a new class of possible attacks though.

regards,

Miguel


--

Miguel Freitas

unread,
Jan 14, 2014, 1:32:15 PM1/14/14
to twiste...@googlegroups.com
Cathal,

On Tue, Jan 14, 2014 at 10:24 AM, Cathal Garvey <cathal...@cathalgarvey.me> wrote:
> hashcash on posts? what is that?

AKA Proof-of-work. So every post has a timestamp (so POW can't be forged
in advance) and must come with a nonce so that it hashes to below a
certain value, usually chosen to take less than a second.

It needn't be even long enough to be noticeable to the average user, but
if it makes it take 1000x longer to send a message, then it reduces the
spam-load on the network by 1000x, too.

Don't take me wrong, but i guess you need to read twister's paper ;-)

The block's POW is already what you are asking for. There is only 1 spam per block. Block's POW difficulty is dynamically adjusted by the network, like in bitcoin, targeting one block every 10 minutes. Also, sending 1000x faster blocks (more spams per second) will only increase the chance that your promoted post will be the one selected to be displayed to the user. It doesn't make users seeing more promoted messages per any unit of time.


So, how long does it take to craft and send a message right now? Choose
a POW threshold that brings it up to about a second (less time than it
would take to write the next post anyway) and you've got a passive,
baked-in anti-spam measure.

There is no POW in user's post. If you don't like a given user who sends spam you just stop following him.

This is entirely different than our promoted posts - read the paper! :-)

regards,

Miguel

Cathal Garvey

unread,
Jan 14, 2014, 1:51:55 PM1/14/14
to twiste...@googlegroups.com
> There is no POW in user's post. If you don't like a given user who sends
> spam you just stop following him.

This is the problem I'm looking at, not promoted posts themselves. I'm
aware they're difficult enough to send!

If I'm not mistaken (I haven't received any yet) you are notified of
mentions and DMs from people you don't follow? Otherwise that's a very
powerful "filter bubble", because one of the advantages of
micro/blogging is interacting with people you otherwise would not hear from.

But in that circumstance, people can mention or DM you spam, too. On
twitter and other silos, the central authority punishes spammers. In
Twister, if you can mention/message others, is there any protection or
cost-hike for spamming? Or can I start spamming people right away?
0x988B9099.asc
signature.asc

Miguel Freitas

unread,
Jan 14, 2014, 2:02:29 PM1/14/14
to twiste...@googlegroups.com
On Tue, Jan 14, 2014 at 4:51 PM, Cathal Garvey <cathal...@cathalgarvey.me> wrote:
If I'm not mistaken (I haven't received any yet) you are notified of
mentions and DMs from people you don't follow?

Mentions, yes. But not DMs (you must follow the sender).
 
Twister, if you can mention/message others, is there any protection or
cost-hike for spamming?

Not yet.

regards,

Miguel

Cathal Garvey

unread,
Jan 14, 2014, 2:04:12 PM1/14/14
to twiste...@googlegroups.com
NB: I sent a message from one of my accounts to the other. Neither
account follows the other. And I can see the message sent from one to
the other.

So, is there any mechanism by which Twister stops people spamming one
another with mentions?

Even hashcash won't stop spammers; it just prevents them from flooding
the network efficiently. The payoff of the 0.1% who click through the
spam becomes much less valuable, so they must go phishing instead.

Going further, a friend promotion/blacklisting system might help in the
long run. So for those phishers, if I block them for spam, then other
people people who are connected to me will get notice that I think
they're a phisher/spammer. Each account holder could have a manually
tweakable threshold of "black marks" they'll tolerate before having a
warning sign appear on an account, because someone who is connected to
1,000 people is likely to see a lot more spurious spamming notices than
someone connected to 10.
0x988B9099.asc
signature.asc

Cathal Garvey

unread,
Jan 14, 2014, 2:05:55 PM1/14/14
to twiste...@googlegroups.com
> Not yet.

OK, thanks. I suppose it's not a backwards-incompatible change to add
such a feature to later clients, so not so urgent..but worth considering
when things are closer to beta. It looks like you have at least one
"blackhat" lurker here who's willing to attack Twister, so I don't think
it'll be long until someone starts spamming to prove a point! ;)
0x988B9099.asc
signature.asc

Amir Taaki

unread,
Jan 14, 2014, 8:00:11 PM1/14/14
to twiste...@googlegroups.com
Nope, it doesn't help to include Bitcoin block hashes in Twister. You'd still be able to generate duplicate blocks with the same hash. The point of embedding data into the Bitcoin blockchain is as an authoritative stamp of which Twister block is genuine.

About difficulty adjustment: now I'm thinking and it isn't needed to mine blocks. Spammers can pay BTC directly not electricity bills and that becomes the authoritative next block. It's the job of spammers creating new blocks to ensure their blocks get and remain in the BTC blockchain. If someone else beats them to it then they've simply burnt some BTC. In Bitcoin if you pay higher fees, your transaction gets into a block earlier. With Twister, the market would eventually settle on an acceptable fee vs spam reward payoff of people creating new blocks.

It's nice because it keeps nickname registrations free, but there's some incentive for spammers to keep generating new blocks. It's like the real world where advertisers pay money to a platform for advertising space, except here it's an open market where anyone is able to submit their bids for equal access.

BTW a good compromise might be to reserve one slot at the top of a feed for spam instead of filling up the main feed.

Miguel Freitas

unread,
Jan 14, 2014, 8:09:08 PM1/14/14
to twiste...@googlegroups.com
On Tue, Jan 14, 2014 at 11:00 PM, Amir Taaki <gen...@gmail.com> wrote:
Nope, it doesn't help to include Bitcoin block hashes in Twister. You'd still be able to generate duplicate blocks with the same hash.

No, i wouldn't. It is easier to set a validation rule such that the bitcoin hash used in new block is required to be newer than the bitcoin hash used in previous block. We wouldn't even need the blocks themselves, just the sequence of hashes.


The point of embedding data into the Bitcoin blockchain is as an authoritative stamp of which Twister block is genuine.

Genuine in what sense?
Block is genuine if it proves to be newer than previous one and work was needed to create it, no?

regards,

Miguel

Amir Taaki

unread,
Jan 14, 2014, 8:49:06 PM1/14/14
to twiste...@googlegroups.com
On Wednesday, January 15, 2014 1:09:08 AM UTC, Miguel Freitas wrote:
On Tue, Jan 14, 2014 at 11:00 PM, Amir Taaki <gen...@gmail.com> wrote:
Nope, it doesn't help to include Bitcoin block hashes in Twister. You'd still be able to generate duplicate blocks with the same hash.

No, i wouldn't. It is easier to set a validation rule such that the bitcoin hash used in new block is required to be newer than the bitcoin hash used in previous block. We wouldn't even need the blocks themselves, just the sequence of hashes.

What would stop me forking the Twister chain to attack it? Which chain is valid? They both claim to be the next block in Twister and include the same Bitcoin block hash.
 
 
The point of embedding data into the Bitcoin blockchain is as an authoritative stamp of which Twister block is genuine.

Genuine in what sense?
Block is genuine if it proves to be newer than previous one and work was needed to create it, no?

Genuine is in according to consensus, this is the block we all agree to accept. The blockchain in Bitcoin uses proof of work to reach eventual consistency because it becomes more and more expensive to reverse old parts of the blockchain.

But in Twister, the risk is that nicknames start to become valuable and someone starts to fork the chain to steal nicknames from people. This means generating valid blocks that continue from an earlier point in the chain, and using your computing power to overtake the main chain making your new chain the valid one.
 

regards,

Miguel

Miguel Freitas

unread,
Jan 15, 2014, 4:54:58 AM1/15/14
to twiste...@googlegroups.com
Amir,

On Tue, Jan 14, 2014 at 11:49 PM, Amir Taaki <gen...@gmail.com> wrote:
On Wednesday, January 15, 2014 1:09:08 AM UTC, Miguel Freitas wrote:
On Tue, Jan 14, 2014 at 11:00 PM, Amir Taaki <gen...@gmail.com> wrote:
Nope, it doesn't help to include Bitcoin block hashes in Twister. You'd still be able to generate duplicate blocks with the same hash.

No, i wouldn't. It is easier to set a validation rule such that the bitcoin hash used in new block is required to be newer than the bitcoin hash used in previous block. We wouldn't even need the blocks themselves, just the sequence of hashes.

What would stop me forking the Twister chain to attack it? Which chain is valid? They both claim to be the next block in Twister and include the same Bitcoin block hash.


The same that we use currently: the sum of work of all the valid blocks + consensus on the longest chain. The new block wouldn't just be valid because it included a Bitcoin hash, that would only be a prerequisite, POW is still needed.


 
Genuine in what sense?
Block is genuine if it proves to be newer than previous one and work was needed to create it, no?

Genuine is in according to consensus, this is the block we all agree to accept. The blockchain in Bitcoin uses proof of work to reach eventual consistency because it becomes more and more expensive to reverse old parts of the blockchain.

Exactly.
 

But in Twister, the risk is that nicknames start to become valuable and someone starts to fork the chain to steal nicknames from people. This means generating valid blocks that continue from an earlier point in the chain, and using your computing power to overtake the main chain making your new chain the valid one.
 

I think i've got your point: you are either assuming that we would give up on POW entirely (relying only on Bitcoin's one) or that our computing power is so small that it shouldn't be considered a protection against block forking.

Now i understand your idea (the reason why we would like to get our hash included in bitcoin's main chain).

But i'm not convinced we should give up on having our own POW, is that what you suggest?

regards,

Miguel

PS: very insightful discussion btw, thanks for joining :)

Cathal Garvey

unread,
Jan 15, 2014, 5:40:20 AM1/15/14
to twiste...@googlegroups.com
What about "social pinning"? Twister is a social network, with
inferrable relationships of trust (mild trust, not real trust; let's
call it "network integrity trust"). I follow you and eighty other
people, so if there were a confusion about which block in a fork I
should follow (because they are of equal length), I'd follow the block
my friends are following, because that's where the discussion is going.

Of course, the average client to Twister may not have any knowledge of
which block s/he will be mined onto or was mined onto, but they can
probably tell which block they *were* mined onto and choose to regard as
"canon". But if they follow anyone who's also mining the network, then
that mining peer could be announcing which blockchain they're mining on
top of, and users who follow them could apply a positive weight towards
that chain in case of a tie.

This assumes a few defaults when it comes to an "attack": that the real
attackers are few in number, that they have disproportionate computing
power, and that they can probably forge as many fake accounts as needed.
But unless a significant fraction of the network chose to follow their
attack-mining accounts, most of the network would be connected to people
outside the attacking group, and would apply a positive weight towards
the "authentic" blockchain.

Does that make sense? Again, probably revealing my ignorance towards
all-things-blockchain here. :)
0x988B9099.asc
signature.asc

Amir Taaki

unread,
Jan 15, 2014, 7:21:12 AM1/15/14
to twiste...@googlegroups.com
Yep basically Bitcoin's blockchain is the strongest hardest security of any blockchain. Before I got into Twister, I wanted to combine a DHT with identities embedded in the blockchain. The biggest problem was that you have to pay for nicknames.

Twister solves that problem with the spam message which is a nice incentive to get spammers to pay a small fee, while keeping nickname registrations free. However I don't feel like it's adequate protection against an attack.

Check out this:

http://dealbook.nytimes.com/2013/12/21/into-the-bitcoin-mines/?_r=0

This is the power going into the Bitcoin network right now. Specialised ASICs and hard metal computing new blocks. Bootstrapping Twister from the BTC blockchain doesn't loose anything (you gain more security) and simplifies the code

Amir Taaki

unread,
Jan 15, 2014, 7:27:04 AM1/15/14
to twiste...@googlegroups.com
I didn't mean to send....

Anyway, it simplifies the code but the downsides are that spammers pay a tiny tx fee, and now there's a dependency on BTC blockchain server. I don't see this as a problem because spammers are incentivised and paying electricity anyway, even if block generation drops really low it doesn't make Twister any less secure. And twisterd is a piece of server software so I expect in the future people running the blockchain server on the same localhost machine.

Including the Bitcoin hash in the block doesn't stop the reversal attack which is what worries me most. If I have a valuable username that communicates some valuable financial information, then suddenly the benefit of attacking twister > benefit of helping twister. Now imagine there are a few such valuable usernames, or that someone is leaking documents or communicating highly sensitive information. Whether it's agents, corporations or scammers, the blockchain would get attacked and once Twister gets bigger you can't be relying on checkpoints to bail you out (because updates are more difficult with production software - maybe every 6 months or more).

John Kelley

unread,
Jan 15, 2014, 8:07:25 AM1/15/14
to twiste...@googlegroups.com
Thing is, the people who would want to disrupt twister would probably not be people looking to make money from btc. i.e. governments.

Miguel Freitas

unread,
Jan 15, 2014, 12:01:29 PM1/15/14
to twiste...@googlegroups.com
Amir,

Ok, I agree with with your reasoning. Now i think i understand your points, and yes using Bitcoin as you suggest might be an alternative. Of course this needs to be really really well thought, it is so much easy to leave open vulnerabilities behind when we try to create a new security protocol. 

Btw, about creating new security protocols I'd first try to adhere to the following general principle: don't do it. 

There are plenty of examples of security protocols which have gone wrong because the designers didn't though of... something. I read this book a few years ago and i highly recommend it (now it's free):


So in terms of twister, I'd still like to see how the current POW blockchain works.

One thing I like about the promoted message (i'm biased) is that it should scale: as the userbase increases, so will increase the intrinsic value of sending promoted messages. More users may also be convinced to generate their own blocks to help protecting the network they use.

I don't know, I think we should mature this discussion and see how the network behaves in the meantime.

regards,

Miguel



--
Reply all
Reply to author
Forward
0 new messages