Essays, Posts & Presentations

Investigating the Ethereum Gold-Bug and Blockchain in the Wolfram Language

Christian Pasquel

Author

Christian Pasquel

Title

Investigating the Ethereum Gold-Bug and Blockchain in the Wolfram Language

Description

Quote from Poe’s ‘The Gold Bug’ sparks search for a real blockchain gold-bug. Exploration of the data surrounding the Ethereum blockchain event using the Wolfram Language.

Category

Essays, Posts & Presentations

Keywords

Developer Insights, Recreational Computation, Uncategorized

URL

http://www.notebookarchive.org/2020-10-7f6kn8a/

DOI

https://notebookarchive.org/2020-10-7f6kn8a

Date Added

2020-10-16

Date Last Modified

2020-10-16

File Size

2.5 megabytes

Supplements

Rights

Redistribution rights reserved

Investigating the Ethereum Gold-Bug and Blockchain in the Wolfram Language

October 16, 2020 — Christian Pasquel, Manager, Wolfram Research South America Connectivity

Blockchain was integrated into the Wolfram Language in 2018 with the release of Version 11.3, featuring a set of functions that is constantly improved and expanded upon by our team. Currently supporting a seamless connection to the Bitcoin, Ethereum, ARK and bloxberg mainnets, testnets and devnets, Wolfram introduced to the distributed ledger technology (DLT) space its philosophy of injecting computational intelligence everywhere through Wolfram Blockchain Labs, with the mission of enabling blockchain-based commerce and business model innovation.

The current pandemic has touched many aspects of our lives, and while my work at Wolfram has not been affected, my personal routine endured some changes due to the lack of social activity. A positive addition to my lifestyle has been an increase in the time I dedicate every night to reading novels and stories. During this nightly ritual, I stumbled upon Edgar Allan Poe’s book Tales of Mystery & Imagination. It’s a posthumous compilation of stories by the American author, who was fascinated by cyphers during his life. This collection of writings features one famous short story that caught my attention, “The Gold-Bug.” First published in 1843, the story follows a character becoming obsessed with a golden beetle and a cypher he unriddles using cryptography techniques that lead him through a data-driven quest looking for a hidden fortune.

My work on blockchains with the Wolfram Language keeps me in a state of mind where I try to absorb everything I can about the topic. I was captivated by the use of cryptography in the story, but one particular line describing the artifact that held the data resonated with me:

“Parchment is durable—almost imperishable. Matters of little moment are rarely consigned to parchment.... It was just such a slip, indeed, as might have been chosen for a memorandum—for a record of something to be long remembered, and carefully preserved.”

I thought that sounded like a blockchain, so I decided to look for a real “blockchain gold-bug” and use the Wolfram Language blockchain tools to explore it.

I came across an event that happened in the Ethereum blockchain on June 10, 2020. That day, some headlines in the blockchain space claimed a transaction moving $134 USD was included in the Ethereum mainnet, featuring $2.6 million USD in fees. The theories surrounding the millionaire event ranged from a computer bug to money laundering. From my perspective, the former is a bug in the code (that could be fixed with a software patch) and the latter is a bug in the legal system (that one day could be handled by a computational contract). This looked like a good candidate for my quest.

The Tale of the First Transaction The news articles referenced transaction ca8f8c315c8b6c48cee0675677b786d1babe726773829a588efa500b71cbdb65 as the protagonist of the story.

Let’s see some information about it:

In[]:=

$BlockchainBase="Ethereum";tx1="ca8f8c315c8b6c48cee0675677b786d1babe726773829a588efa500b71cbdb65";tx1Data=BlockchainTransactionData[tx1];tx1Data//Dataset

Out[]=

TransactionID

ca8f8c315c8b6c48cee0675677b786d1babe726773829a588efa500b71cbdb65

BlockHash

c5730a95345a5c167af0f697496347d4369fd9431899f253be7217953f4586fa

BlockNumber

10237208

Confirmations

772583

Timestamp

Wed 10 Jun 2020 04:47:04

Status

True

TransactionIndex

Sender

cDd6a2b9DD3e386C8cd4a7ada5cab2F1c561182D

Receiver

12D8012Cb8B268D59fbf0b2F7C2302F25EC74E84

Amount

550000000000000000

wei

GasUsed

21000

GasPrice

508034850000000000

wei

Fee

10668731850000000000000

wei

TransactionCount

ByteCount

113

TransactionDigest

ByteArray

32 bytes



DigitalSignature

DigitalSignature

type: elliptic curve (secp256k1)

signature type: deterministic



SenderPublicKey

PublicKey

type: elliptic curve (secp256k1)

public key size: 512 bits



Let’s also focus on the properties that caused an avalanche of tweets that day:

In[]:=

Lookup[tx1Data,{"Amount","Fee"}]

Out[]=

{

550000000000000000

wei

10668731850000000000000

wei

}

To make it very easy to read, we can show these amounts in US dollars (using the current ether exchange rate):

In[]:=

AccountingForm[CurrencyConvert[#,"USDollars"],DigitBlock3]&/@Dataset[tx1Data][{"Amount","Fee"}]

Out[]=

Amount	$ 221.73
Fee	$ 4,301,133.

This is indeed a very strange and unusual transaction because of the excessive value of the fee. To have a reference, let’s choose five random transactions from the same block where the mysterious transaction was included—10237208—and inspect the fees:

In[]:=

randomTXsData=CurrencyConvert[BlockchainTransactionData[RandomSample[DeleteCases[BlockchainBlockData[tx1Data["BlockNumber"]]["TransactionList"],tx1],5],{"Amount","Fee"}],"USDollars"];

In[]:=

BarChartrandomTXsDataAll,2,PlotLabel

Mean



Out[]=

The highest fee is less than one dollar, with a mean of 42 cents. Note that the transaction with the largest amount didn’t require the most expensive fee:

In[]:=

Dataset[Function[u,<|"Fee"u〚2〛,"Amount"u〚1〛|>]/@randomTXsData][ReverseSortBy[#Fee&]]

Out[]=

Fee	Amount
$0.76	$0.00
$0.41	$0.00
$0.33	$37.86
$0.32	$1694.39
$0.29	$39.54

The transaction we are investigating was mined by the mining and staking pool SparkPool. Some hours after that, they tweeted about it:

In[]:=

twitter=ServiceConnect["Twitter"]

Out[]=

ServiceObject

Twitter

Not Connected



In[]:=

twitter["GetTweet","TweetID"1270688700968480768]//Dataset

Out[]=

ID	1270688700968480768
Text	We are further investigating the incident of unusually high tx fee, and you are welcome to provide clues to support@sparkpool.com. SparkPool has had the experience of handling similar issues properly. There will be a solution in the end. https://t.co/mZc49Q0Y4r
Date	Wed 10 Jun 2020 07:06:09
Username	sparkpool_eth
URL	https://twitter.com/sparkpool_eth/status/127068870...

In[]:=

Normal[%]["Text"]

Out[]=

We are further investigating the incident of unusually high tx fee, and you are welcome to provide clues to support@sparkpool.com. SparkPool has had the experience of handling similar issues properly. There will be a solution in the end. https://t.co/mZc49Q0Y4r

The Mysterious Sender But who sent this transaction? Is there something we can learn about the sender?

In[]:=

tx1Data["Sender"]

Out[]=

cDd6a2b9DD3e386C8cd4a7ada5cab2F1c561182D

At the time of writing, the most current information we have is:

In[]:=

tx1SenderData=BlockchainAddressData[tx1Data["Sender"]];tx1SenderData//Dataset

Out[]=

Address	cDd6a2b9DD3e386C8cd4a7ada5cab2F1c561182D
Type	Externally Owned Account
Balance	2530812643939969 wei
ValueInUSDollars	$0.87
TransactionCount	2604
TotalTransactions	9262
TotalInternalTransactions	0
TransactionList	{ … 20 }

The first thing we can clearly see is that this address has received more transactions than it has sent:

In[]:=

Dataset

txs data



Out[]=

Received	6658
Sent	2604
Total	9262
Current Balance	$0.88
Current Balance (ether)	Ξ0.00253081

The account holds a current balance of 88 cents.

As we saw before, the transaction was added to block 10237208, mined on June 10:

In[]:=

BlockchainBlockData[tx1Data["BlockNumber"]]//Dataset

Out[]=

BlockHash	c5730a95345a5c167af0f697496347d4369fd9431899f253be7217953f4586fa
BlockNumber	10237208
Timestamp	Wed 10 Jun 2020 04:47:04
ByteCount	37663
Nonce	∞
Version	0
Confirmations	746987
PreviousBlockHash	a0f1b15ebb05d5c5acf7336161b104e0e610c4d9e2ae1c1cfc06f30fc22240f4
MerkleRoot	b082416d094c2a38bb8785202df8ed5ad4e43ba2185721b8cbdcef8f54ce6542
TotalTransactions	169
TransactionList	{ … 169 }

What was the state of this address during the time of block 10237208? We can see that too:

In[]:=

tx1SenderPastData=BlockchainAddressData[<|"Address"tx1Data["Sender"],"BlockNumber"tx1Data["BlockNumber"]|>];tx1SenderPastData//Dataset

Out[]=

Address	cDd6a2b9DD3e386C8cd4a7ada5cab2F1c561182D
Type	Externally Owned Account
Balance	46719854975669913130000 wei
ValueInUSDollars	$1.13552× 7 10
TransactionCount	57
BlockTransactions	2
BlockInternalTransactions	0
TotalTransactions	5818
TotalInternalTransactions	0
TransactionList	{ … 20 }

At that height the address had a balance of more than 46,000 ethers (the fundamental cryptocurrency used on the Ethereum blockchain):

In[]:=

AccountingForm[N@CurrencyConvert[tx1SenderPastData["Balance"],"Ethers"],DigitBlock3]

Out[]=

46,719.9

As of today, the equivalent is more than $11,000,000:

In[]:=

AccountingForm[tx1SenderPastData["ValueInUSDollars"],DigitBlock3]

Out[]=

11,355,246.

Also, up to that block, the address had sent 57 transactions:

In[]:=

tx1SenderPastData["TransactionCount"]

Out[]=

There’s no information about this address before block 10219082:

In[]:=

BlockchainAddressData[<|"Address"tx1Data["Sender"],"BlockNumber"10219082-1|>]

Out[]=

Missing[NotAvailable]

So this address first happened in the blockchain during block 10219082. This occurred at the following day and time:

In[]:=

BlockchainBlockData[10219082,"Timestamp"]

Out[]=

Sun 7 Jun 2020 09:04:09GMT-5.

This was about 2.8 days before the uncanny transaction:

In[]:=

tx1Data["Timestamp"]-BlockchainBlockData[10219082,"Timestamp"]

Out[]=

2.82147

days

A Story about Transactions Let’s explore the history of the sender’s transactions and try to spot any unusual features

To get the sender’s transaction log, I wrote a script to extract the information starting from the first block where this address first appeared in the blockchain and ending with the block where the millionaire-fee event happened.

You don't need to run the script because it will take a while to extract the data from the blockchain. For that, you can get the public data I put in the Wolfram Cloud:

In[]:=

txData=CloudGet[CloudObject[

https://www.wolframcloud.com/obj/christianp

/Blog/CO/01-txData

]];

Here is the code for the script in case you want to know the details:

In[]:=

PutAppend[#BlockchainAddressData[<|"Address"tx1Data["Sender"],"BlockNumberInterval"{#,#}|>,"TransactionList"],FileNameJoin[{NotebookDirectory[],"txListDataFull.wl"}]]&/@Range[10219082,tx1Data["BlockNumber"]]

In[]:=

txList=Import[FileNameJoin[{NotebookDirectory[],"txListDataFull.wl"}],"ExpressionList"];txList=DeleteCases[txList,__Missing];txList=Flatten[Values[txList]];

In[]:=

PutAppend[#Lookup[BlockchainTransactionData[#,BlockchainBase"Ethereum"],{"Fee","GasUsed","ByteCount"}],FileNameJoin[{NotebookDirectory[],"txDataFull.wl"}]]&/@Lookup[txList,"TransactionID"]

In[]:=

txListData=Import[FileNameJoin[{NotebookDirectory[],"txDataFull.wl"}],"ExpressionList"];

In[]:=

txData=Function[u,Block[{txid=Lookup[u,"TransactionID"],txData},txData=<|MapThread[Rule,{{"Fee","GasUsed","ByteCount"},txid/.txListData}]|>;Join[u,txData]]]/@txList;

(Note: you should add a delay to these scripts so the rate limit when connecting to the Wolfram nodes is not exceeded.)

With this data, we can make a plot of the sender’s activity by showing the number of transactions over time starting from the point the address appeared in the blockchain to the moment the first event happened:

In[]:=

txsSentTally=Tally[Cases[Lookup[txData,{"Timestamp","Sender"}],{ts_,tx1Data["Sender"]}ts]];txsReceivedTally=Tally[Cases[Lookup[txData,{"Timestamp","Receiver"}],{ts_,tx1Data["Sender"]}ts]];

In[]:=

DateListPlot

txs sent data

txs received data

,

Options



Out[]=

	Sent
	Received

These are the total numbers of transactions received and sent during that time interval:

In[]:=

BarChart

TXs sent (1)

TXs received (1)

,

Options



Out[]=

A small detail caught my attention when I first saw these plots. If we tally the timestamps at which more than one transaction was sent, we get this:

In[]:=

GridCases[txsSentTally,{_,n_}/;n>1],

Options



Out[]=

Mon 8 Jun 2020 00:06:44GMT-5.	2
Wed 10 Jun 2020 04:28:33GMT-5.	2
Wed 10 Jun 2020 04:47:04GMT-5.	2

Do you see it? The timestamp of the first transaction is there:

In[]:=

tx1Data["Timestamp"]

Out[]=

Wed 10 Jun 2020 04:47:04GMT-5.

That means two transactions were sent at the same time, or, to be more precise, we can say they were included in the same block because we can’t really know if both transactions were actually sent to the blockchain simultaneously or if they just happened to be chosen by the miner for inclusion in the same block by chance.

Additionally, based on the transaction index, we can see that the mysterious transaction is the first one in the block:

In[]:=

Dataset[BlockchainTransactionData[Cases[Lookup[txData,{"TransactionID","Timestamp","Sender"}],{txid_,tx1Data["Timestamp"],tx1Data["Sender"]}txid]]][SortBy[#TransactionIndex&]][All,{"TransactionID","TransactionIndex","Amount","Fee"}]

Out[]=

TransactionID	TransactionIndex	Amount	Fee
ca8f8c315c8b6c48cee0675677b786d1babe726773829a588efa500b71cbdb65	0	550000000000000000 wei	10668731850000000000000 wei
153d9f4e50df967da12a347859fcbf83756aa16ce3388f0660e86948cabaf352	33	1199195233110000000 wei	1260000000000000 wei

Another obvious feature is a period of high activity when many transactions were received simultaneously:

In[]:=

DateListPlot

txs sent data

txs received data

,

Options



Out[]=

	Sent
	Received

This happened between the following points in time:

In[]:=

mostActivePeriod=MinMax[Cases[txsReceivedTally,{ts_,n_}/;n≥3ts]]

Out[]=



Tue 9 Jun 2020 06:12:34GMT-5.

Tue 9 Jun 2020 14:23:24GMT-5.



In[]:=

TimelinePlot

most active period



Out[]=

That’s roughly eight hours:

In[]:=

Abs[Subtract@@mostActivePeriod]

Out[]=

8.18056

And 4,127 transactions were received in that time frame:

In[]:=

CasesLookup[txData,{"Timestamp","Receiver"}],{ts_,tx1Data["Sender"]}/;

Tue 9 Jun 2020 06:12:34GMT-5.

≤ts≤

Tue 9 Jun 2020 14:23:24GMT-5.

//Length

Out[]=

4127

In other words, 73% of transactions received by the address before the first event happened during the high-activity period:

In[]:=

N@Quantity[%*100/(Cases[Lookup[txData,{"Timestamp","Receiver"}],{ts_,tx1Data["Sender"]}]//Length),"Percent"]

Out[]=

73.1089

While we can’t come to a clear conclusion about why the activity increased during this period, let’s inspect the amount of wei (the smallest denomination of ether) received through it:

In[]:=

totalWei=Total[Cases[Lookup[txData,{"Timestamp","Receiver","Amount"}],{ts_,tx1Data["Sender"],amount_}/;ts≥mostActivePeriod〚1〛amount]]

Out[]=

40863008892268593460000

wei

This accounts for about 87.46% of the sender’s balance at block height 10237208:

In[]:=

N@Quantity[totalWei*100/tx1SenderPastData["Balance"],"Percent"]

Out[]=

87.4639

Therefore, we know that most of the fortune the sender was holding at the height of this block was received during that high-activity time span.

When we go back to consider the sender’s history before the first event, we can clearly see that most transactions were sent during the tenth day of June (note that no transactions were sent the day before the address received most of its money):

In[]:=

GridReverseSortBy[Tally[DateObject[#,"Day"]&/@Cases[Lookup[txData,{"Timestamp","Sender"}],{ts_,tx1Data["Sender"]}ts]],Last],

Options



Out[]=

Day: Wed 10 Jun 2020	53
Day: Mon 8 Jun 2020	3
Day: Sun 7 Jun 2020	1

That happened across a span of around four hours:

In[]:=

txsSentJune10=CasesLookup[txData,{"Timestamp","Sender"}],{ts_,tx1Data["Sender"]}/;ts>

Wed 10 Jun 2020 00:00:00GMT-5.

ts;

In[]:=

Abs[Subtract@@MinMax[txsSentJune10]]

Out[]=

4.19389

In[]:=

TimelinePlot

activity period



Out[]=

In[]:=

DateListPlotTally[txsSentJune10],

Options



Out[]=

Sent

Let me remind you this is the same day as when the high-fee incident occurred.

We can also compute the mean frequency at which transactions were sent by getting the time between each transaction:

In[]:=

txSentTimeDiff=Abs/@Subtract@@@PartitionCasestxsSentTallyAll,1,ts_/;ts≥

Wed 10 Jun 2020 00:35:26GMT-5.

,2,1;

We see a minimum of 24 seconds and a maximum of 58.1 minutes of time difference between transactions:

In[]:=

MinMax[txSentTimeDiff]

Out[]=

{

24.

58.1

min

}

Let’s use the median to get rid of outliers:

In[]:=

Median[txSentTimeDiff]

Out[]=

1.03333

min

That’s about one transaction per minute.

A visual representation gives us an additional perspective:

ListPlottxSentTimeDiff,

Options



Out[]=

Again, let’s not draw conclusions from this information but open the discussion about whether this behavior reflects the actions of a program or a human.

The most shocking part of this story is the devilish value of the fee included in the transaction. An obvious question to follow should then be: is this sender usually such a good tipper?

By inspecting the fee of each transaction that the address sent, we find another interesting piece of information: the sender always used the same fee, except for the bizarre transaction:

In[]:=

Dataset[Function[u,<|"Fee"u〚1〛,"Number of Transactions"u〚2〛|>]/@Tally[Cases[Lookup[txData,{"Sender","Fee"}],{tx1Data["Sender"],fee_}fee]]]

Out[]=

Fee	Number of Transactions
1260000000000000 wei	56
10668731850000000000000 wei	1

That amount of wei equals about 43 cents using the current exchange rate:

In[]:=

CurrencyConvert[%[1,"Fee"],"USDollars"]

Out[]=

0.43

The reason for choosing this fee value is currently hidden knowledge. We can be sure, though, that the address acted consistently as a tipper during its entire history until the arguably flamboyant act of generosity that day in June.

Can we find out anything about the transaction receivers? The addresses themselves are meaningless hashes, but we can check if transactions were sent multiple times to the same destination:

In[]:=

Dataset[Function[u,<|"Address"u〚1〛,"Number of Transactions"u〚2〛|>]/@Cases[Tally[Cases[Lookup[txData,{"Sender","Receiver"}],{tx1Data["Sender"],receiver_}receiver]],{_,n_}/;n>1]][ReverseSortBy[Slot["Number of Transactions"]&]]

Out[]=

Address	Number of Transactions
21a38c1b625589510Fabd25886Ed11E8366dcaf3	3
Ff03702940DF00b6F43610292dbC977E1A1F1a33	2
B1328F5bD4bdd14b16d7624EE4baDeC09FEDBF01	2
a2135c21A148722836D8218ccabAAf8E774cf9e3	2
8aEEcd859d04176Fb457C2f20dd51d8476aEB9f2	2
7cb824431b4C139F38fe5a7329d9646bdF460F09	2
4E5c18a0248912172EAFDa3b453bbB53e0df150F	2
344016541693F6e885cEEEa7BC00b24e62E9060E	2
16aFE8FCc604B9d40717b66181278eD66C543b83	2

There is nothing particularly interesting about this selection. If we repeat the computation to find recurrent senders, we don’t satisfy any curiosity, either:

In[]:=

Dataset[Function[u,<|"Address"u〚1〛,"Number of Transactions"u〚2〛|>]/@Cases[Tally[Cases[Lookup[txData,{"Sender","Receiver"}],{sender_,tx1Data["Sender"]}sender]],{_,n_}/;n>1]][ReverseSortBy[Slot["Number of Transactions"]&]]

Out[]=

Address	Number of Transactions
1A175B1b753488492Ff9466919910a614C76af27	4
FfFeD7883a3E1C6d62bE309e337B050766eA5997	2
EB27879Bcd50A5D1462370F6105e6DC9AFf21944	2
e35DC176586E704De4089f1409988a2Cb943bc25	2
E08BBE40BE1aa93bf7f65A13eC0677CCD55bFC1B	2
D3E5CACD26A93Cc824Ae9Bf3e56A4E09553549cF	2
b17978F7AA415441349514Feb5f5553a5Bc3aa14	2
98799785C16361B43dc8981ccFe5D027281d6263	2
9517189be6B36327c1B18Ef355138e323DCa5DA3	2
8a7766cE7867979118904fb18Ab8F795792e6e35	2
83e7D3CD3D6c47a7315B3097bB9a21ab87Cd5a8f	2
74a408d179003cce89a6eeEc74Bb51b4bB9c1f53	2
72957670D66b6D147D7507c53a122eaD388A4e8a	2
4Ccf8826a6274A6D098c6D4dFF7ad378484436dF	2
4a0868FB993a7811bA77a63406ECCB137D325687	2
43c1e6A1729885d247fbD63D46851Fe5Bda58670	2
3DA08e97CD719cBaBF5AD6fAd65d151Ba0225468	2
31f8bFFc067380165071953652F3aB85ef7b8fBB	2
29e9D1Dfb6e43b132A1cd3E9A5399D46573eC4D4	2
13e115C997d29B43b0078A8692c3b1Eaf9A4Bd72	2
rows 1–20 of 22

With the hope that we can still find some kind of nicety, let’s compute the list of addresses that sent funds to the address under investigation and that also received ether from it:

In[]:=

Intersection[Cases[Lookup[txData,{"Timestamp","Sender","Receiver"}],{ts_,sender_,tx1Data["Sender"]}sender],Cases[Lookup[txData,{"Timestamp","Sender","Receiver"}],{ts_,tx1Data["Sender"],receiver_}receiver]]

Out[]=

{eB3B7ddCaA7f4431054df0BD58c31aCB3A68F6a9}

One single result is not useful data for us. We come to the sad conclusion that the senders and receivers are not part of this story for now.

Once Is Happenstance. Twice Is Coincidence? In Ian Fleming’s novel Goldfinger, Auric Goldfinger says, “Once is happenstance. Twice is coincidence. The third time, it’s enemy action.” Might this relate to what we’re looking at here?

A second transaction featuring the same enigmatic behavior happened some time later that day. In this case, it was the mining pool Ethermine adding the transaction to the blockchain. They also tweeted about it:

In[]:=

twitter["GetTweet","TweetID"1270927030817873920]//Dataset

Out[]=

ID	1270927030817873920
Text	Today our Ethermine ETH pool mined a transaction with a ~10.000 ETH fee (https://t.co/B5gRWOrcPf). We believe that this was an accident and in order to resolve this issue the tx sender should contact us at via DM or our support portal at https://t.co/JgwX4tGYr4 immediately! https://t.co/sWxVRx5muv
Date	Wed 10 Jun 2020 22:53:11
Username	etherchain_org
URL	https://twitter.com/etherchain_org/status/12709270...

In[]:=

Normal[%]["Text"]

Out[]=

Today our Ethermine ETH pool mined a transaction with a ~10.000 ETH fee (https://t.co/B5gRWOrcPf). We believe that this was an accident and in order to resolve this issue the tx sender should contact us at via DM or our support portal at https://t.co/JgwX4tGYr4 immediately! https://t.co/sWxVRx5muv

This is the information we have about the second transaction:

In[]:=

tx2="c215b9356db58ce05412439f49a842f8a3abe6c1792ff8f2c3ee425c3501023c";tx2Data=BlockchainTransactionData[tx2];tx2Data//Dataset

Out[]=

TransactionID

c215b9356db58ce05412439f49a842f8a3abe6c1792ff8f2c3ee425c3501023c

BlockHash

06698ca6eea2b9e6223e5bce41a142796d8845e4147a74356437054e3949fb06

BlockNumber

10241999

Confirmations

767797

Timestamp

Wed 10 Jun 2020 22:30:12

Status

True

TransactionIndex

Sender

cDd6a2b9DD3e386C8cd4a7ada5cab2F1c561182D

Receiver

E87FDA75feC7063c3D2BEf6Dc4f17c008b098C30

Amount

350000000000000000000

wei

GasUsed

21000

GasPrice

508034850000000000

wei

Fee

10668731850000000000000

wei

TransactionCount

1112

ByteCount

116

TransactionDigest

ByteArray

32 bytes



DigitalSignature

DigitalSignature

type: elliptic curve (secp256k1)

signature type: deterministic



SenderPublicKey

PublicKey

type: elliptic curve (secp256k1)

public key size: 512 bits



Note that the fee included in this transaction is the same as in the first transaction:

In[]:=

SameQ[tx2Data["Fee"],tx1Data["Fee"]]

Out[]=

True

Using the same scripts we used to extract data from the period before the first event, we now get transaction data from the time surrounding the second transaction.

This is also available in the Wolfram Cloud to save you the computing time:

In[]:=

txData2=CloudGet[CloudObject[

https://www.wolframcloud.com/obj/christian

p/Blog/CO/01-txData2

]]

Again, I'm making available the code I used for the script in case you want to run it yourself. Remember it may take many minutes, even hours, to get all the data:

In[]:=

txList2=Import[FileNameJoin[{NotebookDirectory[],"txListDataFull2.wl"}],"ExpressionList"];txListData2=Import[FileNameJoin[{NotebookDirectory[],"txDataFull2.wl"}],"ExpressionList"];

In[]:=

txData2=Function[u,Block[{txid=Lookup[u,"TransactionID"],txData},txData=<|MapThread[Rule,{{"Fee","GasUsed","ByteCount"},txid/.txListData2}]|>;Join[u,txData]]]/@txList2;

In this plot, we can see the number of transactions sent and received by the address over the five days surrounding the two bizarre occurrences:

In[]:=

txsSentTally2=Tally[Cases[Lookup[txData2,{"Timestamp","Sender"}],{ts_,tx2Data["Sender"]}ts]];txsReceivedTally2=Tally[Cases[Lookup[txData2,{"Timestamp","Receiver"}],{ts_,tx2Data["Sender"]}ts]];

In[]:=

DateListPlot

TXs sent

TXs received

,

Options



Out[]=

	Sent
	Received

We can repeat the same process we followed for the first transaction and see if multiple transactions were sent at the same time, i.e. included in the same block:

In[]:=

DateListPlotCases[txsSentTally2,{_,n_}/;n>1],

Options



Out[]=

Here we can clearly see there is one single case of three simultaneous transactions:

In[]:=

Cases[txsSentTally2,{_,n_}/;n>2]//Grid

Out[]=

Wed 10 Jun 2020 22:30:12GMT-5.

Curiously enough, the second extravagant transaction is part of this group:

In[]:=

MemberQ[Cases[Lookup[txData2,{"TransactionID","Timestamp","Sender"}],{txid_,tx2Data["Timestamp"],tx1Data["Sender"]}txid],tx2Data["TransactionID"]]

Out[]=

True

However, in contrast with the first event, this transaction is not the first one in the block. With a transaction index of 36, it is the second one in this group of three contiguous transactions:

In[]:=

DatasetBlockchainTransactionData

simultaneous txs

[SortBy[#TransactionIndex&]][All,{"TransactionID","TransactionIndex","Amount","Fee"}]

Out[]=

TransactionID	TransactionIndex	Amount	Fee
6fb95a72335fb1b3a6b72d3ceaeb2f24569f1ee44007dbcffb59b374d0dca2c6	35	647701418970000000 wei	1260000000000000 wei
c215b9356db58ce05412439f49a842f8a3abe6c1792ff8f2c3ee425c3501023c	36	350000000000000000000 wei	10668731850000000000000 wei
78654c9e78c004ff289efe4af95bcd35b7afa619b1ac66e9fae1778090ba6ced	37	723814180020000000 wei	1260000000000000 wei

These are the numbers of transactions received and sent during the period between the two events:

In[]:=

Dataset[<|"Transactions received"Length[Cases[Lookup[txData2,{"Timestamp","Receiver"}],{ts_,tx2Data["Sender"]}/;tx1Data["Timestamp"]<ts≤tx2Data["Timestamp"]]],"Transactions sent"Length[Cases[Lookup[txData2,{"Timestamp","Sender"}],{ts_,tx2Data["Sender"]}/;tx1Data["Timestamp"]<ts≤tx2Data["Timestamp"]]]|>]

Out[]=

Transactions received	273
Transactions sent	1057

When we compare the time before the first event and the period between the two transactions, we see a curious shift developing. After the first transaction was added to the blockchain, the number of sent transactions increased by more than one hundred times and the received transactions decreased to one-twentieth of the value examined before:

In[]:=

BarChart

TXs sent (2)

TXs received (2)

,

TXs sent (1)

TXs received (1)

,

Options



Out[]=

We should also note that the period we are considering from the time the sender appeared in the blockchain (block 10219082) until the first event spans 67.7 hours.

The time between the first and second events is 17.7 hours:

TimelinePlot

before first tx

between txs

,

Options



Out[]=

	Before the first transaction
	Between first and second transactions

This means that, in a shorter time interval after the first transaction, the sender’s activity (regarding transactions sent by the address) increased considerably.

The frequency at which transactions were sent also changed compared to the period before the first transaction:

In[]:=

txSentTimeDiff2=UnitConvert[Abs/@Subtract@@@Partition[Cases[txsSentTally2〚All,1〛,ts_/;tx1Data["Timestamp"]<ts≤tx2Data["Timestamp"]],2,1],"Hours"];

In[]:=

Out[]=

	Median	Mean
Before the first transaction	1.03333min	3.03152min
Between the first and second transaction	5.38014h	5.66981h

For reasons unknown to us, there was a noticeable change in the address’s behavior after the first event. What we do know is that the sender kept using the same fee amount for all transactions until the second transaction happened:

In[]:=

Dataset[Function[u,<|"Fee"u〚1〛,"Number of Transactions"u〚2〛|>]/@Tally[Cases[Lookup[txData2,{"Timestamp","Sender","Fee"}],{ts_,tx1Data["Sender"],fee_}/;tx1Data["Timestamp"]<ts≤tx2Data["Timestamp"]fee]]]

Out[]=

Fee	Number of Transactions
1260000000000000 wei	1056
10668731850000000000000 wei	1

What about the behavior after the second transaction? We can see in this plot that the number of transactions sent by the address kept increasing:

In[]:=

BarChart

TXs sent (3)

TXs received (3)

,

TXs sent (2)

TXs received (2)

,

TXs sent (1)

TXs received (1)

,

Options



Out[]=

This plot shows the time scale we are analyzing:

TimelinePlot

before first tx

between txs

after second tx

,

Options



Out[]=

	Before the first transaction
	Between first and second transactions
	After the second transaction

We can learn from this information that the behavior exhibited by the address after the first transaction kept its essence after the second event, i.e. it considerably increased the number of sent transactions while reducing the amount of transactions received.

Discussion and Growth To wrap this analysis up, let’s summarize the most relevant findings: We saw that the address responsible for both extravagant events appeared in the blockchain just a few days before the first transaction that happened on June 10. In the course of those days, the address received most of its balance during a high-activity period of eight hours on June 9 (and no transactions were sent that day). Then, some hours before the first weird occurrence on June 10, the address’s behavior started changing when transactions were sent at a rate of about one transaction per minute, while the number of received transactions fell to very low values compared with the previous day. This way of acting continued after the second high-fee transaction. Overall, though, the address received many more transactions than the ones it sent, but acted consistently by always using the same fee when sending transactions, except for the two unusual events.

We also know that both exotic transactions have some things in common: They used the same fee amount and were included in their corresponding blocks along with other transactions sent by the address under scrutiny. They also happened during a time when the address changed its behavior from a passive account that received a large number of transactions to an active address sending a large part of its funds.

While this kind of event adds to the controversy around mass adoption of cryptocurrency, this is a fast-evolving technology that still needs to go through our user experience to keep improving upon its design. There’s a computational side to it but also a human one, considering the philosophical ideas surrounding the history of blockchain tech.

Global events like the one we are currently experiencing may have a profound effect on these emerging technologies, and while we don’t know the future, changes will certainly happen and we need to understand them and build on their outturn.

In the end, we didn’t find a treasure like the character of the short story that inspired this blog post did. However, we did have a computational adventure navigating through blockchain data by analyzing a mysterious event and providing interesting findings that contributed to the discussion about these eerie happenings. The Wolfram technology stack was a key part of this endeavor. You can be part of this story too. The data and tools are there for you to use them. Keep exploring and stay curious.

Dive into Wolfram Blockchain Labs or get full access to the latest Wolfram Language functionality with a Mathematica 12.1 or Wolfram|One trial.

Cite this as: Christian Pasquel, "Investigating the Ethereum Gold-Bug and Blockchain in the Wolfram Language" from the Notebook Archive (2020), https://notebookarchive.org/2020-10-7f6kn8a