There's conversation in another thread that is more appropriate here, so I'm quoting a part of it here for discussion.


Is it possible to run an exchange where the exchange operator would not have the ability to enter fabricated orders or to know the positions held in customer accounts?

Just noticed this:


 - https://twitter.com/TomasForgac/status/354918037276721153
 - https://twitter.com/artistrycafesg
 - http://www.artistryspace.com

"Nestled in a quiet corner of the Kampong Glam heritage district, Artistry is a new art gallery and café in a shophouse dedicated to art."

The amount displayed as being available for withdrawal shouldn't be a soft number.  What conditions would cause a withdrawal request to hang as pending, and for how long would the duration be of that status on a withdrawal request? 

OK, at this very moment the last trade at BUZ2 (occurred a few minutes ago) shows 85.  Mt Gox has plenty of bids above, ... and currently trades about 88.

It doesn't matter if that fits anyone's definition of "backwardation", ... it is a condition that can happen, with or without manipulation.

Now until you say that icbit refused to enter an order of yours, or that a deposit you made wasn't credited to you account, then iCBIT is a functional marketplace that is subject to market forces.  Your positions are at a higher risk if you use leverage.  If market forces cause extreme backwardation then that's the nature of the beast.      There's nothing to counter manipulation other than market forces.

Perhaps, akwfleaspirit, ICBIT isn't the right place for you.  Perhaps a nice FDIC insured CD at your local bank is a more secure place for you to speculate with your funds.  [Edit: Actually, that might be something that should be bolded and in red at the top of the OP for this thread.  "This service causes traders to be vulnerable to manipulation by other traders.  If you don't understand the risks  don't trade here.".]

Backwardation

"it may also refer to the situation where a futures contract price is merely lower than the current spot price."
 - http://en.wikipedia.org/wiki/Normal_backwardation#Normal_backwardation_vs._backwardation

Here's a Serval crowdfunding project:

 - http://www.indiegogo.com/projects/speak-freely

I'ld meet up but I'll be out of town.

If you aren't able to get much interest in that event (especially with it occurring five days after this one: http://www.meetup.com/Los-Angeles-Bitcoin/events/123784402/ ) then you might just consider this event that same evening:
 - http://www.meetup.com/Libertarian-Entrepreneurs-in-Los-Angeles/events/126450802

You can remove a transaction that isn't confirming by using pywallet and performing wallet surgery:
 - http://bitcointalk.org/index.php?topic=34028.0

I realize this is a necrothread, but this was a thread started by Camp BX and my question falls under this topic.

I see that Camp BX has added Google two-factor authentication (2FA).

However, let's say I used the 2FA/TOTP code on one device and then want to move that capability onto another device.  The problem I see is that when I go to create a QR code for adding the TOTP code to my second device then the secret code presented by Camp BX is the same QR code that had been presented initially with the first device.   So therefore I cannot be completely assured that the TOTP secret exists only on my second device since the same secret still could exist on the first device (e.g., if it had been backed up).

So my request is to generate a new secret each time the user enabled 2FA / TOTP.

Please, akwfleaspirit, this is a "Help & FAQ" thread.

You have started a thread in the proper board (Service Discussion). That's where these types of comments belong.
 - http://bitcointalk.org/index.php?topic=246845.0

I found a fantastic article describing M-PESA further:
 - http://www.cgap.org/blog/10-things-you-thought-you-knew-about-m-pesa

So an individual can have a balance no more than 50,000 KES (~ $575 USD).  
There cannot be more than 70,000 KES (~ $800 USD) transferred out of an account per day, and 35,000 KES (~ $400 USD) is the most that can be transferred in a a single transaction.

So while these limits have relatively small amounts, they are still high enough that an individual could use this service for a remittance payment to family back in Kenya.  

There already is an M-PESA IMT (international money transfer) method in which money is sent through Western Union and the recipient is an M-PESA user but of course the fees for that are quite high -- generally, at least 10% or more for transfers of $400 or less including loss when the exchange rate conversion occurs.  

With Kipochi the sender can handle all the transfer details and the remittance recipient gets an SMS alert when the funds arrive in M-PESA.  So there is no learning curve or technical hurdle here on the recipient's end.

There's even room for an individual to become an independent provider (agent) of Bitcoin remittance cash-out.  This person would use Kipochi to get started by converting bitcoins received into a form of funds the agent can use for spending.  Then once that agent's volume is heavy enough it then makes sense to work with a local Bitcoin exchanger (to restock the agent's inventory of schillings) and skip the costly M-PESA conversion entirely, as every schilling counts!

So this is different from BitcoinFund.eu?

I don't see a way to pay for the purchase using Bitcoin.

I just updated the default fees in that wiki article.  
 - http://en.bitcoin.it/wiki/Transaction_fee

paytxfee was showing a non-zero value, but that is zero in the software, and has been for quite some time right?

A second set of eyes on the changes would be helpful.

Thanks, I updated the Wiki page to reflect the new fee.   

Incidentally, the size gets rounded up, so the number used for the calculation if there is even one byte over 35K means 36 is the needed value.  Your fee was 0.0035 so the logic in the code would by default leave your transaction as low priority.


There is no way to modify the fee for an existing transaction.  If it was sent using Blockchain.info, eventually it will stop retrying and the funds will again show as spendable.

Is suppose what could be attempted is to take one of the inputs and try to double spend it:
 - https://blockchain.info/create-double-spend   
Then that would invalidate this transaction, causing the funds to immediately become spendable once again.

Perhaps ....

 - http://www.coindesk.com/firmcoin-the-reprogrammable-physical-bitcoin-token-explained/

And another interesting development:
 - http://localbitcoins.blogspot.fi/2013/07/trading-bitcoins-using-m-pesa-in-kenya.html

I'm not familiar enough with M-PESA t know what this offers though.  I need to be an M-PESA agent to accept funds, right?   And if I'm an M-PESA agent there's probably a terms-of-service as to what transactions are allowed.   Or am I misunderstanding how it works?

Well, SD doesn't use web access for wagering.  The report was for a competing site, apparently:

The size of the transaction is a little over 35K.    

"the reference implementation will round up the transaction size to the nearest thousand bytes and then add a fee of 0.0005 0.0001 BTC per thousand bytes"

 - http://en.bitcoin.it/wiki/Transaction_fees

Your fee paid of 0.0035 is way too low.

Pay 0.018 BTC (calculated using 36K X 0.0005 BTC, which is worth under $1.50) and the transaction will likely confirm.


[Edit: v0.8.2 and above the fee is 0.0001 BTC per 1K].

There are likely to be some buyers there.  More than two dozen people have RSVP'd as "will attend" the Wednesday, Jul 10th L.A. Bitcoin Meetup in Santa Monica:
 - www.meetup.com/Los-Angeles-Bitcoin/events/123784402/