Topic: [BTC-TC] Virtual Community Exchange [CLOSED] - page 120. (Read 316534 times)

As a quick note, how would this impact DRIP purchases when they can't be immediately fulfilled? I'd assume placed on the orderbook for someone else to pay the higher fee on?

It should be maker/taker (adding liquidity, i.e. limit orders = no fees) right?

That's a good question.  I have thought about it.  GLBSE when I first started using it did it this way, then it seems like later on it was silently changed to both sides paying.  I remember being pretty pissed when I realized this because I'd stupidly been placing orders that I could have executed right away for just a few satoshi's difference.

It doesn't necessarily have to be all or nothing.  It could be 0.1% to place an order on the book and 0.3% to execute for instance.  That might be a more balanced approach and still encourage more use of the order book.

What does everyone else think?  Would it really have the intended effect of better liquidity?

Other exchanges can do it and for privacy reasons users would prefer not to have wallet addresses tied to their account.

Also have you ever thought of dropping all fees for listing orders and have the people who buy into orders pay all the fee instead.  I think this would encourage traders to put up more listings and improve fluidity.  It's also what the GLBSE did IIRC.

Yeah, it's not really a good idea to have a massive wallet.dat file. You can always use a coin mixer if you want that much privacy.

Of course.  My point is that if the wallet.dat hits even a GB life is really going to suck when I'm trying to keep backups every X minutes and queries to the wallet db take forever.

The wallet is just a BerkleyDB file and unlike most other databases, there's no caching layer on it and as far as I can tell, no safe way to clean out old junk in a bitcoin wallet.

I'll keep looking into it, but it's clear to me that with the stock bitcoind it isn't going to be prudent to roll out fresh addresses per transaction.

Cheers.

You don't have a dedicated bitcoind server with a quite few gigs of space?

It's not just live performance I'm worried about.  Everything gets increasingly harder the larger the wallet.dat gets.  Backups take longer.  Backups take more space.  Bitcoind restarts take longer.  etc.

Also, if (just guessing) a transaction is 0.5 K, and an address key pair is 1K, then:

10 transactions to 1 deposit address: 6 kb
10 transactions to 10 deposit addresses: 15 kb

The site has only been up 3 months and without having an address per deposit the wallet.dat is almost 30M.  Sounds like it would be more like 70M going with a separate address per deposit.  Gox must have a massive wallet... or maybe they have a custom bitcoind that uses a SQL backend with sharding.

I did a quick test run, just for fun.  Here's a wallet.dat with just one or two addresses and a few transactions:

92K 2013-02-28 07:54 wallet.dat

Here's the same wallet.dat after doing getnewaddress 1000 times: (for i in `seq 1 1000`; do ./bitcoind getnewaddress; done)

548K 2013-02-28 08:00 wallet.dat

So every 2000 deposits would be ~1M to the wallet.  I know that doesn't seem like much but it quickly multiplies out when you consider that I back up the wallet at fairly short regular intervals.  It quickly becomes a storage nightmare.    I'm fairly certain now that I'd need to roll out a custom bitcoind with an alternate "wallet" database backend before I could comfortably support this long-term.

Anyone with insider info at Gox about how they do it? 

Not really. It doesn't matter if it's 10 transactions to 1 deposit address or 1 transaction each to 10 deposit addresses - it's still 10 transactions stored in the local wallet. Having a lot of addresses / accounts don't impact performance much.

As far as I'm aware BITSTAMP uses a shared wallet like most exchanges.

To be able to have disposable deposit addresses would be a great feature 

I'll do some research, see if I can figure out what bitstamp is using for the backend.  They may not be aware of the wallet growth issue, or they may have a setup where they can swap wallets at will, or maybe they have a wallet per person, or possibly a custom client that has a feature to remove addresses?  Lots of ways to do it, I'm just not sure that we can do any of those.  I've wondered a few times myself how they support that on the backend, so it's definitely worth doing some homework.

Cheers.

This is entirely up to BTCJAM, the divs would end up in their holding account.  We're open to adding internal BTC transfer support to the OAuth API, which is what they'd need to pass the divs on to the original owners account.

I'm pretty curious about this too.  I asked the same question, but haven't heard back yet.  I took out a 30 day loan and put up S.DICE shares as collateral, so I guess we'll find out one way or another.  Also, as a new feature I wouldn't be surprised or discouraged if there were hiccups or changes to how it functions..

No just one disposable address is fine that can be changed after each tx just like what BITSTAMP and other exchanges offer is what I mean.

I read somewhere that too many addresses gum up the wallet.  I definitely don't want to see performance issues on the hot wallet down the road.

Is this incorrect?

Yeah but you only allowed ten new addresses than that's it no more new address and your stuck with those.  Or am I just being lame 

We do.  Wallet page, Deposit/Withdraw Tab, "request new deposit address" button.


Hope that helps!

Why don't you offer the ability to change your deposit address as most bitcoin exchanges offer 

You're correct.  This is NOT to make it easier to get listed.  There are no changes in listing difficulty.  This is for assets that were approved, operated for a while, have people that are holding shares, but then go downhill.  I do not want to de-list them without giving people a chance to trade their debt or other obligations in a pink/black/pennystock type market.  So they'll sit there for a few months until we can decide what to do with them.  I'm also hopeful that for some of the assets, it would be a wake-up call for the issuer to get their act together, but that may just be wishful thinking.

Cheers.