[BTC-TC] Virtual Community Exchange [CLOSED]

[burnside]

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

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

Deposit Address(es):    ABC123qxN7FKVHkYUiTV4aJTUeVVqp1Zq

[request new deposit address] (limit 10)

Hope that helps!

[matthewh3]

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

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

Deposit Address(es):    ABC123qxN7FKVHkYUiTV4aJTUeVVqp1Zq

[request new deposit address] (limit 10)

Hope that helps!

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 

[burnside]

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

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

Deposit Address(es):    ABC123qxN7FKVHkYUiTV4aJTUeVVqp1Zq

[request new deposit address] (limit 10)

Hope that helps!

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 

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?

[matthewh3]

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

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

Deposit Address(es):    ABC123qxN7FKVHkYUiTV4aJTUeVVqp1Zq

[request new deposit address] (limit 10)

Hope that helps!

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 

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?

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.

[parseval]

This is a brilliant addition to both BTCJam and BTCT.CO!

One question though...what happens to dividends paid to shares whilst they're being utilized as loan collateral?

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..

[burnside]

This is a brilliant addition to both BTCJam and BTCT.CO!

One question though...what happens to dividends paid to shares whilst they're being utilized as loan collateral?

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..

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.

[burnside]

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?

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'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.

[matthewh3]

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?

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'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.

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

[matthewh3]

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?

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'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.

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

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

[poly]

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

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

Deposit Address(es):    ABC123qxN7FKVHkYUiTV4aJTUeVVqp1Zq

[request new deposit address] (limit 10)

Hope that helps!

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 

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?

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.

[burnside]

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?

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.

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? 

[poly]

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?

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.

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? 

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

[burnside]

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

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.

[🏰 TradeFortress 🏰]

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

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.

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.

[matthewh3]

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

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.

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.

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.

[burnside]

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.

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?

[usagi]

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.

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?

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

[btharper]

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.

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?

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?

[burnside]

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.

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?

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?

The DRIP behavior right now is that it continues to build up until it sees an order fitting the existing DRIP criteria, in which case the trade gets executed.  When it was first setup I had considered having it place orders, rather than just waiting, but I wasn't sure that was a good idea.  It would have to place the order at the max you specify you're willing to pay and when there's not a lot of volume you would potentially end up overpaying.

Thinking about it though, it's probably better to have the DRIP place orders, because then someone might fill them, you never know.  Plus then the currency would be on reserve and you wouldn't be quite as likely to forget that the DRIP is in place and doing it's thing.

[endlesscustoms]

hey  something is up i try to log in i get   

Error:

Xcoind backend failure in getbalance at 774