-
Notifications
You must be signed in to change notification settings - Fork 0
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
Non-pertinent transactions included into the transaction list TOKEN -g -u output for the newly spawned ATToken deck #162
Comments
I started to work on this yesterday. Will update this post while I progress. I think the first couple of errors, when you got the "red" PeerAssets general error should now be solved, as they were also occurring in another cases.
If the deck spawn transaction spends to the gateway address, then you should be able to claim it, regardless of it's a deck spawn transaction or not. I see that this is the case: as you spawned the deck from the same address you used as gateway address, the deck spawn transaction is also a gateway transaction because the change of the transaction went to the same address again. I can of course not claim that transaction as the gateway address is not in my wallet, but now that the other issue is resolved you could try to claim it again.
All transactions to the gateway address are gateway transactions where you could claim tokens for. So if the address was used before for other purposes, then all the transactions that went to it are gateway transactions. In theory, the issuer of an AT token could "cheat" spending coins all the time to his own AT token gateway address, and thus claiming tokens while he will benefit from that too. That's a problem of all ICO-style distributions so we can do nothing about it. He could even spend coins to the AT address and then re-spend them again to the address claiming tokens again and so on. This however would be detected easily by those willing to get these tokens who would for sure not tolerate this behaviour. By the way: I'm strongly suspecting that we can close this topic, because I think most related bugs are already fixed and the other main questions were answered here? |
I was trying to check the firsts command mentioned in the OP and have discovered that probably the
So the sender is not one of the two addresses I've used as main above. |
I don't exactly understand what you mean (if I understand wrong then please elaborate ...) but I think the potentially confusing thing here is simply that if you use Or have you used the command with |
Sorry you are right, I haven't paid enough attention to the line that I myself have cited: |
I've set
Then I've tried to claim some transaction that, if understand it right, wasn't originally meant as the burn transactions for that ATToken deck. For instance:
With the
While when I've run What's wrong with the 3 transactions mentioned above? Update:
and I can see it with
_
Even for the transactions that were created before the deck spawn? |
Thank you for the output with
If the token has no start deadline, then all PoB transactions from the genesis block on are valid for tokens. Just for this purpose of course the start and end deadline feature for PoB and AT tokens was implemented, so the official PoB token could have a start deadline near the deck spawn to prevent to dilute it too much. I'm still undecided on this, both approaches have pros and cons, should be discussed in a dedicated thread once launch approaches. UPDATE: Pushed commit after re-checking that claiming for transactions with OP_RETURN outputs works now. |
I've tested
However I've made some check in my logs it doesn't seem to me to have claimed them after you've published the new upgrade. The
I've tested whether it's possible to claim tokens for the burn transaction occurred earlier than the initial block of the deck.
For that purpose I've created the deck `my3` with the startblock `538869` and being on the main address `n3MtPoPaAREU5GEhAErBPuju83bVog2opz` and using the transaction `1a7fb3b69cde609467e5067e8573a189d6277aa9d71e0ddf8784d44fb480c931` which was created on the block `518555`, picked from my `transaction list -b` output, I've run `pobtoken claim 5b15a52c08554c2f3859fb274338622d52ce6702e2fcaca73e63ab445f1c29f1 1a7fb3b69cde609467e5067e8573a189d6277aa9d71e0ddf8784d44fb480c931` and have produced the claim transaction `0a130476b6d86ed0823f328bb6a8d4320f45fe1569f019c0d2674f359e8bc6a2`, but my `token balances -t 5b15a52c08554c2f3859fb274338622d52ce6702e2fcaca73e63ab445f1c29f1` is still 0.
I'd like to make the same test with the ATtoken, but because of the issue #185 I'm not able to for the moment.
|
Your transactions were already claimed indeed (from the output of
At least for the error you provided me the Your post about the error was also before the block these transactions were included in. Block 527476 was very likely after I provided that upgrade. I see my comment was on August 23, and the block including these transaction was on August 24. Maybe you claimed these transactions correctly after my upgrade?
As expected the balance is 0 because the referenced burn transaction was confirmed about 20000 blocks before the deck's startblock. Do you mean you want a warning for that so the claim tx is not created? That wold be a feature request, please open a new issue for that or even better put it into the "Nice to have..." issue. By the way: I've commented now on almost all of the issues that were still open. There are several I consider fixed or completed. Do you want me to close them? I left them open only for the case you wanted to review them, at least on some I don't really need new testing steps. |
Probably I did, but I'm not able to find that claim transactions in my logs. I'm closing this issue for the moment. Should we have some additional evidence there is an issue with this transactions we'll discuss it separately.
Yes I think we should add a compatibility check for the
I apologize, for I've been busy for about 10 days in the end of the August/beginning of September and as result I wasn't still be able to see all of your replies. |
I think I've at least partially found the cause of the issue please have a look into the last update here beneath.
I've run
token list -a
and picked my freshly spawned deckjohns_first_ATtoken
(ea7772ba8b5b297a35a50fac94431db5fc73731dfa7314dd53394d919ca4af58
).Then I've run
transaction list ea7772ba8b5b297a35a50fac94431db5fc73731dfa7314dd53394d919ca4af58 -g -u
to get a list of transactions to use withattoken claim
command and picked the following transaction from the list:Then I've run
attoken claim ea7772ba8b5b297a35a50fac94431db5fc73731dfa7314dd53394d919ca4af58 caeebb817dee5e1a7d0e9ef4e97cdc8b8c86ce33a416ae99da53eecc2a228e4a
and got the following error:The
attoken claim ea7772ba8b5b297a35a50fac94431db5fc73731dfa7314dd53394d919ca4af58 caeebb817dee5e1a7d0e9ef4e97cdc8b8c86ce33a416ae99da53eecc2a228e4a --debug
command outputs the following:Seeing that the output number of that transaction is different from 1, I've also tried
attoken claim ea7772ba8b5b297a35a50fac94431db5fc73731dfa7314dd53394d919ca4af58 caeebb817dee5e1a7d0e9ef4e97cdc8b8c86ce33a416ae99da53eecc2a228e4a:3 --debug
with the same result as well asattoken claim 7a2ae406ddf44ddb17532d4888fdc14573f52749445e9e014075c9f83cbe556f caeebb817dee5e1a7d0e9ef4e97cdc8b8c86ce33a416ae99da53eecc2a228e4a
.However when I've run
attoken claim 7a2ae406ddf44ddb17532d4888fdc14573f52749445e9e014075c9f83cbe556f 1008fea9dc5d1117c4f371cfbaaa835acc2390ae754c536cdcd0b1c0c89b3d0f
I've got a different message:Which is expected, since differently from the PoB decks the ATtoken decks have a different gateway address each.
Then I've run
attoken claim 7a2ae406ddf44ddb17532d4888fdc14573f52749445e9e014075c9f83cbe556f 384bce3ae91b6fac5e76b1f69d519c6372302ea38f4f16cbe55be871f126001c
for the transaction I know for sure was a burn transaction for theATTokenNewSpec
deck and everything went smoothly (transactionbca273987792b2c56e4f1e7df242e66523d836dec6b34f74aae7c4ff5a885b39
).Thinking the issue had to do with the fact that the decks I'm running this command for weren't spawned at that height yet I've picked the first transaction from my
transaction list ea7772ba8b5b297a35a50fac94431db5fc73731dfa7314dd53394d919ca4af58 -g -u
output:and run
attoken claim ea7772ba8b5b297a35a50fac94431db5fc73731dfa7314dd53394d919ca4af58 db3662131d5dbe31825cf72a3007580bcdbb60f798a419e81ebad7003d61b934
. The error was still there.However I've inquired further and have noticed that the list of transaction I'm seeing as
transaction list ea7772ba8b5b297a35a50fac94431db5fc73731dfa7314dd53394d919ca4af58 -g -u
output is not perfectly ordered by the blockheight, i.e. they have the ascending order from the transaction I've mentioned above till transaction83bf2fd400671fcc0f9b192bcefdbac73579b9489e07afae065ffa9bb3de2a85
(block499311
), then they restart from the transaction09e04a9ff7ef2b8218ff3a5c4ea5320b00d2f2151b8c0747b9f5bf68e8d3be78
, which is on the block480421
and go on in ascending blockheight order till the transactionb752aa0aee690f8554d649889689f3735554a68a6311207eef67b2d7f19306a6
:and then there are the following 4 transactions:
(for your convenience here
is the
transaction list ea7772ba8b5b297a35a50fac94431db5fc73731dfa7314dd53394d919ca4af58 -g -u
output I was getting)Moreover by inquiring further I've discovered that the transaction
db3662131d5dbe31825cf72a3007580bcdbb60f798a419e81ebad7003d61b934
I was trying to use to claim my attoken for is mentioned in the issue #153 as the claim transaction of the following command:pobtoken claim 1991d3d80c5df0d7c7b90afd4acf67d398cf8868f3a48b7568a96871bcc6f8e7 a45563c27360f25637f0cc12ca4d4d9b44849656ac3f56ce37125f220aa77331
.Having understood all that, I've picked the oldest transaction I'm seeing in my
transaction list ea7772ba8b5b297a35a50fac94431db5fc73731dfa7314dd53394d919ca4af58 -g -u
output:and tried to run
attoken claim ea7772ba8b5b297a35a50fac94431db5fc73731dfa7314dd53394d919ca4af58 b752aa0aee690f8554d649889689f3735554a68a6311207eef67b2d7f19306a6
and got theGeneral error raised by PeerAssets. Check if your input is correct.
again.I've searched in our issues here again and have discovered in the #151 that the
b752aa0aee690f8554d649889689f3735554a68a6311207eef67b2d7f19306a6
is the claim transaction of thepobtoken claim 95b24015ffb46d82015b709d774542fc4a53ccf27f72d973ed3fb18c384a80ca 7c8db9d1b18083b0cf440ec2b8ca0bee56afb55f5398ba185a2d80123fec4743
command.Looking into the
transaction list ea7772ba8b5b297a35a50fac94431db5fc73731dfa7314dd53394d919ca4af58 -g -u
output I've realized that none of the listed transaction is similar to the burning transactions I've created, because their amounts are different from what I've been typically burning for my tests.The only one that seemed similar to me was
4353f1513a7b210913c45d088e0c10c757644dfd279c4efbc4e4edf4cc592aa8
:so I've run
attoken claim ea7772ba8b5b297a35a50fac94431db5fc73731dfa7314dd53394d919ca4af58 4353f1513a7b210913c45d088e0c10c757644dfd279c4efbc4e4edf4cc592aa8
and was lucky this time, producing the claim transaction02a0081d8707ee274e02474f8e489af378050892a149de9c77ff7f519ce061c7
.I think it's possible that the majority of the transactions included into my
transaction list ea7772ba8b5b297a35a50fac94431db5fc73731dfa7314dd53394d919ca4af58 -g -u
are not burning transactions and also they doesn't have to do with the deckjohns_first_ATtoken
because the majority of them has happened earlier than the deck was spawned (on the499309
block).By the way the deck spawning transaction is also included into my
transaction list ea7772ba8b5b297a35a50fac94431db5fc73731dfa7314dd53394d919ca4af58 -g -u
output and of course I'm not able to claim it, receivingGeneral error raised by PeerAssets. Check if your input is correct.
if I try to runattoken claim ea7772ba8b5b297a35a50fac94431db5fc73731dfa7314dd53394d919ca4af58 ea7772ba8b5b297a35a50fac94431db5fc73731dfa7314dd53394d919ca4af58
._
Update1 25-07-2024
I don't know whether the issue has to do with the fact that my newly spawned deck
johns_first_ATtoken
has the sameat_address
andissuer
as the one I've been burning coins from.I'm going to make tests in the next hours trying to understand whether it's relevant.
_
Update2 25-07-2024
I've run
transaction list ea7772ba8b5b297a35a50fac94431db5fc73731dfa7314dd53394d919ca4af58 -g -u
again and compared its output with the same command's output I've got yesterday and have discovered that the transaction4353f1513a7b210913c45d088e0c10c757644dfd279c4efbc4e4edf4cc592aa8
has disappeared, as expected.But surprisingly the two claim transactions
bca273987792b2c56e4f1e7df242e66523d836dec6b34f74aae7c4ff5a885b39
and02a0081d8707ee274e02474f8e489af378050892a149de9c77ff7f519ce061c7
I've mentioned here above yesterday were included into the newer version.I've also noticed that there are many transactions included more than once both in the today's and the yesterday's outputs, for instance this one
35645ed307256f7ca9182b7c2d83fcbc1b15e8fa8e84e9bd00f5fa2427f23e65
._
Update3 25-07-2024
I've spawned another deck,
johns_attoken2
. Making tests with that deck I've discovered that if the burn transaction is done from itsat_address
the claim transaction remains in thetransaction list johns_attoken2 -g -u
output.I've also discovered that if I run
transaction list johns_attoken2 -g -u
ortransaction list johns_first_ATtoken -g -u
from any main address that is different from theirat_address
no unclaimed transaction is returned (the list is empty).However for the moment I don't have any hypothesis about the origin of the other transactions that are in the
transaction list johns_first_ATtoken -g -u
output, because some of them are clearly not claim transactions and many of them were created even before the deck was spawned.The text was updated successfully, but these errors were encountered: