my exchange is losing me money
[...]
If anybody has any other suggestions I'm open to them, but in a few days if nobody has any better ideas I'm likely going to do one of the above-listed things.
The obvious thing to do is to have your exchange actually be an exchange. Match buyers with sellers and take a fee on each trade. That way you can't lose. Currently you're not just an exchange, but also the only market maker. People are able to game your bot by trading against it. Yeah, this was gonna be one of my solutions. I'm still thinking through all my options but I also had something like this in mind. Edit: I've disabled the exchange until I decide what to do |
|
|
|
Hey guys, So, I've got some bad news: my exchange is losing me money. I will not continue to operate it if it's going to lose me money. I invested time and my own money into this mostly as a service to the site, but due to its simplicity, I lose money if the price swings one way or the other (BTC/LTC wise). In my mind, there are a few things I can do: - Increase the flat fee rate from 1% to something higher, possibly 2%, 2.5%, or 3%
- Attempt to dynamically scale the fee based on price movements, which wouldn't be perfect and would still just raise fees.
- Stop running the exchange altogether
I could technically make mirror trades on an exchange to replace any funds I sell to users immediately, but this would incur exchange fees and require me to trust an exchange, two things I don't want to do. If anybody has any other suggestions I'm open to them, but in a few days if nobody has any better ideas I'm likely going to do one of the above-listed things. Maybe make a simple exchange bot with orders? People will send coins to your bot for a tiny fee and it will automatically execute trades as soon as there's a matching order, or will return the coins back when users cancel their orders. The bot can whisper in pm the list of all active orders to avoid clogging the chat. I've thought about it, but honestly it seems too complicated for the site, and much too complicated for a text-only format. |
|
|
|
Hey guys, So, I've got some bad news: my exchange is losing me money. I will not continue to operate it if it's going to lose me money. I invested time and my own money into this mostly as a service to the site, but due to its simplicity, I lose money if the price swings one way or the other (BTC/LTC wise). In my mind, there are a few things I can do: - Increase the flat fee rate from 1% to something higher, possibly 2%, 2.5%, or 3%
- Attempt to dynamically scale the fee based on price movements, which wouldn't be perfect and would still just raise fees.
- Stop running the exchange altogether
I could technically make mirror trades on an exchange to replace any funds I sell to users immediately, but this would incur exchange fees and require me to trust an exchange, two things I don't want to do. If anybody has any other suggestions I'm open to them, but in a few days if nobody has any better ideas I'm likely going to do one of the above-listed things. |
|
|
|
Yes, I know that. But I need unlimited or more then 40 character pattern.
Lol. Trying to crack the Bitcoin richlist? Just your bitcoin address  . Seriously, who has an unlimited version?  Nobody. It's impossible, man. Guys. I just need the programm. Don't tell me please "possible/impossible". I know that programmers can easily remove this limit. I'll pay a tip There's a reason for the limit, as you'll find. However, I can remove the limit for you, if you really want, at your own risk (i.e. results not guaranteed), I can send you source code or precompile for Linux. Send me a PM. Will you be able to send the version without limitation of bitcoin address length for Windows? The limitation on address length is not something any program could overcome. It's due to the nature of how Bitcoin addresses work. Do not run any software or use keys from people claiming to be able to make such "40 character long" prefix addresses. Hello!
Why using the "-F compressed" command, all private addresses start with "L" or "K". And if you do not use this command, then only on "5"?
This is to tell the wallet that the addresses being used are compressed so that they scan the correct addresses. |
|
|
|
It could be handy features, but there are some problems such as :
1. It will make zero-confirmation impossible, especially zero-confirmation is very needed when you pay in store where merchant obviously can't wait 10 minutes.
Zero conf has pretty much been impossible for a while, with RBF and double spending. I think lightning network will be the new way to make instant Bitcoin payments. 2. I think develop your idea would be difficult since developer also have to think how to prevent double-spend or prevent rebroadcast transaction.
I think something like this could be as simple as broadcasting a request to remove a transaction from the mempool. 3. It could make conflict when miner mine a block after you broadcast "cancel TX" to bitcoin network while other nodes receive your broadcast before receive newest mined block which include your transaction.
I don't think there would be a second transaction to cancel the first, as that would take space in the blocks, so it would take fees, so it wouldn't be that helpful. Like I said to your second point, I think a request to remove a transaction from the mempool would be a much better solution. |
|
|
|
Known issue. There are some subtle problems here. I’ve wanted to kick around ideas for a potential BIP, but it’s been fairly low on my list.
My doubt, regarding signing in segwit address is if this is a "bug" and will soon be corrected, or is it an abandoned feature? If the later is the case, i will probably move back to legacy addresses... I fear to lose airdrops, which may be quite significant. I think there will eventually be a standard way to sign and verify messages with segwit addresses. But currently, almost nobody will be able to (easily) verify a segwit address signed message. My doubt, regarding signing in segwit address is if this is a "bug" and will soon be corrected, or is it an abandoned feature?
It is neither a bug nor an abandoned feature. It is just that we are still working on creating a more generalized signing scheme that lets people sign with things like P2SH addresses (e.g. sign with a multisig address). A signing standard that allows signed messages from multisig addresses would be incredible, I hope progress is made on this eventually. |
|
|
|
So, it isn't really the Ledger device itself... but the Ledger Chrome App that is susceptible to this particular issue. Users who use Electrum (and other 3rd party Ledger compatible wallets) are less likely to face this problem. Assuming of course they're running the newer versions that patch the JSON RPC flaw  Having said that, anyone who just hands out Bitcoin Addresses without validating them first is asking for trouble. As with all crypto related matters... a healthy level of paranoia is a "Good Things"™ It's a good thing that it's possible to use Electrum or other desktop wallets to send with, but I think it's definitely still a big problem because of how many users use the chrome apps. |
|
|
|
|
This is a very very unlikely scenario, you're basically trying to find a single value that hashes to 0, so effectively you're trying to find a hash collision. At the current hash rate of 23,000,000 TH/s of the entire Bitcoin network, you would have a 50% chance of finding the value that hashes to 0 after going through half of all possible hashes, which would be (2^256)/2 possible hashes. Wolfram alpha tells me that (2^256)/2/23,000,000,000,000,000,000 is 2208558830972980411979121875928648144784354871094523697652007751615774728773803 7109375. This is the expected number of seconds it will take the current Bitcoin network to have a 50% chance of finding a block that hashes to 0, otherwise written as 7.0032941114059500633533798703977934575861075313753288... × 10^77 years.
Basically, it's just not gonna happen.
|
|
|
|
I was attempting to go check out your provable fairness system, I found your verifier. I can change the client seed, but not the server seed or the hash secret. I'm assuming this is a bug, I thought you'd want to know about it. Hi RGBkey, Thanks for your observation! And it's not a bug, actually, we focus the fairness on each bet result. If you can change the client seed of a certain bet, it means the client seed you enter will be part of the randomness of the bet result. But if you can change both the server seed and hash secret, it's not easy to verify the result of a certain bet. So you can see that you can verify each bet result by examining the "BET DETAIL" of every bet. Hope this explanation is clear to you, let us know if any other remarks, thank you so much ETTA GamesHow am I supposed to use this verifier to check the results of any of my games if it won't let me change all of the data to the data for my specific bet? |
|
|
|
|
I have a Ledger and had no idea about that button that displays the address on the device. Thanks for this information.
|
|
|
|
Even though it's not of much consequence, no screenshot should ever be accepted as proof, as the values seen could easily have been edited. Example Not accusing OP of anything, just a friendly PSA. |
|
|
|
|
To add to that conversation, I think it would be beneficial to add support for at least withdrawing to bech32 addresses. It would require a small change in the codebase and it would allow users to spend even less on fees. I know that fees are low right now but if we're always trying to add features that lower fees when the fees are high there's going to be a lot of upset users in the time before the features get added.
I realize that adding support for allowing deposits to YD on bech32 addresses would likely be more complicated than adding support for withdraws, but I hope that can eventually become a reality too. Even if it was only supported via the API at first.
|
|
|
|
I was attempting to go check out your provable fairness system, I found your verifier. I can change the client seed, but not the server seed or the hash secret. I'm assuming this is a bug, I thought you'd want to know about it. |
|
|
|
Really wish you guys have eth,bch... Not interested in paying over 10-15$ to gamble around 50$ Guess i'm gonna use those clones  Bitcoin fees are extremely low right now, 2 sats per byte. You can send for pennies. |
|
|
|
We're gonna miss you, Ryan. I had a great time gambling at Bustabit back in 2016. I even invested BTC in your ICO back then. Too bad not enough funds was raised back then. Anyway, I forgot to say thanks for the bonuses you sent in spite of the failed ICO.
Bustabit was great during the lull moments when coins at Poloniex weren't doing anything.
Bustabit had an ICO? I wonder what the early investors got during those days and now that they moved on to version 2 of the site now and under new management. I also heard they have an investment option as that bustadice put in place when they started the site. Didnt you read it didnt raised enough fund? yes bustabit v2 now have investment option as well. Similar to bustadice , it has 10 % dilution fee to motivate people to stay longer with them. Site currently has 1700+ bitcoin and site's profit is at -99 btc. It is about the best time to put your money in before the variance swing to investor That's not how variance works. Probability works on future events, not on events that have already happened. The probability of Busta losing another 99 BTC is the same as it was before it happened. Don't fall into that mental trap. Yes you are correct but you need to realize that in the long run the casino always wins. Hence you can assume that if the site stays open long enough the profit will be at least at break even. So in that scenario you are actually at an advantage to get in when it's at a negative rather than at a positive. The idea that it's better to get in while the site is negative is a fallacy. The site has already lost the money. The chances it will gain or lose money now are more or less equal, minus the effects of the house edge. You are not "more likely" to make money while the site is in negative profit, and you are not "less likely" to lose money when the site has performed better than expected. |
|
|
|
I use Windows, I could compile/test if needed.
Thanks. I will initially put something Unix-only on Github, then work on making ready for some sort of Windows version. What is your Windows development environment? I think I need to try going the mingw route, due to use of POSIX getopt(), POSIX regex, etc. My very limited C knowledge involves writing code on a linux VM and compiling with gcc. I can adapt to whatever though. I have the ability to get free licenses for visual studio through work. |
|
|
|
|
Cold storage isn't really a set of rules to follow, but more a range on a "security slider". I'd say it's cold storage as long as it's on an offline machine used only for signing, but you can get more paranoid from there too. Is the key stored on the computer, or is it stored on a metal plate or something?
|
|
|
|
|
I don't think programming a proof-of-concept vanity address generator in C would be that hard, if we use core's library to generate the keys. Optimization could come later, but implementing Bech32 in C would not be that difficult.
|
|
|
|
|
AM and RGB-Exchange will continue to be down until I can repair my machine, sorry folks. I have no way of estimating how long this will take me unfortunately.
Fixed
|
|
|
|
|
Show Posts
