[tor-relays] Oniontip

Sun Sep 28 14:14:46 UTC 2014

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Well I'm happy to see OnionTip, I think it's certainly better than the
reimbursement approach which uses far too much paperwork and time etc.
Having said this we need to increase adoption before people like
myself step into the frame because the moment I bring in my exit
cluster is the moment it will sap more than 50% of all donations and
even more for exit donations. For now I am refraining from joining. My
own finances can support my current cluster for several years assuming
no further income or support and I appreciate this isn't the case with
everyone, so it is best the donations went to them first.

If we wanted to support diversity, we could place some multipliers
based on bandwidth probability? So for example, if the country of the
relay is one of the top 10 countries it reduces the share of donation
by 40%, places 11-20 reduced by 20% and then 21-30 receives 20% boost
and 31+ receive 40% boost? If you've been following the topic in
tor-dev about scaling Tor, diversity is very important and I feel
oniontip may go some way to assisting that by providing incentives to
diversify.

- -T

On 28/09/2014 15:03, Donncha O'Cearbhaill wrote:
> Thanks everyone for all the feedback. I'm delighted to see OnionTip
> is being used and that relay operators are getting some (usually
> token) appreciation.
> 
> Mike, I've taken on board all the feedback you gave to this list on
> 2nd September. I've just pushed some changes. There is now a
> listing of all previous transactions sent from OnionTip, their size
> and the number or relays they have selected to pay.[1]
> 
> The number of selected relays gives a rough indication of how many 
> people are just paying the default (to all the relays) or are
> setting their own criteria.
> 
> I've also published a Python script to validate the transactions 
> completely from the blockchain based on the seed I use to generate 
> addresses [2].
> 
> I'm open to all suggests for a better distribution strategy. At
> the moment I definitely think the incentive is somewhat wrong when
> someone gets a much larger share by running a middle relay in a
> cheap bandwidth location than someone running a smaller exit in a
> geographical diversity location.
> 
> As most people seem to use the defaults, for a start I'm going to
> add an option so that Exits receive a premium on their bandwidth
> share by default (maybe 1.5-2x).
> 
> If there are any particular questions anyone has about the data or 
> donations so far, I'm happy to pull the data from the DB and try
> to answer them. For one, I'm going to try find out how many relays
> had bitcoin address listed in their first day or two. Maybe it can
> give an indication how many new relay operators are being pulled in
> because of OnionTip.
> 
> Thanks again for all the feedback so far. I look forward to seeing
> what we can do to improve OnionTip, and to continue supporting the
> growth of the Tor network.
> 
> Regards, Donncha
> 
> [1] https://oniontip.com/transactions [2] 
> https://github.com/DonnchaC/oniontip/blob/master/scripts/payment-check.py
>
> 
> 
> 
> On Sun, 2014-09-28 at 02:32 -0700, Mike Perry wrote:
>> Thomas White:
>>> Hmmm... appears to be have been upgraded since I last checked
>>> then (which was only a few weeks ago!). Nicely done oniontip. I
>>> stand corrected.
>> 
>> Well, my original ask was for everyone to be able to verify that
>> all 12.36 BTC that oniontip has received (as of right now) has
>> actually been distributed how the users have asked.
>> 
>> I suppose that since individual users can easily inspect that
>> their donation has gone to the relays they selected (by looking
>> at blockchain.info for their one-time use address), it is
>> unlikely that the system will get away with cheating for long.
>> But it is still hard for a new donor to tell if any other donors
>> have been swindled recently, using simple blockchain inspection.
>> They basically have to click around on the individual relay
>> recipient keys to make sure everything looks legit.
>> 
>> This makes me nervous in terms of endorsement. I can easily see
>> hundreds of users getting swindled before one of them suddenly
>> realizes that there is an extra bitcoin address in their
>> transactions that is not in the original relay list they
>> selected, or that the actual bitcoin distribution was slightly
>> different than what they selected. If all users could inspect all
>> donations easily, this type of compromise would be found
>> quicker.
>> 
>> Ideally, it would be possible to verify all of these questions
>> (and many more) with only the blockchain. For instance, a comment
>> in the bitcoin transaction could indicate the OnionTip options
>> selected, and a single page on the website could allow us to view
>> all donations to the system.
>> 
>> 
>> Beyond this, I think there are actually interesting sociological 
>> questions we could answer with easy access to the OnionTip
>> donation data and option selection. I'm very curious how donors
>> are choosing to distribute their Bitcoin to the relays.
>> 
>> For instance:
>> 
>> 1. Is OnionTip encouraging the type of network diversity we want?
>> Do we want to suggest changes to the default donation mode to
>> encourage better diversity?
>> 
>> 2. UI is still confusing to me. Is this UI causing people to
>> prefer a certain type of donation over others, where they
>> probably shouldn't?
>> 
>> a. Is anyone actually using the Guard or Exit filters? If not,
>> this means my super-cheap and unreliable FDC middle node will
>> probably get me more OnionTip donations than either a more stable
>> Guard node, or a more hassle-prone Exit node. This seems like an 
>> undesirable way to incentivize relay operation. Is it happening? 
>> Or are most people selecting Guard+Exit?
>> 
>> b. Are people taking advantage of the country selection dialog?
>> Are they doing it in a way that is favoring underrepresented
>> countries? Or are people just choosing countries based on the
>> next World Cup match, the current Olympic gold medal count
>> leader, or some other crazy notion that seems to make little
>> sense to network diversity?
>> 
>> 3. What are big donors doing? Do they always select the default
>> choice?
>> 
>> a. If so, we should think waaay harder about what this choice
>> is.
>> 
>> b. If not, what do they want? Do they like specific or strange 
>> countries? Do they like countries with the fewest relays? With
>> the lowest current bandwidth? With the best laws? Do we agree
>> with their choices, and want to make it easier for other donors
>> to make them too? Or should we be concerned, and try to encourage
>> other behavior?
>> 
>> c. Maybe only big donors get scammed with extra BTC destination 
>> addresses or a different transaction entirely? How can I see if 
>> other recent big donors have been scammed?
>> 
>> 
>> 
>> 
>>> On 28/09/2014 03:28, Ed Carter wrote:
>>>> The process is completely transparent.  All Bitcoin
>>>> transactions are viewable by the public on the Bitcoin
>>>> blockchain.  The Bitcoin addresses are posted by the relay
>>>> operators themselves in their contact info on their relay.  I
>>>> can confirm that I receive donations made to the address I
>>>> posted on my relay.
>>>> 
>>>> My relay: 
>>>> https://globe.torproject.org/#/relay/3C49A7D9BEBC668352F627CE60B1FE9B628DD2EA
>>>>
>>>>
>>>> 
Blockchain.info web page showing donations received to my
>>>> address: 
>>>> http://blockchain.info/address/1GXZVChXoxgrBzqMsCrWGu2ua6VTKSH6U1
>>>>
>>>>>
>>>> 
My concern (which has been highlighted before by Mike Perry) is
>>>>> that the site lacks accountability and transparency. There
>>>>> is no way to verify the donations actually reach the
>>>>> operators.
>> 
>> _______________________________________________ tor-relays
>> mailing list tor-relays at lists.torproject.org 
>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
> 
> 
> 
> _______________________________________________ tor-relays mailing
> list tor-relays at lists.torproject.org 
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)

iQIcBAEBAgAGBQJUKBfVAAoJEE2uQiaesOsL7NYP/21kcJiQF8uqUoDtkU5Lh2dx
5NqriUO49ngJMmx5HIJilt60Y1qjkyn6sun8lfsrI9u1PGxWXituoDfKfCwWrDyu
54MYyn2jaCK+qHdKhO+8NjNbOsUV844jZ+9jMpbEwRJ6MkSiSNwF0yhJZPVtfS+y
dPnK32y+6bOtk7n2M+8SQQxjnT4D1GSPGVU6UIpTHW2p/jwiwEL08/pVG+PlDP3c
IHy2jK94IUWWdaWvBpqTMjTDZRRxfRl/0xDIUmVKEwsGYSyTjbw3YflmLxNth9/5
PCvhDDATta6Uxsq+olxv0rM+Va0emQDoQ2ONL2zFH9bj+tt9BC/PtTmL+NY+4swd
lKEenJwfyCbWpjEz42VJ+amzVBGFzDMKCq7Wecc3TR8QAeitb/fRpaN5yGc565KW
8635BEnTxBiMHAPDesSvIECYDPdX47ARb40M0gQ5rbyMhPeFCcyNgpSCP2TWTJlq
c5t/rE0OqhrQVqkgqwamIfiizlbz5y1QUkF0v4MT9WqfXiDiP12+cvce7w+aY//i
2GX04ifaVGuTIF8KPpkaTKoYeNq6SbHVm5lgnvCqaalDPuo+uJT4zKs9NEDQ4Hh+
lHKjWYz7gfKMwWtiN2pSBALO20Q+J5gsZmTmyH8fKgeK9zaWFvhaBV/rz7Kkt3lB
RJxLwW6cD8tY0m4B4WTF
=ZDXC
-----END PGP SIGNATURE-----