I thought locktime transactions were non-standard, and therefore extremely hard to get into the blockchain, because locktime is used to delay when a transaction can at the most early be confirmed, and chaining an unconfirmed tx after such a tx which is prevented from confirming makes it too easy to cheat with 0-confirmation purchases. If this is all locktime does, then once the tx is in the blockchain it should be irrelevant that it was once locked.
Perhaps Armory should ignore (or color in a strange color) any unconfirmed TX with a locktime, but treat it as any other tx once confirmed.
Topic: Armory is not acknowledging a transaction I got. (Read 1061 times)
Personally, I feel a single confirmation should overrule it all, shouldn't it? My understanding is if it's got a single confirmation, and, that block isn't invalidated/orphaned, then, that transaction can't be taken back, or, am I misunderstanding?
You're probably correct, but I haven't spent much time thinking about it. Honestly, this isn't a common transaction type, and I just wanted to make sure it wasn't totally neglected, without opening up any holes. If this becomes more common, I'll simply implement the logic correctly, the same way Bitcoin-Qt does.
Yes, Armory will not show you any tx that don't satisfy "isFinal()" conditions. A transaction is considered not final if:
(1) Locktime+OneDay is in the future
(2) Any TxIns have non-0xFFFFFFFF sequence numbers
Why is one day added to the locktime? Because I was being ultra-conservative, and wasn't 100% positive that I was handling the timezones correctly (which would open up an attack vector to pay someone using Armory then retract it). Therefore it should show up by tomorrow.
I would've been smarter about it, but I didn't have the patience to go hand-craft some transactions and mess with my locale to test the timezones, just to handle a case that 99.99% of users will never hit. Congrats on being in the top 0.01%
(1) Locktime+OneDay is in the future
(2) Any TxIns have non-0xFFFFFFFF sequence numbers
Why is one day added to the locktime? Because I was being ultra-conservative, and wasn't 100% positive that I was handling the timezones correctly (which would open up an attack vector to pay someone using Armory then retract it). Therefore it should show up by tomorrow.
I would've been smarter about it, but I didn't have the patience to go hand-craft some transactions and mess with my locale to test the timezones, just to handle a case that 99.99% of users will never hit. Congrats on being in the top 0.01%
So, it will appear tomorrow in my transaction list instantly with however many confirmations it has 'n all that?
Personally, I feel a single confirmation should overrule it all, shouldn't it? My understanding is if it's got a single confirmation, and, that block isn't invalidated/orphaned, then, that transaction can't be taken back, or, am I misunderstanding?
Yes, Armory will not show you any tx that don't satisfy "isFinal()" conditions. A transaction is considered not final if:
(1) Locktime+OneDay is in the future
(2) Any TxIns have non-0xFFFFFFFF sequence numbers
Why is one day added to the locktime? Because I was being ultra-conservative, and wasn't 100% positive that I was handling the timezones correctly (which would open up an attack vector to pay someone using Armory then retract it). Therefore it should show up by tomorrow.
I would've been smarter about it, but I didn't have the patience to go hand-craft some transactions and mess with my locale to test the timezones, just to handle a case that 99.99% of users will never hit. Congrats on being in the top 0.01%
(1) Locktime+OneDay is in the future
(2) Any TxIns have non-0xFFFFFFFF sequence numbers
Why is one day added to the locktime? Because I was being ultra-conservative, and wasn't 100% positive that I was handling the timezones correctly (which would open up an attack vector to pay someone using Armory then retract it). Therefore it should show up by tomorrow.
I would've been smarter about it, but I didn't have the patience to go hand-craft some transactions and mess with my locale to test the timezones, just to handle a case that 99.99% of users will never hit. Congrats on being in the top 0.01%
Transaction:-
https://blockchain.info/tx/324185cc3d5e63eb3276c7d41956d0651ad14674e0452a1f5c77a5110125082e
Raw transaction:-
https://blockexplorer.com/rawtx/324185cc3d5e63eb3276c7d41956d0651ad14674e0452a1f5c77a5110125082e
Why I think there's an issue:-
Instead of:-
I tried 'rescanning databases' to no avail.
https://blockchain.info/tx/324185cc3d5e63eb3276c7d41956d0651ad14674e0452a1f5c77a5110125082e
Raw transaction:-
https://blockexplorer.com/rawtx/324185cc3d5e63eb3276c7d41956d0651ad14674e0452a1f5c77a5110125082e
Why I think there's an issue:-
Code:
"lock_time": 1392854400,
"sequence": 0
Instead of:-
Code:
"lock_time": 0,
"sequence": 0xFFFFFFFF
I tried 'rescanning databases' to no avail.
Jump to: