blistovmhz

Well holy crap. Five days later, the transaction to the final address (1Dy) is finally alive again and waiting for confirmation! That’s … pretty slow… :p

@gleb, did you ever watch the actual blockchain to confirm that the transaction included the final destination? I suppose it’s always possible that blockchain.info is handling the secondary transfer manually instead of simply injecting it as part of the initial transfer, but then on the site shows it as a single transfer.. for a while….
This is though, 4 days since the original transfer to 1Gfx and still no suggestion that I might eventually receive the funds.

@gleb, I did try to contact blockchain.info (no response) and posted on bitcointalk, but no response there either as I’m officially still a n00b and can only post to the newbie section. I had a buddy post on my behalf as well but he hasn’t seen any response thus far either. I suspect no one believes this actually happened the way I describe, as it just shouldn’t be possible. I saw the transaction on the block chain, then it changes 48h later. I dunno, perhaps I’m mistaken and I only saw it on blockchain.info and perhaps their website shows you want they want you to see instead of reflecting the reality of the block chain itself? This would be … Deeply suspicious, but I hate to jump to conclusions of malicious intent this soon.

Ultimately from my perspective, I’ve looked through the code so I know it’s not a plugin issue, which leaves blockchain.info or the bitcoin network as a whole. I’m more inclined to believe the failure is with blockchain.info.

That said, @gleb, have you seen transfers come through successfully… recently?

Well for now I’m waiting on someone to release a plugin that does precisely as you’ve done. I’ve disabled the existing bitcoin plugin as two for two, my transactions did not make their way to my final address, and instead got stuck in the temporary address. ??
Luckily I caught this before my customers started paying in BTC (only one valid order was lost, the other transaction was my test), so I’m only out $80 or so thus far.
*edit* BTC value went up again, so it’s now $94 :p

I can’t imagine this being a failure of anyone other than Blockchain.info’s API as I saw the transaction was correct for the first 48h and saw it hit the actual block chain correctly. I also however, can’t imagine how that transaction was modified, as AFAIK, this should be impossible.

@gleb, yea, the thing is that the transfer has simply changed. The final address is no longer part of the blockchain, and it’s been 4 days now since the intermediary confirmed. I’ve sent an email to blockchain.info but haven’t heard back from them yet.
I think the direct to wallet option is far superior, plus then we’re not doing two transfers, requiring two fees, and situations like this (where the transfer simply changes days after creation) are taken out of the equation.

I’ve checked the actual blockchain for the transaction in question, and it has in fact, been modified after the fact, but there is of course, no evidence of this beyond the initial transaction log from the plugin.

@webdesz, going to publish? That sounds like … most of a re-write.

Oops. Turns out the private key for the generated address is not actually that “secret key”. So I do not have access to that address and the funds are now in limbo.

./__log.php:// 24.84.12.106(48467) -> 2013-04-04, 22:08:00 UTC|1.26/Standard|bwwc-bitcoin-gateway.php(284)|: Generated unique bitcoin address: ‘1GfxJgs8FU6JrKFJFALT3PZxgv9VR7UXnL’ for order_id 19
./__log.php:// 185.7.149.10(49554) -> 2013-04-05, 1:22:57 UTC|1.26/Standard|bwwc-bitcoin-gateway.php(434)|: BWWC__maybe_bitcoin_ipn_callback () called and ‘bitcoinway=1’ detected. REQUEST = a:14:{s:9:”anonymous”;s:5:”false”;s:6:”shared”;s:5:”false”;s:19:”destination_address”;s:34:”1Dyqf4aG3K83mCbsWyjqzUGkRh5xV3rXPw”;s:10:”bitcoinway”;s:1:”1″;s:13:”confirmations”;s:2:”19″;s:7:”address”;s:34:”1Dyqf4aG3K83mCbsWyjqzUGkRh5xV3rXPw”;s:5:”value”;s:6:”747943″;s:13:”input_address”;s:34:”1GfxJgs8FU6JrKFJFALT3PZxgv9VR7UXnL”;s:3:”src”;s:6:”bcinfo”;s:8:”order_id”;s:2:”19″;s:10:”secret_key”;s:16:”BLAHBLAHBLAH”;s:6:”wc-api”;s:12:”BWWC_Bitcoin”;s:22:”input_transaction_hash”;s:64:”67252d19a2a6c5e962b638d80d41f5649153f5030d63f1176bf0b4aecf05d54f”;s:16:”transaction_hash”;s:64:”c4dbd20d745f4841a6cdcb7f043f886e9c915bf3addda848276e72d989725e2c”;}

So, this may be totally unrelated, but it’s the first time I’ve ever seen or heard of this happening.

On my test site, I created a single product worth $1 USD. I used the Bitcoin plugin to pay for a test order (for $1). When I submitted the transaction, everything looked normal. I paid the 0.007whatever BTC to the generated address of 1GfxJgs8FU6JrKFJFALT3PZxgv9VR7UXnL, which automatically created the next chained transaction to my final address of 1Dyqf4aG3K83mCbsWyjqzUGkRh5xV3rXPw. When the transaction was kicked off, I watched the blockchain manually to make sure everything was in order. The primary (temporary) transaction to 1GfxJgs8FU6JrKFJFALT3PZxgv9VR7UXnL took place and was confirmed within a few minutes, but the chained transaction to 1Dyqf4aG3K83mCbsWyjqzUGkRh5xV3rXPw was still waiting with 0 confirmations. For the first 36 hours I am absolutely positive the chained transaction was in the blockchain. After 48 hours however, the second transaction simply disappears into the void. It is gone from the blockchain entirely, so now my BTC are stuck at 1GfxJgs8FU6JrKFJFALT3PZxgv9VR7UXnL.

Of course, it’s impossible to verify the final address was ever part of the transaction except to do it again. I’ve never heard of this happening except through a double spend scenario, which can’t possibly be worth doing for 0.0074 BTC.

Idea’s? (You can see that the generated 1GfxJgs8FU6JrKFJFALT3PZxgv9VR7UXnL address is still in the blockchain with my money, but it looks like a single transaction from me to it. There is however, also another chained transaction from 1GfxJgs8FU6JrKFJFALT3PZxgv9VR7UXnL to 1F2tru7RrzuTph1oUa93nqVQfCvYABz8pe for 0.4BTC, which is not mine, and it didn’t come out of my account.

@webdesz, Excellent. Thanks dude/dudette. My version wasn’t nearly as pretty.
@gleb, Are you going to include the changes we’ve gone through here in a soonish release? Both the removal of MT.Gox exchange lookup and this QR code addition are working perfectly for me.

Yea, I’m torn on the secondary address transfer. Good for anonymity, bad for getting the transfer completed (minimum 2x longer for confirmation, assuming a fee has been paid for both).

While we’re on the topic of future functionality:
1. Calling up a QR code would be handy. I started writing this into your plugin, but my PHP skillz are embarrassingly poor.
2. Ability to manually query the blockchain to check confirmations. This would be handy in the event someone initiates a direct transfer. Ideally I’d be able to go into the order and see how many confirmations have been processed (but I suppose this is probably on the drawing board as you’re already discussing direct-to-wallet transfers).

It’d be nice to have the direct transfer option, but there are of course, vendors who would prefer to keep the transaction relatively anonymous for … er… accounting purposes. :p. I know the US does now officially recognize BTC as taxable income.

I suppose it doesn’t really matter so long as it eventually confirms. I’ve heard from some that it just won’t ever get confirmed. I’ll give it a full 24h and check again.

Okay, so the generated address has >100 confirmations but the receiving address has 0 as there was no fee attached. Will this transaction ever be confirmed with 0 fee?

OH Jesus! I didn’t know that. Okay, so the BTC won’t make it to my main address until after 100 confirmations on the temporary, and I won’t receive my IPN until then either correct?

Is this only an issue since we blocked MT.Gox? (I don’t see a point for the confirmation option otherwise).

Is it waiting for confirmation on the temporary address or the final address as specified in the configuration?
I configured for 1 confirmation (for testing) and sent myself a payment. The payment of course goes to the intermediary address, which has 2 confirmations, while the final address has 0 thus far.