Thanks for opening this discussion. We tried to open similar discussion with our member-base in yesterday's update. But as you correctly noted, not a lot of our members actually read our updates. Perhaps here is a better place to address these concerns.

I appreciate that you have been systematic in your discussion (and not all over the map) because it makes it easier to respond in a systematic and consistent way.

The way #steembasicincome works is if you send one still and say an account name, both of you will get 1 share. You can also get 1 share for every 2 Steem you delegate. The more shares you have the faster your 'subscription balance' increases. This is the balance that is used to give you votes. Also, if you upvote their comments and any of their 10 or so accounts, you can increase your balance by more than 100% of your vote.

We think of this as three separate value streams. While they aggregate into the total votes people receive, each stream has its own particular rules. In approaching this discussion, I would like to handle each stream separately.

• If you send 1 STEEM and specify an account name, you each get 1 unit.

This is the original mechanism that has never been changed since SBI launched almost 2 years ago. This was designed explicitly to be an account-level curation. You sponsor an account for 1 STEEM worth of lifetime upvotes. In doing so, you essentially receive 50% curation (you also get 1 STEEM present value of lifetime upvotes). This feature attracts very minimal abuse because the time to ROI is very long. It's the mechanism that contest uses, and that results in SBI supporting many valuable causes and accounts. We still believe this model is net-positive for Steem, and we don't plan to change it.

• You can also get 1 share for every 2 Steem you delegate.

There are pros and cons to this. It has been normal throughout Steem history for services to offer various levels of rewards to members that delegate. Delegation also allows members to support (and be supported by) Steem Basic Income without having to send liquid STEEM and trust us to keep delivering upvotes. While we have built a good track record of reliability, it's important to keep an open channel that allows members to support and benefit from our project without having to send liquid STEEM after initial enrollment.
Delegation is also a common way for whale accounts to get consistent large upvotes. We are considering making adjustments to the calculations to decrease the benefits of delegation some. My preference here would be for members to earn a fair return on delegation, while allowing it to skew toward supporting smaller accounts instead of whales. This is already happening organically because of the role our curation returns play in delegation rewards. If we decide more needs to be done after addressing upvoting bonuses, then we will.

• Also, if you upvote their comments and any of their 10 or so accounts, you can increase your balance by more than 100% of your vote.

This is the area that is our biggest concern, and the area we want to address. This was introduced to help us build a sustainable SP base and to help other programs do the same. Before HF21, there was very little abuse here (although not zero), and the small abuse that we saw was usually addressed quickly by our blacklists. (We have followed @steemcleaners and @buildawhale blacklists automatically since our automation was released. This is covered in our FAQ.)
Since HF22, many large accounts have shifted from bid-bots to vote-swapping services. This has upset the balance of abuse, and my own concerns about our voting trends have risen exponentially. In many cases, the accounts we vote are not bad enough for blacklisting, but not good enough to justify the votes that our upvoting rewards are returning to them.

We would like to phase out upvoting bonuses completely over a period of 10 to 12 weeks.

We believe there is a role for stake-based rewards within the overall content-oriented curation schema, but we do not believe that having stake should be the sole determinant of who gets rewarded.

SBI's native sponsoring system was designed so that members could 'crowdsource' support, stacking it to that point where it would be equivalent to whale-level support... an internal patreon-like model that offers greater stability and reduced risk of subscriber-flight.

Since we do actively support thousands of accounts and over 1500 accounts benefit from our upvoting rewards, we do not think it appropriate to turn the model on a dime and cancel upvoting rewards without opening discussion with our members.

While many other programs were able to change quickly to 'manual' curation, they were able to do so because their systems were entirely transactional. They made no promises and, once each paid upvote was delivered, owed nothing more to their customers . We have instead built long-term relationships and a community of active supporters that use SBI as a tool to support their passion projects. It would be unethical for us to make major changes without public discussion and an attempt to build consensus.

To that end, we will cross-post this long-form response into tonight's update, with a link to your post.

One problem with downvoting to your hearts content is down vote revenge. Personally, I find it is the worst reason to downvote. It's even worse than downvoting because you disagree with someone's opinion.

We agree with this completely. We have never engaged in revenge downvotes, although we have sometimes been more aggressive in penalizing other forms of abuse when we receive revenge downvotes. We do sometimes mark accounts that downvote us to not receive upvotes anymore, but that's a separate response.

When we've been downvoted, we try to engage and discuss potential issues with that person. In most cases, they have at least decided that we are not harmful, or that we are less harmful than other potential downvote targets. In some cases they continue downvoting us and we let them do so without retaliation.

We have never penalized any member or cancelled their subscriptions for speaking out against SBI (though when people are publicly critical, they often request us to cancel their subscriptions or assign to somebody else). One reason we advocate a crowd-sourced basic income is because a 'universal' basic income is extremely vulnerable to political changes and censorship.

We also never downvote over disagreement with content.