A) Social Dimensions and Notions of the Transaction Have Limited Wallet DesignUniversally

Most wallet software is designed with certain assumptions about what transactions are (or can be), built in.
If most in society have developed an assumption about what a transaction is, the manifestation of what our cryptocurrency wallets become (and the format in which the graphical user interfaces are developed to facilitate transactions) will tend to follow such a trend.

If a transaction (in which one sends, or transfers BCN) remains limited notionally only as an exchange of currency for goods, services, or other currency (etc.), there is a problem in terms of the capacity which we are allowing ourselves to develop and enjoy from decentralized systems. Certainly, this problem is not solely in BCN but can be seen in any other cryptocurrency wallet as well.

Up to this point, some technical challenges exist which have kept cryptocurrency and wallet developers from tackling the issue, as mentioned in the BCN developer's blog post, 'Future of Slacktivism: How 1,000,000 Likes Can Save Lives.' Thus, cryptocurrency wallets do not yet emulate natural giving systems to the degree that they could.

To sum up: The problem is that we have not yet re-envisioned the transaction to allow the user new ways to explore a transaction's full potential and offer the option of greater giving potential. However, we now have the means to do so.

B) Technical Limitations Currently Exist which Result in boundaries for Microgiving Option Development

(The following includes notes taken from correspondence with BCN developers, where these are included I've marked below with a (D).)

In BCN, some of following technical limitations apply when evaluating what could be done in developing various microgiving scenarios:

1) The sender: can make an extra output with a small sum (such as 1 output with dust) depending on certain conditions. (D) But the problem is how it will be spent later by the Receiver (considering there would be no ringsig partners for a receiver to spend anonymously).
The end result of this scenario (if utilized in a microgiving process) would be a loss of anonymity and high cost.

2) BCN presents users' choice, from "full anonymity" to "save all dust" effectively. Dust costs less than fee for the extra transaction size that it causes. This wide range of flexibility and the inherent "voluntary-ness" of the system means that users determine what is best for them. (This is not part of "the problem," but rather is provided as a statement of the condition which is necessary for BCN to work.)

3) (D) A Sender-centric approach: when a user is sending any transaction, the wallet automatically associates a percentage of its amount to a virtual donation "account". This may be purely virtual so that the user accumulates a significant amount that will be donated and doesn't involve any actual inputs. Once the sum is gathered, wallet suggests donating the accumulated sum and select the right inputs. This approach does not require particular outputs to be associated with the donation payment, but it may also accumulate dust outputs which would be sent to the donation address. The problem with this approach is it results in transaction(s) that accumulate dust outputs that point to a single sender, which reduces untraceability.

4) (D) A recipient-centric approach: when a user sends a transaction that involves dust, the dust output can be sent to a specified donation address. This one input doesn't require mixing as it looks like any ordinary dust that already exists, even though the recipient is not the user himself as usual. It's not the users that gather dust to be sent, but the recipients.

5) The recipient-centric approach is probably the best option to pursue in BCN for microgiving option development, and the door should be left open for random change / sum unrelated to dust inputs and of course any non-dust amount someone would want to donate. If the user wants the non-dust donations to occur in a bundled form the microgiving could be set to be broadcast based on some threshold level, e.g. when a purchase or transaction is done equal to or greater than "X." The user sets the threshold in the background of the wallet (essentially, a purchase or send level which would trigger when they wish to microgive), and provide in background preferences (settings) what amounts they wish to give and to what address those amounts will be sent. Though there are technical limitations, the recipient-centric approach, with additional details as described above, would allow for the ABIS change request to be developed (described in detail below).

Change Requested (Draft):

The BCN GUI wallet appears as follows:

Nothing about the startup appearance of the GUI wallet would change under this change request. Rather, a functional enhancement is proposed, which would be evident to the user in the settings area.

Essentially, the change request would involve a new Settings menu option being added that would include fields, so as to:

a) allow users to specify donation address(es) so that when transactions involve dust, the dust output can be sent to the user-specified donation address(es) in a recipient-centric model,

b) would also allow for random change / sum unrelated to dust inputs and any non-dust amount someone would want to donate,

c) If the user wants the non-dust donations to occur in a bundled form the microgiving could be set to be broadcast based on some threshold level, e.g. when a purchase or transaction is done equal to or greater than "X." The user sets the threshold in the background of the wallet (essentially, a purchase or send level which would trigger when they wish to give in some way), and provide in background preferences (settings) what amounts they wish to give and to what address those amounts will be sent.

New options that are being added under this change request in settings to accomplish this:

A dropdown menu in settings that would allow the user to "Configure Donations" at any time, which would look something like this when you select it from dropdown:

- "donation addresses" (these won't appear any different than other addresses, but there would be a field saying "donation addresses" where the addresses go, user fills this in and wallet saves it, can be changed anytime)
These allow dust output to be sent to the user-specified donation address(es) in a recipient-centric model,

(The above three submenu items proposed, along with the "configure donations" dropdown menu item, are the simplest elements of this proposal. The following proposed submenu item needs more review as to issues with its name and functionality, and out of this discussion I'd like to settle on a submenu element ("Donate only..." or "threshold value," or something else) that solves the problem mentioned below.)

Wallets can be designed to handle this as an internal accounting feature. For example, when enough "donation" value is accumulated it can be sent to the donation recipient by piggybacking on one of the user's daily transactions. This can be made clear to the user via the UI (individual donation amounts, current amount accumulated, and total amount sent).

Reasons and Justification:

Development of ways for users to remove the traditional boundaries and trappings of what transactions have meant will also enable people to turn the transactional culture on its head. This can occur by using BCN's uncensorable p2p technology* to allow the users to voluntarily specify the way resources should be directed in the world through "microgiving" as a part of any transaction they desire, or as part of every transaction if they so wish, much like the bees do when they bounce from flower to flower spreading pollen as they gather what they need for their hive.

*It is assumed here that financial censorship will be minimized by relying on BCN's installable desktop graphic wallet which is available for Linux, OSX, or Windows; which both insulates the users from known censorship problems historically associated with common web-based wallets or services, and functions as a simple, graphically user-friendly tool which streamlines the process of sending and receiving.

Social implications of the proposed Change Request (Additional Reasons and Justification)

Some level of automation (based on what user settings and preferences are) is more preferable to one-time or other manual donation systems, and also has a clear social benefit. The social benefit is that after a certain length of time, the user may wish to have giving become an ordinary (or potentially even larger) part of what they normally do as part of a transaction (but will always have full control over the direction of the user's resources, which is in sharp contrast with coercive systems which attempt to use force to use someone to give up financial resources for some "greater good"). In other words, in the system as proposed under this change request, the fluidity, or movement of data associated with what people consider to be "money" continues to be fluid, indeed, even more so, but rather than being closely held, the system is lubricated by virtue of an "arms open" rather than an "arms closed" approach to the transactional concept.

Because the entire concept is fully voluntary there are really a nearly infinite range of choices, essentially limited only by the technology, fees, and network limitations, when the user is contemplating who to provide a microdonation to and at what level and at what threshold the microdonation(s) will be broadcast, based on their wallet settings. The behavioral angle is that this amplifies a natural instinct within which transforms the action we are doing into one in which the resource is given naturally in a way that the individual decides is good, but which collectively results in a social good as a result of the actions of many individuals, associations, and so forth, that might ultimately use this function. There is an assumption in this process that people involved would not be coerced into using this tool ~ for example, if someone wanted to, they would contribute some microdonation to fix the City's broken-up roads, assuming that their town used BCN(ABIS) and had such a system, but I make the assumption that there would be no-one coercing them to do so ~ that they do so freely, voluntarily.

The system thus is presented without prejudice; the microgiving notion is left to the user; they could be microdonating to their 401k, to their City's line item account for the roads to fix potholes, to a homeless veteran's nonprofit, to their sick brother Bob, to anything or anyone that has an address. Reducing friction and evolving a giving process, I also assume and hope that we would in this model become more like the bees that share pollen as they bounce from flower to flower.

Areas that would be Visually Affected by Proposed Change:

BCN GUI Wallet ~ Settings (This would result in a new Settings section)

Draft Test Plan:

a) Solicit Community Input on this Draft Change Request (DCR)
b) Alter DCR and Republish as Change Request (CR) Following Initial Review Period
c) Developers take over CR in Development Funnel
d) Code is Developed to Correspond to CR
e) Test and Retest Phase

BCN community input is sought on this idea through bytecointalk, as well as any bitcointalk referring or linking to this topic, and any other extended avenue for discussion (your social media of choice). I'll consider this bytecointalk thread a "start first" point for where I look for comments, so if there is discussion on it that occurs outside of here (twitter, bitcointalk, etc) please don't hesitate to drop a link to it in this thread so I can see it and listen to the input.

1) In alternative to changes as proposed, one alternative is to change the proposal based on any community input received. (This is why it's out here, so that the critical community input can be gotten and any changes needed can be incorporated.)

2) Wallet-based approach with unique background preferences that can be set by the user and provides threshold for when microgiving occurs is current approach (as proposed in CR), another approach may be the same wallet-based approach that has less preferences for user to be concerned with, but still provides the ability for recipients to specify addresses where inbound dust will go and where they'd like to donate occasionally.

3) Do nothing. No change is required.

Priority to Implement

TBD ~ Potentially, one of the next releases (This will be better known once the Draft Change Request is republished to a Change Request after community input and review)

Other Notes

While this change request is for these ideas to be integrated into BCN, I also hope to eventually see them integrated into other currencies and areas as well ~ and so, it's my intent to make ABIS as a concept more interoperable.Please let me know if you have any thoughts on how that should best happen, including any suggestions you have for licensing or other issues ~ the ABIS repository is currently GPL-v3, see: https://github.com/ABISprotocol/ABIS/blob/master/LICENSE Such issues as interoperability, potential integration of ABIS microgiving concept(s) into other currencies, what license should be on the ABIS repository, etc., are not technically part of the scope of this change request discussion, but I welcome any input I receive on those issues, and the best pathway to do so would be either via to open a github issue at https://github.com/abisprotocol/abis or contact me via one of the methods shown in my signature.

Thanks for helping with the process of this Draft Change Request review and comment.

Hello Odinn and thank you for submitting your Change Request for the community discussion.

I can confirm that Bytecoin dev team has been communicating with Odinn on ABIS implementation for Bytecoin. The discussion was ongoing from Fall 2014 and by June 2015 we've reached an agreement to implement ABIS microdonations in Bytecoin Wallet after the Change Request is discussed and finalized.

The required actions described in the main post of this thread correlate with our vision. Once CR is ready, we are going to schedule its release.

I'd like to invite everyone to share their thoughts in this thread. Other Bytecoin dev team members are going to comment too.

To start with, dust issue indeed exists in Bytecoin and all other CryptoNote based currencies.
There are two approaches to how dust can be defined:

1. A very small output roughly not more than 100 atomic units
2. Any output which is less than the standard fee (0.01 BCN, or 1,000,000 atomic units)

Dust is too small to be spent in an isolated transaction. What's more, dust inputs (especially the ones described in #1) rarely have a mixing partner. CryptoNote allows to send transactions with one input not being mixed (in a mixed transaction) without any consequences for untraceability. However, accumulating too much dust may lead to untraceability rendered unachievable for certain transactions that involve several unmixable inputs.

Dust is usually created in form of change from a transaction and is returned back to the user's balance.

The recipient-centric approach allows to send the dust outputs not back to the sender (in form of change), but sending it to a public key belonging to a 3rd party recipient. Thus the outputs of a transaction may be sent to three parties: the recipient (transferred sum), the sender (change sum), donation recipient (dust/donation sum). Such an approach allows to move untraceability concerns to the donation recipients, who generally do not have rationale to increase their anonymity through untraceability.

Quote:The end result of this scenario (if utilized in a microgiving process) would be a loss of anonymity and high cost.

This is a rough statement and is not generally correct. Even though lack of inputs for mixing can, under certain circumstances, decrease the effect of or cancel the untraceability property, it does not automatically results in a loss of anonymity. Still, user's privacy would be protected with unlinkability property (no way to link outputs to the corresponding user's addresses, learn their balances and financial operations). I'd personally avoid "anonymity loss" statement here.

The question about the Change Request itself that are not currently clear to me:

1. Should it be a general Settings menu, or a new Donation one. Ideally, the user would like to know how much has been donated to various addresses. What's more, if threshold donation is involved, the user should be able learn current balance (under threshold).

Thus, the extra information non-attributable to Settings menu only may call for a separate interface for microdonations.

2. Should there be any preset donation addresses and how they should be distributed. Such a mechanism would increase centralization and facilitate donations to a smaller number of addresses. On the other hand, it simplifies getting started with donations out-of-box.

3. What microdonations use cases should be covered:
- dust donation (naturally, yes, with each tx)
- threshold donations (accumulating until being sent in a separate donation-only tx)
- donations in case tx sum is greater than X (with each such a tx?)
- random donations, 1-5% of the sum depending on the available outputs (with each tx)

In my opinion, the last choice is in line with dust donations. What's more, it provides a unified experience for the user. So either you won't to donate only the irrelevant dust, or would like to contribute more.

4. How the donations should be introduced to the user in the first place when he first launches the Wallet.

These are my thoughts and I'm waiting for other Bytecoin team members to contribute to the discussion.

Thanks, and I look forward to this process of collaboration with the Bytecoin community.

Responding briefly,

(07-04-2015, 01:19 PM)Ullo Wrote: (...)
Dust is too small to be spent in an isolated transaction. What's more, dust inputs (especially the ones described in #1) rarely have a mixing partner. CryptoNote allows to send transactions with one input not being mixed (in a mixed transaction) without any consequences for untraceability. However, accumulating too much dust may lead to untraceability rendered unachievable for certain transactions that involve several unmixable inputs.

Dust is usually created in form of change from a transaction and is returned back to the user's balance.

The recipient-centric approach allows to send the dust outputs not back to the sender (in form of change), but sending it to a public key belonging to a 3rd party recipient. Thus the outputs of a transaction may be sent to three parties: the recipient (transferred sum), the sender (change sum), donation recipient (dust/donation sum). Such an approach allows to move untraceability concerns to the donation recipients, who generally do not have rationale to increase their anonymity through untraceability.

This makes sense, and I suppose a natural follow-up inquiry is what would be the best way to implement this (recipient-centric) method in consideration of the general description above and also in consideration of any recipient(s) that wish to retain untraceability for most of their transactions. If too much dust is accumulated, then the untraceability level desired is unachievable, if on the other hand not so much is accumulated, and it is fluid, then it would seem that level(s) desired are more acheivable.

Quote:The end result of this scenario (if utilized in a microgiving process) would be a loss of anonymity and high cost.

This is a rough statement and is not generally correct. Even though lack of inputs for mixing can, under certain circumstances, decrease the effect of or cancel the untraceability property, it does not automatically results in a loss of anonymity. Still, user's privacy would be protected with unlinkability property (no way to link outputs to the corresponding user's addresses, learn their balances and financial operations). I'd personally avoid "anonymity loss" statement here.

It sounds as though I put too broad-brush a stroke on that statement. Let me know if there would be some good alternative language that would be better to include.

OK, that "amount" bit you referred to above, is corresponding to the donation addresses. In this case, here you've clicked on a Configure Donations item in Settings, then you get to Donation Addresses (enter these) which indicate where the dust is going to go. Now the question is here: Is an "amount" field required at all, or is the system going to handle that for the user? At first I thought, this is exactly the kind of thing that the wallet should be able to handle. But then I thought, the user should stipulate some kind of amount. Ordinarily, however, dust is so small, that the user is not going to be interested in entering said numbers.
So in terms of the donation addresses that allow dust output to be sent to the user-specified donation address(es) in a recipient-centric model as proposed in the change request, maybe the "amount" field as proposed above isn't needed... maybe the wallet just handles the "amount," because it's dust. It may simply be something that the user never will have to worry about, thus the donation addresses and labels would be the only things changed by the user. Let me know what you think about that.

(07-04-2015, 02:39 PM)Ullo Wrote: The question about the Change Request itself that are not currently clear to me:

1. Should it be a general Settings menu, or a new Donation one. Ideally, the user would like to know how much has been donated to various addresses. What's more, if threshold donation is involved, the user should be able learn current balance (under threshold).

Thus, the extra information non-attributable to Settings menu only may call for a separate interface for microdonations.

2. Should there be any preset donation addresses and how they should be distributed. Such a mechanism would increase centralization and facilitate donations to a smaller number of addresses. On the other hand, it simplifies getting started with donations out-of-box.

3. What microdonations use cases should be covered:
- dust donation (naturally, yes, with each tx)
- threshold donations (accumulating until being sent in a separate donation-only tx)
- donations in case tx sum is greater than X (with each such a tx?)
- random donations, 1-5% of the sum depending on the available outputs (with each tx)

In my opinion, the last choice is in line with dust donations. What's more, it provides a unified experience for the user. So either you won't to donate only the irrelevant dust, or would like to contribute more.

4. How the donations should be introduced to the user in the first place when he first launches the Wallet.

These are my thoughts and I'm waiting for other Bytecoin team members to contribute to the discussion.

My answers to this last part ~

- Keep it as simple as possible
- I was thinking of new option in general Settings menu (Configure Donations) which would then have further dropdowns which correspond to it. But if this seems like it would add too much to Settings, then Donations could be added as a menu item apart from Settings.
- Regarding No. 2, I think the answer is no
- Regarding No. 3, yay to all of the use cases (but that's just me) :-)

I suppose we can start from dust that is generated while sending change back to user. We can easily add the possibility to specify donation address in wallet settings. All dust will be optionally (in case user explicitly allowed) sent to this donation address on every transaction.

At the present moment there is no good way to accumulate dust outputs because network will not accept zero-fee transactions (this is memory pool level restriction, not a protocol-level one). We have to leave some "window" in each block for free transactions in order to make it possible to use large number of dust outputs.

I suppose we can start from dust that is generated while sending change back to user. We can easily add the possibility to specify donation address in wallet settings. All dust will be optionally (in case user explicitly allowed) sent to this donation address on every transaction.

At the present moment there is no good way to accumulate dust outputs because network will not accept zero-fee transactions (this is memory pool level restriction, not a protocol-level one). We have to leave some "window" in each block for free transactions in order to make it possible to use large number of dust outputs.

This way I see two steps in the near future we have to take:

1. add "donation address" field to wallet settings

2. allow zero-fee transactions (probably the way Bitcoin does it)

These two steps will make the first ABIS user-case live.

Hello amjuarez,

Thanks for this insight. I have the following to add to build on your remarks:

a) For the ABIS implementation in the BCN GUI wallet, it is assumed that microgiving amounts would have a cost (e.g. would not be without a fee in the network), but that fee flexibility would be retained for microgiving scenarios.

b) Some ""window" in each block" as you have described may need to be designed such that it woud be left or added to block(s) [in your words, in each block] for free transactions; alternatively, such a "window" could be limited so that it could not be abused (used maliciously against the network). More on that to follow in section (d) below.

c) As Charlie Lee of Litecoin (who also advises Coinbase) recently pointed out in Coin Telegraph, commenting about current problems in bitcoin regarding instances of dust which end up overloading a network, "the fix implemented in Litecoin is just to charge the sender a fee for each tiny output he creates. For example, in this specific attack, the sender is charged one fee for sending to 34 tiny outputs of 0.00001 BTC. With the fix, that fee would be 34 times as much. So it would cost the attacker a lot more to perform the spam attack."

I disagree with Charlie Lee that such a "fix" would be appropriate for bitcoin, and I feel it was extreme for litecoin as well to have taken a policy that simply set a high-fee policy for every transaction rather than allowing for a combination of natural fee market adjustment and (in bitcoin) limitfreerelay. What I am alluding to here is that there has evolved out of bitcoin's recent dust problems, a transaction fee market largely unhindered by policy, and users have the ability to change their limitfreerelay figure. While this defaults to 15, reducing limitfreerelay to a lower number will reduce the speed at which the mempool can grow due to free transactions. Thus the issue is not simply "the fee" in bitcoin (and similar but different coins, e.g. Freicoin, Huntercoin, etc.), but one could (in a bitcoin context) avoid going nuclear in fee policies simply by adjusting the default figure to (5 or 8) in bitcoin.conf as follows - something like this:

Code:

limitfreerelay=5

This is admittedly a short-term solution to some of the more complex problems facing bitcoin. However, to sum up, I think that it would be mistaken to impose a "fix" of a high-fee policy for every transaction (in bitcoin or in any similar cryptocurrency), especially when the bitcoin developers appear to have (mostly) worked out some things in a more reasonable way (1, 2) to address these very problems mentioned above without having to add the fee insanity.

It may be even that they've overreacted to some of the dust-related problems that have affected bitcoin, as in the past, such issues have come up and haven't been a lasting problem; in my view, current "dust problems" affecting that currency should be interpreted as an opportunity to look at the dust in the context of microgiving.

Note: I've added some of my own remarks to the pull request area on github where people are trying to revive Charlie Lee's "fix" for bitcoin. Really... that died in 2012, still, they cannot let it lie! I felt compelled to comment. Please link above if you are interested in the bitcoin development discussion.

d) Moving back again from bitcoin to bytecoin (BCN), I wanted to cover some of the issues specific to that, where potentially many zero, or minimum fee transactions can lead to transaction flooding. (I say potentially, because this might actually not occur, depending upon the design of how the wallet handles them and how the system is developed to respond to increases in numbers of such transactions.) There is the issue of how Bytecoin will handle a growing number of transactions with its current limit of 12 transactions per second (approx., as that limit could be changed, but that is the current limit at the time of this post). How might this be addressed? Dust is defined as (per Ullo)
1. A very small output roughly not more than 100 atomic units
2. Any output which is less than the standard fee (0.01 BCN, or 1,000,000 atomic units)
In Bytecoin (BCN) we don't have the problem of serious blockchain bloating; the system still allows the limit to slowly grow with the time if necessary. Transaction size does not need to be limited explicitly, it has "adaptive limits."
Thus, to couple the process of having zero-fee transactions along with the recipient-centric approach (user sends transaction involves dust, the dust output can be sent to a specified donation address) might be assisted in the following ways:
- wallet could be configured to distribute dust output only at specific times (e.g. only allows no more than once every hour, or in such a way that the users' chosen options do not inadvertently overload the network)
- Alternately, the setting could be configured to trigger the microgiving with dust to occur once a week or at random times such that the the likelihood of a "flood" is minimized
- Option to enter fee could be added to prioritize movement of dust. (Since this wouldn't make sense for a single dust txout, the idea here is that there would be various dust items bundled by the wallet and the user would have the option of entering a fee to have them broadcast all at once. The wallet would calculate the appropriate fee and have them then go altogether as part of a single tx.
- Add-on, assuming an external functionality is required (e.g. social interaction such as with twitter to enhance the project, with cryptocurrency units serving as likes), multiple microtransactions would continue from within the GUI wallet and sending a single combined transaction to the reservation's address, say, every hour; linking data from this activity to the add-on.

I'd say that micro-donation is indeed an interesting opportunity for Bytecoin to help solve social issues and gain more traction. Good to see that ABIS protocol can be implemented in Bytecoin.

Comparing amjuarez's comment:

Quote:allow zero-fee transactions (probably the way Bitcoin does it)

and Bytecoin recent roadmap update:

Quote:New transaction priority rules

This feature is a major improvement of transaction rules for Bytecoin network. It reserves a part of each block for specific zero-fee transactions. The latter are likely to emerge as a result of micro-donation protocol implementation and in case a large amount of tiny inputs is involved.

I assume that Bytecoin team has taken the proposal seriously.

I have a number of questions that might be relevant to the design decision:

1) How many dust outputs are created in Bytecoin network per day? Is there an estimate of how much Bytecoin network can donate in general at the moment? If this amount is too lay, it may be sensible to introduce non-dust donation from day one.

2) There is an issue of informing user on the donation activity. Even though dust should be irrelevant to him, it may be psychologically uncomfortable to know that a part of your money has been sent to a 3rd party without you knowing about it. A possible solution may be a popup on first launch that informs user on the donation and asks him whether he'd like to donate a larger sum in each transaction.

3) How the wallet should handle a transaction? If I am sending a sum to an address, what happens if donation exceeds the change? A situation should be avoided when my recipient has received less money than he should have due to a donation activity.

Quote:Thus, to couple the process of having zero-fee transactions along with the recipient-centric approach (user sends transaction involves dust, the dust output can be sent to a specified donation address) might be assisted in the following ways:
- wallet could be configured to distribute dust output only at specific times (e.g. only allows no more than once every hour, or in such a way that the users' chosen options do not inadvertently overload the network)
- Alternately, the setting could be configured to trigger the microgiving with dust to occur once a week or at random times such that the the likelihood of a "flood" is minimized
- Option to enter fee could be added to prioritize movement of dust. (Since this wouldn't make sense for a single dust txout, the idea here is that there would be various dust items bundled by the wallet and the user would have the option of entering a fee to have them broadcast all at once. The wallet would calculate the appropriate fee and have them then go altogether as part of a single tx.
- Add-on, assuming an external functionality is required (e.g. social interaction such as with twitter to enhance the project, with cryptocurrency units serving as likes), multiple microtransactions would continue from within the GUI wallet and sending a single combined transaction to the reservation's address, say, every hour; linking data from this activity to the add-on.

I assume that the micro-donation through dust outputs does not change anything from the current network perspective. As amjuarez mentioned, the dust output will be sent not as a change back to the user, but to a charity. Thus, it is still one original transaction no matter where the dust goes. If that's correct, there should be no flood associated with the micro-donations giving.

I'm not sure what is implied under new tx priority rules, but it seems to be related to the recipient of the micro-donations that has "a lot of tiny inputs".

(07-15-2015, 06:29 PM)Rias Wrote: I assume that the micro-donation through dust outputs does not change anything from the current network perspective. As amjuarez mentioned, the dust output will be sent not as a change back to the user, but to a charity. Thus, it is still one original transaction no matter where the dust goes. If that's correct, there should be no flood associated with the micro-donations giving.

I'm not sure what is implied under new tx priority rules, but it seems to be related to the recipient of the micro-donations that has "a lot of tiny inputs".

That is actually the case. We were discussing that if a user has dust inputs only, it is likely that he won't be able to send any transaction if there's fee. In order to bypass this issue we've introduced the new tx priority rules into our roadmap. It serves for the purpose of inputs optimization.

For the charitable organization that accepts Bytecoin dust it would imply a new option in Bytecoin Wallet. Something like "optimize my inputs in the background". As a result, the free transactions would end up with tiny inputs reorganized into a small number of larger outputs available in your wallet. This would greatly simplify user experience and allow spending dust donations. However, I guess this feature is out of scope of this discussion.

Quote:1) How many dust outputs are created in Bytecoin network per day? Is there an estimate of how much Bytecoin network can donate in general at the moment? If this amount is too lay, it may be sensible to introduce non-dust donation from day one.

We're going to calculate the figures. I'll provide you with them as soon as they are ready.

Quote:3) How the wallet should handle a transaction? If I am sending a sum to an address, what happens if donation exceeds the change? A situation should be avoided when my recipient has received less money than he should have due to a donation activity.

The idea was to reroute change to donation addresses instead of yours as it is today. Under this condition, if there's no dust change left, it won't be sent.

(07-15-2015, 06:29 PM)Rias Wrote: I assume that the micro-donation through dust outputs does not change anything from the current network perspective. As amjuarez mentioned, the dust output will be sent not as a change back to the user, but to a charity. Thus, it is still one original transaction no matter where the dust goes. If that's correct, there should be no flood associated with the micro-donations giving.

I'm not sure what is implied under new tx priority rules, but it seems to be related to the recipient of the micro-donations that has "a lot of tiny inputs".

That is actually the case. We were discussing that if a user has dust inputs only, it is likely that he won't be able to send any transaction if there's fee. In order to bypass this issue we've introduced the new tx priority rules into our roadmap. It serves for the purpose of inputs optimization.

For the charitable organization that accepts Bytecoin dust it would imply a new option in Bytecoin Wallet. Something like "optimize my inputs in the background". As a result, the free transactions would end up with tiny inputs reorganized into a small number of larger outputs available in your wallet. This would greatly simplify user experience and allow spending dust donations. However, I guess this feature is out of scope of this discussion.

Quote:1) How many dust outputs are created in Bytecoin network per day? Is there an estimate of how much Bytecoin network can donate in general at the moment? If this amount is too lay, it may be sensible to introduce non-dust donation from day one.

We're going to calculate the figures. I'll provide you with them as soon as they are ready.

Quote:3) How the wallet should handle a transaction? If I am sending a sum to an address, what happens if donation exceeds the change? A situation should be avoided when my recipient has received less money than he should have due to a donation activity.

The idea was to reroute change to donation addresses instead of yours as it is today. Under this condition, if there's no dust change left, it won't be sent.

Thank you Rias and Ullo, while I am also looking forward to these figures, while reading this I realize that the issues as you have mentioned them here make this simpler than I thought it would be, that is, the matter of my concern about "floods" will not be such an issue. I have also recently read the bytecoin developers' post about unconfirmed transactions pool synchronization solution from July 15, 2015 and that was very helpful.

Very glad to be here, and looking forward to further comments from the Bytecoin community.

There is an another donation option we are thinking about: donation mining.

Donation miners aren't necessarily Bytecoin or any other cryptocurrency users. They are mining in favor of some charity or some project. This use case is very easy to implement: from the charity side they have to provide a BCN address and a link to BCN miner or BCN wallet with an embedded miner. Miners will send shares to any pool using charity's address instead of their own. This looks like a feasible way to donate using only CPU power.

My question can be a little out of technical sphere, but how do we decide what organizations we would like to donate to? Do we make a list of some organizations, assigning a BCN address to each of them? And how do we choose them in the first place? Do we cast a vote or just define some organizations that might share same values with the Bytecoin developers and users? Or will those donations be collected only to support the further development of the Bytecoin-oriented projects, e.g. wallets? And who should decide that?

There is an another donation option we are thinking about: donation mining.

Donation miners aren't necessarily Bytecoin or any other cryptocurrency users. They are mining in favor of some charity or some project. This use case is very easy to implement: from the charity side they have to provide a BCN address and a link to BCN miner or BCN wallet with an embedded miner. Miners will send shares to any pool using charity's address instead of their own. This looks like a feasible way to donate using only CPU power.

What is your opinion?

Hello amjuarez,

I hadn't thought of that use case at all! Thank you for bringing it up. This sounds like it would be potentially significant for nonprofits or organizations of any variety which have as their purpose (temporary or permanent) to be recipients (as an example) where the organization has a published charitable purpose (as one example), and at the same time the miner(s) ~ user determines from wallet what is the recipient within the context of the BCN wallet with an embedded miner, using the example you provided above ~ then user would specify in their Donation Settings (or however the Settings are to be configured for the GUI Wallet for this) the amount or percentage of the mining proceeds that would be sent to the user's selected charity.
Note of course there is no list of approved charities or individuals, the user decides what to do and it is entirely voluntary and contingent upon whether or not the organization or individual has a BCN address, and due diligence of the part(ies) involved.
This is a great idea and I think it should be added to the use cases already contemplated.

My question can be a little out of technical sphere, but how do we decide what organizations we would like to donate to? Do we make a list of some organizations, assigning a BCN address to each of them? And how do we choose them in the first place? Do we cast a vote or just define some organizations that might share same values with the Bytecoin developers and users? Or will those donations be collected only to support the further development of the Bytecoin-oriented projects, e.g. wallets? And who should decide that?

Hello evelknievel,

Thanks for asking these questions. How to decide and what sort of mechanism... would a vote be cast on how funds would be spent.. will the donations only be collected for certain projects... I think you have asked exactly the right sort of questions. It's the matter of not only what would someone do with this but how would end users be empowered (or not) by it and what would be the limitations in the end of this sort of proposal when implemented.

To sum it up, how it's decided as to what persons or organizations you would like to donate to, would be entirely up to you as an individual. The wallet user controls everything about what happens.

So for example, if you wanted to have something go to your sick brother Bob, that's your choice.
If you wanted to donate to yourself (say set aside for your 401k or gold purchases), that's your choice too.
If you wanted to donate something to your own local government or town or village to contribute or sustain any line item in the budget of your locale (say, for fixing potholes in your local roads), you are free to.
If you wanted to develop entirely independent and anarchistic projects to create autonomous communities sustained by your funds, you are free to.

And so on and so forth, limited only by your imagination, really. However, the recipients must have BCN addresses and must themselves be willing to use the software (a GUI wallet).

Part of your question was,

"Do we cast a vote or just define some organizations that might share same values with the Bytecoin developers and users? Or will those donations be collected only to support the further development of the Bytecoin-oriented projects, e.g. wallets?"

Since each GUI wallet user as an individual (node) decides individually what his/her donations are going to be, to what degree they are going to occur, and to whom, I'd say that there is actually no need for any votes to occur on the matter. Each individual chooses as they see fit and the collective result across the network is what happens. However, if a group of users collude (through messaging or social media for example) to make a certain address a popular recipient for a certain time period, this will have the practical effect of a vote for that time period.

The donations aren't being collected to support further development of Bytecoin-oriented projects in this proposal, but I imagine that it would be easy enough to include this as an option if you wanted to. For example, as part of the implementation, you could include an option in the wallet in the settings area that would ask the user if they want to designate some microdonations (dust) for Bytecoin development. This could be an option that the user could turn on or off with a small checkbox. It may not be necessary, but in any event, I don't see a problem with such an option so long as it is off by default upon initial installation, and the user has the option to turn it on or off.

Key to this entire proposal is that everything is voluntary and entirely within the control of the user.

I hope that answers your questions. Let me know if there's anything else in followup to this that I can answer.

I'm planning on revising this Draft Change Request consistent with the input I've received here. It will be republished as a Change Request (finalized). Please feel free to continue to add comments; note I will finalize the Change Request around the evening of August 4th. (I'll use this same thread to republish it in.)

Next steps I will take are as follows:

- Alter DCR (Draft Change Request) and Republish as CR (Change Request) Following Initial Review Period (around Aug. 4 2015)
at that point,
- Developers take over CR in Development Funnel
- Code is Developed to Correspond to CR
- Test and Retest Phase
Further details on development process can be seen athttps://bytecoin.org/blog/software-testing-process/

Please continue to add comments and questions here on this change request.

I really like the idea of of using cryptocurrency as a means to affect change in the world through "slacktivism" and the ABIS protocol seems like a good step in that direction. I agree with you that the recipient based approach is probably the best way to approach this.

Quote:The recipient-centric approach is probably the best option to pursue in BCN for microgiving option development, and the door should be left open for random change / sum unrelated to dust inputs and of course any non-dust amount someone would want to donate.

This makes sense to me as the easiest way for a user to participate in microgiving, while also preserving untraceability. Perhaps there could be an option for senders for whom untraceability isn't a high priority, to opt into the sender specific option you list. However I'm not familiar with BCN enough to know if the reduced untraceability for this proposed sender specific microdonation, would "bleed" into other transactions, reducing the sender's untraceability on other transactions.
As someone who wasn't intimately familiar with the BCN project, the "Future of Slacktivism" post piqued my interest. If we can get to the point where cryptocurrency can handle Twitter/FB level microdonations in the form of 'likes' then that'd be an amazing accomplishment and would certainly do a lot to help change the world for the better. Good luck, I'm excited to see where this leads.

A) Social Dimensions and Notions of the Transaction Have Limited Wallet DesignUniversally

Most wallet software is designed with certain assumptions about what transactions are (or can be), built in.
If most in society have developed an assumption about what a transaction is, the manifestation of what our cryptocurrency wallets become (and the format in which the graphical user interfaces are developed to facilitate transactions) will tend to follow such a trend.

If a transaction (in which one sends, or transfers BCN) remains limited notionally only as an exchange of currency for goods, services, or other currency (etc.), there is a problem in terms of the capacity which we are allowing ourselves to develop and enjoy from decentralized systems. Certainly, this problem is not solely in BCN but can be seen in any other cryptocurrency wallet as well.

Up to this point, some technical challenges exist which have kept cryptocurrency and wallet developers from tackling the issue, as mentioned in the BCN developer's blog post, 'Future of Slacktivism: How 1,000,000 Likes Can Save Lives.' Thus, cryptocurrency wallets do not yet emulate natural giving systems to the degree that they could.

To sum up: The problem is that we have not yet re-envisioned the transaction to allow the user new ways to explore a transaction's full potential and offer the option of greater giving potential. However, we now have the means to do so.

B) Technical Limitations Currently Exist which Result in boundaries for Microgiving Option Development

(The following includes notes taken from correspondence with BCN developers, where these are included I've marked below with a (D).)

In BCN, some of following technical limitations apply when evaluating what could be done in developing various microgiving scenarios:

1) The sender can make an extra output with a small sum (such as 1 output with dust) depending on certain conditions. (D) But the problem is how it will be spent later by the Receiver (considering there would be no ringsig partners for a receiver to spend anonymously). A user's privacy would remain protected with unlinkability property in this scenario.

2) BCN presents users' choice, from "full anonymity" to "save all dust" effectively. Dust costs less than fee for the extra transaction size that it causes. This wide range of flexibility and the inherent "voluntary-ness" of the system means that users determine what is best for them. (This is not part of "the problem," but rather is provided as a statement of the condition which is necessary for BCN to work.)

3) (D) A Sender-centric approach: when a user is sending any transaction, the wallet automatically associates a percentage of its amount to a virtual donation "account". This may be purely virtual so that the user accumulates a significant amount that will be donated and doesn't involve any actual inputs. Once the sum is gathered, wallet suggests donating the accumulated sum and select the right inputs. This approach does not require particular outputs to be associated with the donation payment, but it may also accumulate dust outputs which would be sent to the donation address. The problem with this approach is it results in transaction(s) that accumulate dust outputs that point to a single sender, which reduces untraceability.

4) (D) A recipient-centric approach: when a user sends a transaction that involves dust, the dust output can be sent to a specified donation address. This one input doesn't require mixing as it looks like any ordinary dust that already exists, even though the recipient is not the user himself as usual. It's not the users that gather dust to be sent, but the recipients.

5) The recipient-centric approach is probably the best option to pursue in BCN for microgiving option development, and the door should be left open for random change / sum unrelated to dust inputs and of course any non-dust amount someone would want to donate. If the user wants the non-dust donations to occur in a bundled form the microgiving could be set to be broadcast based on some threshold level, e.g. when a purchase or transaction is done equal to or greater than "X." The user sets the threshold in the background of the wallet (essentially, a purchase or send level which would trigger when they wish to microgive), and provide in background preferences (menu and / or settings) what amounts they wish to give and to what address those amounts will be sent. Though there are technical limitations, the recipient-centric approach, with additional details as described above, would allow for the ABIS change request to be developed (described in detail below).

Change Requested (Final):

The BCN GUI wallet appears as follows:

Nothing about the startup appearance of the GUI wallet would change under this change request. Rather, a functional enhancement is proposed, which would be evident to the user as a new menu option.

Essentially, the change request would involve a new menu option being added that would include fields, so as to:

a) allow users to specify donation address(es) so that when transactions involve dust, the dust output can be sent to the user-specified donation address(es) in a recipient-centric model,

b) would also allow for random change / sum unrelated to dust inputs and any non-dust amount someone would want to donate,

c) If the user wants the non-dust donations to occur in a bundled form the microgiving could be set to be broadcast based on some threshold level, e.g. when a purchase or transaction is done equal to or greater than "X." The user sets the threshold in the background of the wallet (essentially, a purchase or send level which would trigger when they wish to give in some way), and provide in background preferences (donation menu and / or settings) what amounts they wish to give and to what address those amounts will be sent.

New options that are being added under this change request in menu (and / or settings) to accomplish this:

A new menu option, called Donations that would allow the user to "Configure Donations" at any time, which would look something like this when you select it from dropdown:

- "donation addresses" (these won't appear any different than other addresses, but there would be a field saying "donation addresses" where the addresses go, user fills this in and wallet saves it, can be changed anytime)
These allow dust output to be sent to the user-specified donation address(es) in a recipient-centric model, which the user can then alter at any time,

- "amount" corresponding to donation addresses, user fills this in, and wallet saves it, can be changed anytime
(These would be for non-dust amounts.)
(For dust amounts, a different setting or submenu area is needed; due to the quantities involved, the wallet should prompt with dust figures (an alternate possibility is allowing the user to tailor the dust amount by having a "dust button" which moves the dust level up or down with interactive arrow icons, thus enabling the user to specify how much they want to give from the dust context). The user should be able to see how much has been donated to various addresses. If a threshold donation is involved, the user should be able learn current balance (under threshold).)

- "label" for donation addresses (optional item to fill in)

(The above three submenu items proposed, along with the "configure donations" dropdown menu item, are the simplest elements of this proposal. The following proposed submenu item indicates an area of additional functionality which the user specifies.)

- Submenu item of "Donate only when transaction is ___ or greater" (under the "configure donations" as proposed in menu). The value would be the number of BCN (threshold value of a transaction) which will trigger donation(s) higher than dust values. In other words, by reading the submenu option the user would see exactly what it means, and if the user chose to fill in the field in this menu area, then this would be a way for the user to stipulate, for example, at what transactional levels the user wishes to make donations that are greater than the system dust value. In this case, the wallet, for transactions involving dust, would still be sending dust output to the user-specified donation address(es) in the recipient-centric model proposed by this change request, but a suggestion is being made here for how non-dust donations might be handled under the settings proposed as well.
If "Donate only when transaction is ___ or greater" is included as a submenu option, then additional corresponding fields must also be provided below it which allow the user to enter further donation addresses.

Wallets can be designed to handle this as an internal accounting feature. For example, when enough "donation" value is accumulated it can be sent to the donation recipient by piggybacking on one of the user's daily transactions. This can be made clear to the user via the UI (individual donation amounts, current amount accumulated, and total amount sent).

- Option to offer dust contributions for BCN development - This can be incorporated as part of the development and implementation process for ABIS, but if it is, is requested to be as a "checkbox" style in settings with "default off" (e.g., on install of the wallet, the option is unchecked and it is up to the user if the option to contribute would be selected)

(Future possibilities beyond the GUI wallet)

- Add-on, assuming an external functionality is required (e.g. social interaction such as with twitter or other external interaction such as p2p market add-on or pool add-on to enhance the project, with cryptocurrency units serving as likes), multiple microtransactions would continue from within the GUI wallet and sending a single combined transaction to an address, say, every hour; linking data from this activity to the add-on.

Reasons and Justification:

Development of ways for users to remove the traditional boundaries and trappings of what transactions have meant will also enable people to turn the transactional culture on its head. This can occur by using BCN's uncensorable p2p technology* to allow the users to voluntarily specify the way resources should be directed in the world through "microgiving" as a part of any transaction they desire, or as part of every transaction if they so wish, much like the bees do when they bounce from flower to flower spreading pollen as they gather what they need for their hive.

*It is assumed here that financial censorship will be minimized by relying on BCN's installable desktop graphic wallet which is available for Linux, OSX, or Windows; which both insulates the users from known censorship problems historically associated with common web-based wallets or services, and functions as a simple, graphically user-friendly tool which streamlines the process of sending and receiving.

Social implications of the proposed Change Request (Additional Reasons and Justification)

Some level of automation (based on what user settings and preferences are) is more preferable to one-time or other manual donation systems, and also has a clear social benefit. The social benefit is that after a certain length of time, the user may wish to have giving become an ordinary (or potentially even larger) part of what they normally do as part of a transaction (but will always have full control over the direction of the user's resources, which is in sharp contrast with coercive systems which attempt to use force to use someone to give up financial resources for some "greater good"). In other words, in the system as proposed under this change request, the fluidity, or movement of data associated with what people consider to be "money" continues to be fluid, indeed, even more so, but rather than being closely held, the system is lubricated by virtue of an "arms open" rather than an "arms closed" approach to the transactional concept.

Because the entire concept is fully voluntary there are really a nearly infinite range of choices, essentially limited only by the technology, fees, and network limitations, when the user is contemplating who to provide a microdonation to and at what level and at what threshold the microdonation(s) will be broadcast, based on their wallet settings. The behavioral angle is that this amplifies a natural instinct within which transforms the action we are doing into one in which the resource is given naturally in a way that the individual decides is good, but which collectively results in a social good as a result of the actions of many individuals, associations, and so forth, that might ultimately use this function. There is an assumption in this process that people involved would not be coerced into using this tool ~ for example, if someone wanted to, they would contribute some microdonation to fix the City's broken-up roads, assuming that their town used BCN(ABIS) and had such a system, but I make the assumption that there would be no-one coercing them to do so ~ that they do so freely, voluntarily.

The system thus is presented without prejudice; the microgiving notion is left to the user; they could be microdonating to their 401k, to their City's line item account for the roads to fix potholes, to a homeless veteran's nonprofit, to their sick brother Bob, to anything or anyone that has an address. Reducing friction and evolving a giving process, I also assume and hope that we would in this model become more like the bees that share pollen as they bounce from flower to flower.

Areas that would be Visually Affected by Proposed Change:

BCN GUI Wallet ~ (This would result in a new Menu section along with other changes)

1) The original draft change request was altered based on community input received in order to generate this final version of the change request. Further ideas are welcomed and potentially may also contribute to future development.

2) Do nothing. No change is required.

Priority to Implement

Inputs optimization is scheduled for 1.0.7 release (potentially by mid-August).

ABIS is anticipated with a priority for implementation in release 1.0.8 (around end of August or early September).

Other Notes

While this change request is for these ideas to be integrated into BCN, I also hope to eventually see them integrated into other currencies and areas as well ~ and so, it's my intent to make ABIS as a concept more interoperable.Please let me know if you have any thoughts on how that should best happen, including any suggestions you have for licensing or other issues ~ the ABIS repository is currently GPL-v3 (and is anticipated to remain so), see: https://github.com/ABISprotocol/ABIS/blob/master/LICENSE Such issues as interoperability, potential integration of ABIS microgiving concept(s) into other currencies, what license should be on the ABIS repository, etc., are not technically part of the scope of this change request discussion, but I nonetheless welcome any input I receive on those issues, and the best pathway to do so would be either via to open a github issue at https://github.com/abisprotocol/abis or contact me via one of the methods shown in my signature.