lower withdraw cooldown by 100 seconds (we could lower this even further IMO)
replace burn address from example with tipbot representative account, to prevent any 'mishaps'
split the withdraw into send and sendmax to prevent user mistakes
sendmax now doesn't take an amount, so it will send the full number of naneeros/bananos (but allegedly not fractions of it due to possible limitations in the send-queue logic?)
improve address recognition by using regex instead of depending on a strict input syntax (splitting on spaces). Compatible with nano_ xrb_ ban_. More precise error messages depending on the type of mistake (checksum errors get triggered by the node, regex fails within python already, double address occurrences will also halt the operation)
improve amount recognition for withdraws - now it's irrelevent where in the string the amount is located, because first the address is removed from the input, and then the already existing number recognition regex kicks in. Exception handling was adjusted accordingly, as amounts are mandatory for send now. Now it also throws an error on multiple amount occurrences (Previously, it would use the first occurrence and discard the others without warning).
The number logic for other commands is untouched by this PR
remove WITHDRAW_INSUFFICIENT_BALANCE text block because it's redundant with INSUFFICIENT_FUNDS_TEXT
for the upcoming transition phase, I made withdraw dysfunctional but tell the user about its deprecation and inform about the new alternatives
Problems I noticed that still remain:
while there are less potential input mistakes now, a typo or a misunderstanding of units could still lead to undesired send amounts. Maybe the bot should ask for a confirmation (Other discord bots for example write: You are about to do X ... Answer with 'yes' now to execute this)
the split caused some redundancy, and naming may be inconsistent now
bot.py is rather big, could be split up
Some error messages are still inline
impossible to withdraw decimals because they get truncated
what's the purpose of abs() here? Do we even handle negative amounts?
send example has a static xrb_ prefix
If we adjust exception handling for all tipping commands, we can use the new find_send_amounts() on all of them.
Haven't run the whole thing through an interpreter yet; I only tested the new address regex behavior. Merge with caution!
What this PR does:
withdraw
intosend
andsendmax
to prevent user mistakessendmax
now doesn't take an amount, so it will send the full number of naneeros/bananos (but allegedly not fractions of it due to possible limitations in the send-queue logic?)nano_ xrb_ ban_
. More precise error messages depending on the type of mistake (checksum errors get triggered by the node, regex fails within python already, double address occurrences will also halt the operation)send
now. Now it also throws an error on multiple amount occurrences (Previously, it would use the first occurrence and discard the others without warning). The number logic for other commands is untouched by this PRwithdraw
dysfunctional but tell the user about its deprecation and inform about the new alternativesProblems I noticed that still remain:
You are about to do X ... Answer with 'yes' now to execute this
)send
example has a staticxrb_
prefixfind_send_amounts()
on all of them.Haven't run the whole thing through an interpreter yet; I only tested the new address regex behavior. Merge with caution!