Strona 1 z 1

WTF: The transaction is not final

: poniedziałek, 6 lutego 2017, 19:25
autor: domator
txid: e663195b3630ca665e9fcff2c27b8847bf13e607001e498af18c030c47c209ef
na blockchain.info: https://blockchain.info/pl/search?searc ... 0c47c209ef
"Transaction rejected by our node. Reason: The transaction is not final"
O co chodzi?
Wallet to core pod linuxem. Fee wyglada normalnie (0.0002992).

EDIT: sprawa nieaktualna. Po dluzszym czasie nagle poszlo. Ale jak ktos ma wiedze o co chodzi to chetnie wyslucham bo takie niespodzianki zawsze mnie irytuja....

WTF: The transaction is not final

: poniedziałek, 6 lutego 2017, 20:31
autor: pm7
@domator, Może się mylę, ale transakcja chyba miała w sobie ograniczenie, że nie może być wykopana przed blokiem 451822.

https://live.blockcypher.com/btc/tx/e66 ... c47c209ef/
Lock Time 451822
Tu jest nawet potwierdzenie tego:
http://bitcoin.stackexchange.com/questi ... by-default
// Discourage fee sniping.
//
// For a large miner the value of the transactions in the best block and
// the mempool can exceed the cost of deliberately attempting to mine two
// blocks to orphan the current best block. By setting nLockTime such that
// only the next block can include the transaction, we discourage this
// practice as the height restricted and limited blocksize gives miners
// considering fee sniping fewer options for pulling off this attack.
//
// A simple way to think about this is from the wallet's point of view we
// always want the blockchain to move forward. By setting nLockTime this
// way we're basically making the statement that we only want this
// transaction to appear in the next block; we don't want to potentially
// encourage reorgs by allowing transactions to appear at lower heights
// than the next block in forks of the best chain.
//
// Of course, the subsidy is high enough, and transaction volume low
// enough, that fee sniping isn't a problem yet, but by implementing a fix
// now we ensure code won't be written that makes assumptions about
// nLockTime that preclude a fix later.

txNew.nLockTime = chainActive.Height();

// Secondly occasionally randomly pick a nLockTime even further back, so
// that transactions that are delayed after signing for whatever reason,
// e.g. high-latency mix networks and some CoinJoin implementations, have
// better privacy.

if (GetRandInt(10) == 0)
txNew.nLockTime = std::max(0, (int)txNew.nLockTime - GetRandInt(100));
Blockchain.info zwyczajnie po raz kolejny pokazuje, że nie nadaje się do użytkowania.
Polecam przykładowo https://www.blocktrail.com/BTC.

WTF: The transaction is not final

: poniedziałek, 6 lutego 2017, 21:16
autor: domator
OK. A skad sie ten lock mogl wziac? To pierwsze pytanie. Wysylalem klasycznie "bitcoin-cli sendtoaddress xxxxx" bez zadnych dodatkowych parametrow. To raz.
Po drugie moze i blockchain sie nie nadaje ale ta transakcja faktycznie "wisiala" i u odbiorcy nie byla widoczna :-( wiec to chyba z blockchainem.info nie ma wiele wspolnego?

WTF: The transaction is not final

: poniedziałek, 6 lutego 2017, 21:24
autor: pm7
@domator, czy zajrzałeś może na drugi link, który jest w moim poście?
Bo (co powinieneś wiedzieć, jeżeli zajrzałeś) ten drugi link to czyjeś pytanie
"Why Bitcoin core creates time locked transactions by default?"
i odpowiedź na nie, czyli dokładnie to, o co pytasz.

Co do odbiorcy: a jakiego portfelu używa? Być może transakcja się odrobinę słabiej rozpropagowała, albo nie wyświetliła w portfelu przez lock_time.

WTF: The transaction is not final

: poniedziałek, 6 lutego 2017, 21:27
autor: domator
Zajarzalem teraz. Przepraszam za glupie pytanie. Tak, wyjasnione dobrze tam jest. Dzieki.