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

Gox runs their own yubikey server. Then they dont have to rely on a third party.

I'd heard at one point that gox yubikeys and regular off-the-shelf yubikeys were different somehow?  Any tricks to supporting both?

I'll order some up and see what I can do.

Cheers.

Hi all;

I just saw the new order cancel right on the market view of litecoinglobal. Thanks for putting that in.

next, how about yubikey support?


require_once 'Auth/Yubico.php';
// ...
// Is it a Yubikey?
$otp = $GET_OR_POST...
$yubi = new Auth_Yubico('####', 'api-key');  // #### = pin, api-key is your key.
$auth = $yubi->verify($otp);

if (PEAR::isError($auth) == FALSE) {
   // Authenticated via YubiKey!
   $yubikey = hexparseOTP($otp);      // parse otp
   $key_id = $ret['uid'];                            // get the yubikey ID number (which you would store in your DB and use like a PIN.)
}
else if (GOOGLEAUTH==TRUE)
{
   // user is authenticated via google auth
} else if (IS_IT_A_PIN? == TRUE)
{
   // it's a PIN.
   // user is authenticated via PIN
}

YABMC import complete! 

https://btct.co/security/B.YABMC

As with previous imports, if you didn't get your welcome email with account details, please check your spam folder before contacting support.

There's also a passthru available on BitFunder offered by Graet, check it out here: https://bitfunder.com/asset/GPT.YABMC

Thank you all for choosing BTC-TC!

I agree that it's an awesome looking proposal that is completelynearly useless without support rolled out. Although even as it currently exists it could be used to generate lots of addresses for people without the server knowing private keys. However then you need the wallet to accept them somewhere. While Armory uses deterministic keys, I'm not sure the exact implementation (though it does allow public key only wallets as well).

Can't knock your enthusiasm for the crazy stuff we suggest.

A lot of the features in that proposal look pretty nice.  My personal favorite is being able to run two of the same wallets simultaneously on separate servers.  Right now the site's hot wallet is a single point of failure.

If it ends up being developed, and is solid, I don't see any reason why we couldn't adopt it.

Cheers.

I don't suppose you'd be interested in (eventually, very little client support so far) implementing BIP 32 Addresses Each deposit or withdrawal could be a unique address without the need to distribute new information.

Voted.

This has been requested a few times.  Finally bit the bullet and went ahead and programmed it in.  So on the wallet page you can now request additional deposit addresses up to a limit of 10. 

Also, a quick reminder for the mods.  YABMC needs your vote. 

I think it'd be a good idea if users could change their deposit address for anonymity reasons.

I have no idea of how fireduck does it, but SatoshiDICE sweeps individual inputs into more manageable chunks for future spends. You can see this happening even on losing bets. Dice will send some other TX to another of their "bank" addresses, along with your loss. I'm sure that they have a huge and complicated system of managing all of these inputs, tracking the size, and age of each input. Then they can spend only inputs that they need to complete the TX with minimal fees.
They also keep various sized inputs on hand so that they don't have to break up a 100 BTC input to pay 0.01, and then end up with new "young" 99.99 BTC input.
Of course, Dice handles more TXs than anyone, so yeah, their system is complicated.

Another alternative is to allow withdraws to be queued together. Lets say someone wants to withdraw, but they can wait. Queue withdraws and send all on the hour. If there are any TX fees, they would be shared by everyone withdrawing so it would be much lower (hopefully).

You can always craft your own raw transaction, but that's quite complicated. bitcoin really needs quite a few more APIs, but some of the core developers seem to want to go with the "no extra features unless it's absolutely necessary, go make your own client" route.

Good question, and thanks for the note about the first post, I'll get that fixed.

Right now the hot wallet bitcoind is mostly stock.  I say mostly because I have done some very minor (non-core) customizing to it.  As such, I seem to only be able to get the actual fee out of the RPC interface after the transaction has been made.  (any bitcoind pros please let me know if there's something I'm missing!)

It has been a point of much confusion and frustration.  For example, I reserve 0.005 from the balance in case there's a fee, but the other day someone withdrew something like ~0.070 and ended up with a 0.020 fee, leaving their account negative 0.015.  Doh.  A few slightly negative accounts are not a huge deal, but what if 1000 people had that happen to them?  It starts to be an issue.  I'm not sure yet what the answer is... maybe a 0.1 BTC reserve?

The other option I've been looking into is the zero transaction fee patch.  It seems to have some gotcha's though.  For instance they recommend minimum transfers of 0.01 BTC and they still recommend adding a fee manually when there are lots of inputs.  Is there anyone out there with a lot of experience running this on a decent sized site?  Maybe I should just email the BTC-e guys or something. 

Cheers.

Just looking back through and saw the OP still lists 0.01 BTC withdrawal fee, figured you may want to update that, if not other parts. I was wondering though how the bitcoind is factored in. Is there any confirmation about whether it will or will not be added for a particular withdrawal, can you choose to delay payment to decrease (or eliminate) the fee (either just waiting, or grouping with other withdrawals)? And is it just based off of the servers hot wallet (which is even harder to control)?

Not saying it's a bad idea, just wondering if an individual can predict if it will be there or not.

Something is definitely wrong somewhere.  I'll see what I can figure out.  Thanks for the report!

Edit: I think I pinned it down.  Had to make some tweaks to the sql server timezone tables.  It'll take an hour or so for the old data to time out of the cache, after that it should be good.

Cheers.

It looks like times associated with motions are not handling time zones correctly. For example, if I view this BTC-TRADING-PT motion when logged in, it says:

If I view it when logged out, it says:

Note that the times are the same even thought the time zones are different.

The patch last night broke the portfolio page for accounts without any securities held in them.

Fixed it up this morning, should be good to go.

Cheers.

A quick summary of the svn logs for the last couple weeks:

- New Locked tab for locked securities.
- The public portfolio feature now includes the ability to publicly display your wallet balance.
- Big reformat of the Account page.  It's now up to date and matches most of the rest of the site. 
- API improvements on the ticker output, it now includes additional 7 day and 30 day data.
- Fixed a bug with address verification on the Wallet address entry forms.  I was calling the verification function incorrectly such that everything was being considered valid.
- Security Trade tab now has red/green buttons for buying and selling.  Hopefully makes things a little clearer.
- New support request form.  Sends an email to the support gurus.
- New Security Trade tab information bar, including shares outstanding, 7 day numbers, 30 day numbers, and the moderator score.
- Many, many email formatting and output improvements.
- New 30 day and 90 day per share dividend payouts calculated on the Security Dividends tab.
- ** Huge change ** - Implementation of manual withdrawals when the withdrawal amount exceeds a daily withdrawal cap of an equivalent of $300 USD in digital currency.  This should not impact trading much, and there are some good benefits.  The main ones are;
    (A) To protect the exchange.  I can now reduce the amount of coin in the hot wallet to a safer level.  This is a huge security exposure win.
    (B) To protect users from compromised account situations.  If an attacker tries to withdraw over the threshold, you will get an email saying a manual withdrawal
    was requested.  You then have some time to contact us and ask us to cancel the withdrawal.
- No longer prompt asset issuers to vote on their own motions in the Portfolio page, since when they get to the Asset page they couldn't vote on their own motions anyway. 
- Motions with a start date in the past will now automatically start immediately.  It was pretty common for people to use the "Now" button in the calendar, wait a few seconds, then submit, rendering a start date in the past, which popped up an annoying error.
- Many timezone related bug fixes.  I believe there are still many to go.  The problem is that many of the html code chunks are shared among users in multiple time zones, so I'm having to re-work the caching for a lot of them.
- My Trades tab on the Portfolio page now has a 500 trade limit, bumped up from 30.

Work is progressing on the API setup for trading.  It is based on oauth 1.0a, and should be pretty easy to program for if you're familiar with oauth.  No ETA on it yet, we're taking it slow so we get it right.

4 posts in January 2012.

Then you come back a year later and have done nothing but harass the exchange since.

Whose sock are you?