Logged Conversation (all times UTC)
[00:15] <stellar-slack1> matschaffer: https://github.com/stellar/stellar-core/pull/457 is going to require reinitializing the testnet when it lands
[00:15] <stellar-slack1> (or, well, history in particular; it changes the naming scheme of history files)
[00:16] <stellar-slack1> very slightly, just enough to permit checkpoints made at random intervals as by manual intervention, rather than only on 64-ledger boundaries as currently
[00:18] <stellar-slack1> matschaffer: meanwhile I am switching over to trying to diagnose the stacktrace reporter tomorrow in final 2 days before vacation, happy day!
[00:31] <stellar-slack1> graydon: sweet. I’ll keep an eye out for it
[00:31] <stellar-slack1> and yeah, would be nice to figure out how to get stacks more reliably :simple_smile:
[11:36] <stellar-slack1> Another multi-sig question: If I have a transaction that I want multiple signers to sign and generate the transaction with the correct sequence and pass it around to the other signatories, does that mean that I can’t pass around another transaction for the same account and sequence+1 to other signatories and submit it before the original transaction?
[11:36] <stellar-slack1> https://github.com/stellar/stellar-core/blob/8f9051207549c2a518f51c93d715216cc5cc044c/src/transactions/TransactionFrame.cpp#L237-L241
[11:36] <stellar-slack1> In other words how does stellar-core deal with multiple concurrent multi-sig transactions? If no one ends up signing the first transaction or take a long time, that will block all subsequent transactions, and they’ll have to be resigned with a lower sequence?
[14:56] <stellar-slack1> @donovan: the recommended way to deal with the situation you describe is to have the root account of each transaction (the account specified as the `sourceAccount` in the `Transaction` object) be a different account for each multi-sig transaction you need in flight at the same time. That new account can be minimally funded, it only needs to have enough XLM to pay the fees for the transaction. And I believ
[14:56] <stellar-slack1> transaction include a `MergeAccountOp` as the final operation of the transaction to retrieve the funds held in reserve for the root account.
[14:58] <stellar-slack1> Ahh, nice, so a new account per multi-sig operation. Can you completely recover all funds from a temporary account and effectively delete it then, using MergeAccountOp?
[14:59] <stellar-slack1> yep
[14:59] <stellar-slack1> cool, problem solved :simple_smile:
[14:59] <stellar-slack1> less the fees spent on the transaction
[15:02] <stellar-slack1> Once an account has been deleted, how would you be able to query it’s prior state(s)? Would you have to go back into the history log? I’m guessing this is the job that Horizon intends to cover.
[15:06] <stellar-slack1> yeah, exactly. the live ledger will have no evidence it ever existed. It will be in the history archives, and horizon will have records
[15:07] <stellar-slack1> Well, here’s a tricky question. I create a temporary account, do some multi-sigs with it, incrementing the sequence each time, delete it, recreate it. What’s the sequence now? How does stellar-core know that the account has been previously used?
[15:08] <stellar-slack1> :simple_smile: we talked about that situation a lot. here’s our solution:
[15:09] <stellar-slack1> The sequence number is 64-bit, and the high 32-bits are set initially to the ledger in which an account came into existence.
[15:10] <stellar-slack1> Nice, a tonce mixed in with a nonce. Sounds like a good solution to me :simple_smile:
[15:10] <stellar-slack1> yes, you now have to look up the accounts sequence number after funding it, but we feel that’s better than the replay attacks :simple_smile:
About StellarVerse IRC Logger
StellarValue IRC Logger
is part of