-
Notifications
You must be signed in to change notification settings - Fork 159
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Protocol 19 #416
Protocol 19 #416
Conversation
…er from CAP40 into StrKey encoding/decoding.
…ntID for signed payload pojo to check discriminant on public key types
… instead of tx.timebounds
…loadSigner, pr feedback
Protocol 19 - CAP-40 Signed Payload Signer
…nbuild interface for consistency
…e functional approach instead
CAP 21, Transaction Preconditions and Account sequence fields
…e-built signatures onto a transaction
…yte expressions in test
payload signer signatures
#412: updated xdr files to latest from protocol 19 changes on core
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
some minor notes ⬇️
@@ -2,6 +2,26 @@ | |||
|
|||
As this project is pre 1.0, breaking changes may happen for minor version bumps. A breaking change will get clearly notified in this log. | |||
|
|||
## 0.32.0 (Pending) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we add something about gradle? I don't know anything about Java build envs but maybe a note here about the changes would be helpful
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
could mention, but the gradle version upgrade is not an external facing change, there is no developer touchpoint on it, it ends up here as pre-downloaded bins of the new version that developers still run with same cli gradlew build|test
, they don't need to do additional host system changes for the gradle upgrade.
inner.getTimeBounds(), | ||
inner.getNetwork() | ||
); | ||
this.mInner = new TransactionBuilder(inner.accountConverter, new Account(inner.getSourceAccount(), inner.getSequenceNumber() - 1), inner.getNetwork()) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is re-creating the account here problematic, since seqnum changes will not be reflected by the inner.getSourceAccount()
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
shouldn't be, kept the interface of this FeeBumpTransaction.Builder the same, the parameters are one-way inbound, doesn't mutate state of those, the new local instance of account is created here to use the new TransactionBuilder interface, but the seqnum increment change that new builder applies on that account instance are ignored here, since that info was never propagated outward.
.setBaseFee((int)inner.getFee()) | ||
.addOperations(Arrays.asList(inner.getOperations())) | ||
.addMemo(inner.getMemo()) | ||
.addPreconditions(new TransactionPreconditions.TransactionPreconditionsBuilder().timeBounds(inner.getTimeBounds()).build()) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can the final Transaction inner
have other preconditions that need to be added here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it's a V0
tx since it's in this block, so TimeBounds is the only precondition'able attribute available from that version of tx right?
@@ -157,11 +162,6 @@ public static ChallengeTransaction readChallengeTransaction(String challengeXdr, | |||
throw new InvalidSep10ChallengeException("The transaction sequence number should be zero."); | |||
} | |||
|
|||
// verify that transaction has time bounds set, and that current time is between the minimum and maximum bounds. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why gone?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
looked redundant, the test will fail on L165 if it were null
} | ||
|
||
mTimeoutSet = true; | ||
if (timeout > 0) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sanity check: there's no else
case, so will there be no preconditions built if timeout is set to inf?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes, good catch on the edge case, I've reviewed this and cleaned up and added more test coverage on setting timeouts.
preconditions.getV2().getTimeBounds().getMinTime().getTimePoint().getUint64(), | ||
preconditions.getV2().getTimeBounds().getMaxTime().getTimePoint().getUint64())); | ||
} | ||
if (preconditions.getV2().getExtraSigners() != null && preconditions.getV2().getExtraSigners().length > 0) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
some/most of these can never be null, afaict
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
there is no enforcement of null check in the generated xdr java stub classes, an instance of the stub class, xdr.PreconditionsV2 could be constructed with the builder which doesn't require any of these attribs to be set, which results in nulls:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🎉
KeyPair source = KeyPair.fromSecretSeed("SC4CGETADVYTCR5HEAVZRB3DZQY5Y4J7RFNJTRA6ESMHIPEZUSTE2QDK"); | ||
|
||
@Test | ||
public void testPaylodSignerKey() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is a typo here it should be testPayloadSignerKey
These are updates to the Java SDK to support Protocol 19.
This PR merges the feature branch that has already gone through prior reviews for specifics on CAP-21 and CAP-40 changes here:
https://github.com/stellar/java-stellar-sdk/pulls?q=is%3Apr+is%3Aclosed+label%3A%22Protocol+19%22
Closes #410
Closes #411
Closes #409
Closes #412