Rate Limited Free Transactions Feature Implemented

Started by abit, February 14, 2016, 04:00:28 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

CLains

Quote from: Empirical1.2 on February 14, 2016, 06:47:59 PM
+5% +5% Don't know much about coding but you seem to be doing great fast work, abit, well done!

+5%
Vote for BitSpace EOS Block Producer!

[url="https://steemit.com/eos/@bitspace/bitspace-eos-block-producer-candidate"]https://steemit.com/eos/@bitspace/bitspace-eos-block-producer-candidate[/url]

xeroc

Quote from: giant middle finger on February 15, 2016, 04:19:31 AM
chinese still pissed off

fees still too expensive

you must send 100 BTC randsom to china or else suffer the wrath of the monkey new year (all chinese dump
all BitShares!)


按百分比计算转账手续费功能,开发完成
只要降低,就支持,降得越低越支持







sarc



actually, props to the red dragon for showing us that we can have our cake and eat it too.

subsidized microtransactions and happy Long Term Members!!
Cool thing is .. we dont need to put this on every asset .. but maybe just USD and CNY .. we can keep BTS transferes (comparable) expensive

Musewhale

MUSE witness:mygoodfriend     vote for me

giant middle finger

chinese still pissed off

fees still too expensive

you must send 100 BTC randsom to china or else suffer the wrath of the monkey new year (all chinese dump
all BitShares!)


按百分比计算转账手续费功能,开发完成
只要降低,就支持,降得越低越支持







sarc



actually, props to the red dragon for showing us that we can have our cake and eat it too.

subsidized microtransactions and happy Long Term Members!!


sudo

 +5% +5% +5% +5% +5% +5% cool  awesome
I like it  becacuse  I lock my bts 8) 8) 8)

TravelsAsia

Quote from: xeroc on February 14, 2016, 04:18:27 PM
awesome job!

for your next project ... could you please fork from graphene/develop? that would make it way easier to integrate this into MUSE or the testnet!!!

+5% anyway

+5%

Great initiative.

abit

Quote from: bytemaster on February 14, 2016, 05:41:00 PM
I did a quick review of the implementation and believe it accomplishes 90% of what I wanted to accomplish. The only thing this doesn't do is dynamically adjust the fee in response to load.

Assuming this gets properly tested I would support integrating it.
Thanks.
It's a bit hard to make it dynamic, so I made a simpler implementation first.
Still testing..
BitShares committee member: abit
BitShares witness: in.abit

Empirical1.2

 +5% +5% Don't know much about coding but you seem to be doing great fast work, abit, well done!
If you want to take the island burn the boats

merivercap

 +5%

Great to hear..

Thanks for the review @bytemaster!

Fantastic job @abit! 
BitCash - http://www.bitcash.org 
Beta: bitCash Wallet / p2p Gateway: ([url="https://m.bitcash.org"]https://m.bitcash.org[/url])
Beta: bitCash Trade ([url="https://trade.bitcash.org"]https://trade.bitcash.org[/url])

svk

Worker: dev.bitsharesblocks

bytemaster

I did a quick review of the implementation and believe it accomplishes 90% of what I wanted to accomplish. The only thing this doesn't do is dynamically adjust the fee in response to load.

Assuming this gets properly tested I would support integrating it.
For the latest updates checkout my blog: [url="http://bytemaster.bitshares.org"]http://bytemaster.bitshares.org[/url]
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

Thom

I really like how you implemented this abit  +5%. I understand the comment about the approach being a "bandaid", but actually the approach you took makes a lot of sense and allows the system to function exactly as it does now, should there be a bottleneck or bug in the process of adding to or paying out of the "accumulated fees" (i.e. rate limiting) holdings. This is an enhancement in the purest sense of the word.

I take it if an operation requires a fee and there is a balance of accumulated fees, the cost of the operation will automatically be supplied from the accumulated fees holdings?

I do seem to recall BM commenting somewhere that such operation should not be allowed. I could be wrong about that. I believe it has to do with whales exceeding the available network bandwidth?

Am I also correct in assuming that there are no prohibitions, stoppages, "sorry, can't do that" aspects to your approach? For example using a std account with a 1000 BTS balance performing some op (say in a python loop) that requires 1 BTS, there is nothing that would restrict the speed of that loop right? If there were no rate limiting, the loop would terminate after 1000 iterations (assuming the op didn't impact account balance). With rate limiting perhaps a few more iterations could be possible, due to accumulated fees being non-zero + the original 1000 BTS balance that both contribute to fees.
Injustice anywhere is a threat to justice everywhere - MLK |  Verbaltech2 Witness Reports: [url="https://bitsharestalk.org/index.php/topic,23902.0.html"]https://bitsharestalk.org/index.php/topic,23902.0.html[/url]

Xeldal

Quote from: abit on February 14, 2016, 04:55:20 PM

The "accumulated fees" can only be used to pay fees. Or say it's budgets. When you're running out of budgets, you can pay fee in the original way. Make sense?

And fees paid with coin-days wont go to referral program (or cash back for LTM), they are eliminated.

Yes that makes sense.  Thank you.
I like that you've left available the option to pay fee if beyond coin-days budget. : ) very nice!

abit

Quote from: gamey on February 14, 2016, 04:55:02 PM

I haven't looked at the code but I'm glad to see this sort of input. Great way to set an example for others to follow, Abit.
Example of developing back-end, or GUI, or example of using it? I will post my CLI commands here while testing through it.

By the way, my worker hasn't started yet, perhaps svk hasn't have time to work on related GUI.
BitShares committee member: abit
BitShares witness: in.abit