Pushing genesis back to 0

Technical questions about the Ripple API, the protocol, etc.
Google [Bot] like(s) this thread.

Re: Pushing genesis back to 0

Postby JoelKatz » Tue May 20, 2014 9:05 pm

donch wrote:So, bad news, unfortunately...

I scanned all the CommittedObjects tables in all the provided databases and found 1438 candidate transaction with metadata leaf nodes. I extracted the transaction part using the variable bytes length provided and prepended the transaction id hash prefix and performed the hash to create the transaction id (not transaction node hash). None of these hashes matched the expected 193 PreviousTxnId's found in a full dump of ledger 32570.

Oh no. Are you positive the hashing process was done correctly? Did you double check with a leaf node whose transaction ID was known?
User avatar
JoelKatz
Ripple
Ripple
 
Posts: 1859
Joined: Sun Dec 23, 2012 3:45 pm
Location: Oakland, CA

Re: Pushing genesis back to 0

Postby donch » Tue May 20, 2014 9:10 pm

JoelKatz wrote:
donch wrote:So, bad news, unfortunately...

I scanned all the CommittedObjects tables in all the provided databases and found 1438 candidate transaction with metadata leaf nodes. I extracted the transaction part using the variable bytes length provided and prepended the transaction id hash prefix and performed the hash to create the transaction id (not transaction node hash). None of these hashes matched the expected 193 PreviousTxnId's found in a full dump of ledger 32570.

Oh no. Are you positive the hashing process was done correctly? Did you double check with a leaf node whose transaction ID was known?


Yes I did a test with:

https://ripple.com/tools/info/#9503B3B9 ... 648F47E90A

PreviousTxnId: 27C8D37187C3ED0123AFE9FDF8A728F637DE8F28B0D2E2CF5BD6F2DABCAD64D2

Code: Select all
{
  "id": 1,
  "command": "tx",
  "transaction": "27C8D37187C3ED0123AFE9FDF8A728F637DE8F28B0D2E2CF5BD6F2DABCAD64D2",
  "binary": true
}


Code: Select all
{
  "id": 1,
  "status": "success",
  "type": "response",
  "result": {
    "hash": "27C8D37187C3ED0123AFE9FDF8A728F637DE8F28B0D2E2CF5BD6F2DABCAD64D2",
    "inLedger": 5999999,
    "ledger_index": 5999999,
    "meta": "201C00000000F8E511006125005B8D7E55FCB1A2361D36BE7904EE6508064CA51BB7A921D212B07C6419CC18E9FF160EB7562CF524584FC1DDA14ABF3AF2134F54F29BA2AD9206BD9436E4426A3AFBD298DCE624000DAEC062400001854A74BD8CE1E7220000000024000DAEC12D0000000062400001854A5D9EF28114921A8D4667FEC23671825D2FDDE08B719DC77C25E1E1E511006125005B65915567D6840B96A62E3B25AC18C0E954AC12F558C62852184B918EF8947A5F567D8756D8CAD44D3DB0265913DEC5491E05BB572FB224B7DAD039022C5A4D9205F21629E6624000000009404834E1E7220000000024000000042D000000006240000000095765D481149E052E8FDF9D6AB1C4D677E35AFA7FD9BE6B1230E1E1F1031000",
    "tx": "120000220000000024000DAEC050118733FF147C084160B2925C3D4CFACD0100000000000000000000000000000000614000000000171DA06840000000000000FA732103D7895A6AE8F78A1B136903ABCCDC7ECEB1C7C5B2A37DBE47B6C268B9CB46157174463044022053FA4A494028DE090C1DFD70CAFA98F0C8887D1CE6971CE4AC8AAFBBFC669617022053066CC66200667FAA0E55840CAB49F3955908BC0C7A0433038326EA743D9E5A8114921A8D4667FEC23671825D2FDDE08B719DC77C2583149E052E8FDF9D6AB1C4D677E35AFA7FD9BE6B1230",
    "validated": true
  }
}


Code: Select all
echo 54584E00120000220000000024000DAEC050118733FF147C084160B2925C3D4CFACD0100000000000000000000000000000000614000000000171DA06840000000000000FA732103D7895A6AE8F78A1B136903ABCCDC7ECEB1C7C5B2A37DBE47B6C268B9CB46157174463044022053FA4A494028DE090C1DFD70CAFA98F0C8887D1CE6971CE4AC8AAFBBFC669617022053066CC66200667FAA0E55840CAB49F3955908BC0C7A0433038326EA743D9E5A8114921A8D4667FEC23671825D2FDDE08B719DC77C2583149E052E8FDF9D6AB1C4D677E35AFA7FD9BE6B1230 | xxd -r -p | shasum -a512 | cut -c-64
27c8d37187c3ed0123afe9fdf8a728f637de8f28b0d2e2cf5bd6f2dabcad64d2
donch
 
Posts: 796
Joined: Mon Nov 18, 2013 8:07 pm

Re: Pushing genesis back to 0

Postby Sukrim » Tue May 20, 2014 9:23 pm

Could you post a list of these transaction hashes that are contained and cross-reference them with the ones that are in the transaction.db files? This way we could at least know if some potential candidates exist at all in these dumps or if they all belong to previous ledgers.

All discussions aside, thanks to donch for reacting so fast and taking less than a day to analyze this dump of data and thanks to JoelKatz for providing it in the first place! :)
Sukrim
 
Posts: 1826
Joined: Mon May 20, 2013 10:44 am

Re: Pushing genesis back to 0

Postby donch » Tue May 20, 2014 9:39 pm

Sukrim wrote:Could you post a list of these transaction hashes that are contained and cross-reference them with the ones that are in the transaction.db files? This way we could at least know if some potential candidates exist at all in these dumps or if they all belong to previous ledgers.

All discussions aside, thanks to donch for reacting so fast and taking less than a day to analyze this dump of data and thanks to JoelKatz for providing it in the first place! :)


Here you go:

https://gist.github.com/donovanhide/577 ... 20f03e6c1e

The transaction ids are the first 64 hex characters in the first slot in the gist, followed by the hex form of the transaction with the transaction id prefix. They aren't deduped. Again no wanted transaction ids were found.

It is all a bit complicated and undocumented but I hope that helps :-)
donch
 
Posts: 796
Joined: Mon Nov 18, 2013 8:07 pm

Re: Pushing genesis back to 0

Postby JoelKatz » Tue May 20, 2014 9:57 pm

Why are you looking in the transaction database? Metadata leaf nodes are in the hashnode database.
User avatar
JoelKatz
Ripple
Ripple
 
Posts: 1859
Joined: Sun Dec 23, 2012 3:45 pm
Location: Oakland, CA

Re: Pushing genesis back to 0

Postby donch » Tue May 20, 2014 10:08 pm

I'm not:

https://gist.github.com/donovanhide/0e4 ... 43127bbfc5

Sukrim requested it, so I did this as well:

https://gist.github.com/donovanhide/577 ... 20f03e6c1e

It doesn't really matter anyway, they are virtually the same dataset.
donch
 
Posts: 796
Joined: Mon Nov 18, 2013 8:07 pm

Re: Pushing genesis back to 0

Postby Sukrim » Tue May 20, 2014 10:31 pm

JoelKatz wrote:Why are you looking in the transaction database? Metadata leaf nodes are in the hashnode database.

My idea was that the ones in the transaction databases are "useless" (belonging to pre-genesis ledger chains), however it might be the case that there are transactions in the hashnodes that are not visible in the transaction.db files. These might be the ones that are used in the current ledger too.
Sukrim
 
Posts: 1826
Joined: Mon May 20, 2013 10:44 am

Re: Pushing genesis back to 0

Postby dchapes » Wed May 21, 2014 3:10 pm

Hurukan wrote:I hope you will help us against trollers...

Because you and we will have the following sarcastic remarks ;)

Ignorant trollers will troll no matter what you do.
Just say the Ripple genesis ledger is numbered 32570 instead of 0 or 1.
:-)
OpenPGP KeyID: france short hawaii
Although I moderate and post a lot on the Ripple forum, I am not associated with RippleLabs; I'm just a Ripple user. I speak only for myself.
I am somewhat associated with RippleFederation and a minor financial supporter of RippleUnion.
dchapes
 
Posts: 1445
Joined: Thu Mar 14, 2013 1:08 pm
Location: Ontario, Canada

Re: Pushing genesis back to 0

Postby donch » Wed May 21, 2014 3:13 pm

dchapes wrote:
Hurukan wrote:I hope you will help us against trollers...

Because you and we will have the following sarcastic remarks ;)

Ignorant trollers will troll no matter what you do.
Just say the Ripple genesis ledger is numbered 32570 instead of 0 or 1.


That doesn't help answer the question of how the large holders of XRP received their holdings. You can't say Ripple is an open ledger when the largest holders of XRP cannot be accounted for. It is a major flaw. The decision to not restart the ledger when the bug was first spotted was a bad one. To wait over a year to reveal the data does not exist is an even worse one.
donch
 
Posts: 796
Joined: Mon Nov 18, 2013 8:07 pm

Re: Pushing genesis back to 0

Postby donch » Wed May 21, 2014 8:29 pm

Just to be sure, I checked the first full dump of the ledger (~500GB) that I received from Ripple Labs to make sure it didn't contain any of the transactions known to exist before ledger 32570. If they were found then there would be a transaction with metadata node with the expected transaction id at the end of the node value. Unfortunately apart from some spurious Inner Nodes with ledger 0, the earliest transaction found containing the expected hash (in it's metadata not as the expected suffix) was 38,128 (the transaction is actually listed in ledger 38,219).

https://gist.github.com/donovanhide/3b6 ... 610789fcc1

The second slot is the found nodes, some of which are transactions with 4534E4400xx120000yy where xx is the variable length and yy is the transaction type. Nodes are sorted by ledger appearance, which is the first 4 bytes of the node value.

The third slot is the wanted transaction ids.

So, as Sukrim expressed an interest in, there is no sign of these transactions in this dump. Does anyone at Ripple Labs have any other hopes? Is there an EC2 instance that has been in continuous operation since late December 2012 that might have some vestiges lying around? If there is no chance of the data existing, would be good to get a clear statement of that fact.
donch
 
Posts: 796
Joined: Mon Nov 18, 2013 8:07 pm

PreviousNext

Return to Developers

Who is online

Users browsing this forum: MSN [Bot] and 10 guests