The Shayan – Reborn Let's make it fair this time Tue, 28 Mar 2017 23:31:25 +0000 en-US hourly 1 The Shayan – Reborn 32 32 58072221 Collar Options Smart Contract Fri, 07 Oct 2016 18:14:05 +0000 Read More]]> It’s been an exciting month for Velocity, after our Demo day at International Blockchain Week in Shanghai, we’ve been contacted by so many interesting people sharing Velocity vision.

Built using blockchain technology and Ethereum smart contracts, the platform aims to make derivatives trading more transparent, accessible and secure. The decentralized options platform provides support for users to enter into a collar option using a smart contract on the Ethereum blockchain, a move claimed by the company as making it the first platform that doesn’t rely on central servers or “middlemen” settlement processes to manage funds. siliconANGLE

We launched our Demo Options website which uses the underlying smart contract on Ethereum Morden testnet. The feedback we got from community helped us to envision better use cases for this technology. We’d be happy to hear more in our public slack channel.

The decentralized options platform allows users to enter into a collar option using a smart contract on the Ethereum blockchain, meaning it doesn’t rely on central servers or middlemen settlement processes to manage funds. Each party purchases a contract by sending a small amount of ETH to the contract’s Ethereum address. Once accepted by the network, the contract will fetch a starting price from the oracle’s price feed, and run for a period of five blocks. Velocity Offers Smart Contract Price Feeds

We’re happy to announce that the main collar option smart contract is now open source, you can read more and check out the source code in our Github repo.

Originally published at on October 7, 2016.

Introducing Pricegeth, Publishing Crypto Price Pairs Every Ethereum Block Thu, 01 Sep 2016 17:23:09 +0000 Read More]]> Introducing Pricegeth, Publishing Crypto Price Pairs Every Ethereum Block

Decentralized apps and smart contracts get executed on the Ethereum blockchain. Although accessible when an internet connection is available, Dapps by themselves cannot connect to internet directly and fetch information. This is a problem for the distributed ecosystem.

There are a few different approaches to solving this. One way is a callback method. This is where smart contract A would send a transaction to smart contract B, a data oracle, asking for some information.

The oracle smart contract would have a central server which is listening to the network for these transactions to fetch information. Then the oracle server would send a transaction to smart contract A with the results.

There are some downsides to this method. One being if the server is down or has bugs, there might not be immediate callbacks or it may just never happen.

Another issue is the gas cost of the callback function. If smart contract A needs to do some calculations and change a few variables, it requires enough gas from the callback transaction. This is how services such as works.

Another possible method is to publish the information to Ethereum blockchain which is accessible to other smart contracts. This is why we’ve created Pricegeth, which is now available on Github.

A few things to note about Pricegeth:

  • Pricegeth publishes price pairs (BTCUSD, BTCETH, BTCETC, BTCDOGE) at every ether block time
  • Using Pricegeth Library is free and easy to implement (check out example.sol)
  • This is a work in progress. The main contract address and function outputs might change in the near future.
  • Everything needed to get started is here:

Originally published at on September 1, 2016.

The return of OP_Return Tue, 15 Mar 2016 20:41:50 +0000 Read More]]> Bitcoin is a digital money, meaning it’s Digital, simple. It is based on 0s and 1s, as they say. A more efficient way of showing 0 and 1s is by using their hexadecimal representation a.k.a base 16.

For example this is a raw bitcoin transaction:


All historical data of all Bitcoin transactions ever happened are stored in a big database called “Blockchain”, and that is because these hexadecimal numbers are grouped together in batches, each called a “block” and chained to the previous data on the database with a cryptographic method to prove the order and sanity, a Blockchain.

What can we do with a raw transaction?

The above hex decodes to:

 “addresses”: “1BvAjjRGERmQvUBprkpPeZYZQNxCbLKe4P”, 
 “fees”: 2500, 
 “hash”: “7f2875779f2429ee76e50857c6407e56ecc5ba7b0c9cfb102a477e50072233fa”, 
 “inputs”: [
     “addresses”: [ “1BvAjjRGERmQvUBprkpPeZYZQNxCbLKe4P”], 
     “output_index”: 1, 
     “output_value”: 4454430, 
     “prev_hash”:    “8ed8ff9ff29ab4343798f6c360d2728c693ceeebdbb4575e1594d4666927da43”, 
      “script”: “483045022100d826eaff805130ec55a90cb5dd261e0f7ab02c918e0f2f1748c819c83ec94fcf0220561250a05bf5c6f7a0dd6d7eab1ae0414d5d5f194a9ddf94b3733a5409f921560121037d2542baf3a0ab1b00bffa5fbe045579f40f3572a0e0227b33a4bb13e7d85d06”, 
      “script_type”: “pay-to-pubkey-hash”, 
      “sequence”: 4294967295
 “lock_time”: 0, 
 “outputs”: [
 { <strong>“addresses”: [], 
   “data_hex”: “237375706572626974636f696e6572207375706572626974636f696e65722e636f6d”, 
   “data_string”: “#superbitcoiner”, 
   “script”: “</strong>6a22237375706572626974636f696e6572207375706572626974636f696e65722e636f6d<strong>”, 
   “script_type”: “null-data”, 
   “value”: 1</strong>
   {“addresses”: [“<strong>1BvAjjRGERmQvUBprkpPeZYZQNxCbLKe4P</strong>”], 
    “script”: “76a91477bf6e7ff62bdad5237ec8a1da91f52b1628186388ac”, 
    <strong>“script_type”: “pay-to-pubkey-hash”, </strong>
    “spent_by”: “407f5f46110256d0729cabe8a76168399342234df4001f1689b2166cdc5f02c7”, 
    “value”: 4451929
 “size”: 237, 
 “total”: 4451930, 
 “ver”: 1, 
 “vin_sz”: 1, 
 “vout_sz”: 2

which would end up being:

As you may have noticed, one of the outputs of this transaction is to a null-data script. what it means is that you get to write 80 bytes of null_data, and burn any amount of bitcoins sent to that script, in the above case 1 satoshi plus miner’s fee. That means 40 characters. This null_data, on the protocol level is known as OP_Return.

What can you do with this?

Recently, as the blocksize debate branch off to all other aspects of Bitcoin protocol, there are talks about limiting Bitcoin blockchain just for the payments (Bitcoin Classic) versus having settlements too (Bitcoin Core).

In short, we have one group (Bitcoin Classic) that thinks that bitcoin should always be a payment network, aimed at ultimately replacing traditional payment methods. Then we have another group that thinks of bitcoin as more of a settlement network (Bitcoin Core), and that end users should use sidechains, the Lightning network or other future initiatives that could appear in the future as networks for payment.

– CoinDesk

Who’s doing settlements? All of the following companies are using Bitcoin Blockchain as a settlement network, using OP_Return.

Bitproof, Coinspark, Colu, Docproof, Eternity Wall, Factom, Monegraph, Onename, Open AssetsStampery

% of Last Week’s Transations by Each Protocol
OP_Return Stats,

To see what else is going on the blockchain, I made it easier to communicate from deep in OP_return of a Bitcoin transaction to the outside world, twitter for example.

These are a few of the OP_Returns broadcasted recently, which are being stored on the blockchain forever:

Some other interesting related links:

OP_Return_ack is a real-time data source mirrored from Bitcoin blockchain (as soon as the the transaction confirms it’d be broadcasted on twitter).
Top Bitcoin Mobile Wallets Prove Block Confirmation Time is a Myth Thu, 25 Feb 2016 20:59:21 +0000 Read More]]> The block size debate might seem unimportant to people who don’t use bitcoin on a daily basis. However, the biggest challenge in bitcoin right now is dealing with confirmation time.

This is especially true during peak transaction periods. The problem starts when lots of transactions propagate the network. It is possible to use higher network fees on outgoing transactions for faster confirmation. However, this is not guaranteed.

There are not many mobile wallets letting users change transaction fees. In addition, automated fee estimation usually doesn’t work the way it should.

Bitcoin users often have to wait more than 15 minutes for a transaction to confirm. Sometimes, transactions can even take up to four hours. Limited block sizes can even lead to a fee market for transactions.

In theory, it is possible to automatically calculate an ideal miner fee. This would mean a transaction being confirmed in the first block. Even so, the time a subsequent block is generated still is a random variable. It simply cannot be controlled.

Here is an example of automated fee recommendation. By estimation, any transaction with a fee higher than 52,419 satoshis/KB would be included in the first block. Any transaction with fees lower than 25,000 satoshis/KB would need to wait at least two blocks to get confirmed.


This is why it is interesting to do an experiment testing existing mobile bitcoin wallets. The goal: To see how they calculate fees. Also, how these wallets compete for transactions included in the first block.

It should be noted during this test there were no bitcoin stress tests or transaction peaks occuring.

So, the average time of one confirmation is around 23 minutes. This is a long time.

There are 2.7 transactions broadcasted per second and 4,421 transactions in the mempool. This is quite low compared to the average number of transactions in mempool.


The result of this experiment indicates transaction fees could help transactions get confirmed faster.

Even so, the fact no blocks could be generated for more than 40 minutes still causes issues. When the someone is trying to sell bitcoin for cash, there needs to be at least one confirmation.

Also, none of these mobile wallets seem to choose mining fees efficiently depending on network state. They mostly rely on luck for fast confirmation.


The bitcoin network block difficulty ensures the average time of a block in every 2,016 blocks is 600 seconds. As seen in the above chart, when block generation time (the confirmation time) decreases fast, there is a higher leap in block difficulty.

Bitcoin adjusts difficulty every 2,016 blocks to keep up with the hashrate increase. The average block time is 10 minutes.

In a perfect world, where the blocks are not full and all transactions have enough fees, every transaction should be included in the first block. This average is 10 minutes.

As seen below, a median transaction confirmation with fees is around 8 minutes. However, it does not match our mobile wallet experiment.


The following is a visualization how long it took to generate a block after the previous one took 2,000 tries.

This is generated using block_time. It might not be exactly the same as block propagation time. Yet this explains negative time values. There are many blocks here requiring more than 30 minutes.


BitAccess has made a lot of improvements to handle transactions and make them more efficient. However, confirmation time is still a burden regarding how fast transactions can be processed.

We want to mitigate long transaction waits. In particular, we endeavor to make the transaction experience better. We are working on a solution.

Originally published at on February 22, 2016.

A cosmik way to go… Mon, 01 Feb 2016 01:59:21 +0000 Read More]]> Cosmik

[Here will be the detail for Cosmik game just submitted to the appstore] ]]> 2 247 Miner’s deal Fri, 13 Nov 2015 22:33:36 +0000 Read More]]>

I’ve been working full time on Bitcoin related products for the last 2 years and every day I’m more fascinated by things I figure out, however some of them are mostly speculation and not really facts for now.

My take on this graph

On November 12th, 2015 between 17:17 to 19:17 EST this spike happened deep in bitcoin network, The things I get from seeing these graphs are as follows (from bottom-up):

  • Looking at the % Transaction Inputs vs Outputs, it shows that the number of inputs in the transactions were way higher than the number of outputs. This also happens when there’s spam attacks going on to fill up the mempool. Or when there are lots of Bitcoin ,that was splitting into chunks before, are being gathered together again.
  • Looking at Bytes Per Transaction proves the above statement.
  • Looking at Transaction Fees (satoshis) Paid Per Kilobyte shows that on that period the transaction fees (a.k.a miner’s fee) were really low. So basically low fee transactions specially with too many inputs would be categorized as low priority and with the recent patches on Bitcoind, some nodes might actually reject these transactions and prevent them from propagation.
    • This is how transaction priority is calculated:
      priority = sum(input_value_in_base_units * input_age)/size_in_bytes
    • This could also be because there are too many P2SH (a.k.a multisig) transactions were happening, but because of the results from % Transaction Inputs vs Outputs, probability of this is low.
    • Or also lots of P2SH inputs on lots of transactions ?
  • Looking at Transactions Accepted vs Rejected  for that period shows that there were high ratio of accepted transactions. This usually means everything’s super great, however with the recent ongoing malleability attacks and spam attacks here or there, this is suspicious.
    • It could be that right at that time the attacker stopped his attacks and then started again. <- I doubt this one, just a guess
    • It could be that either it was a miner(s) doing the transactions and including them in their mined blocks or miner(s) are accepting someone else’s low priority transactions in return for maybe a fee.


Ok let’s see if we can find something:

blocks on that time

Some almost full blocks on that time

There are some almost full blocks on that time period, but it’s not anything weird these days.

Let’s go deeper in block 383283 (mined by Unknown).

While just going through the transactions, I saw some pattern like transactions such as 16~25 inputs and 20~21 outputs (e.g,  abdc70074bbcf4c32bff29b0e5d6beebc062e6fabbac837fa489fa088aa7ebe9)

and with the help of blockseer, I saw that there’s definitely a pattern going on there.

blockseer 21

Not sure if it’s related or not, after traversing up this weird intertwined tree, I got one address labeled as NUCLEUS MARKET.

Starting to feel like John Nash

Starting to see patterns everywhere…

let’s continue in the blocks. yup more and more of these transactions and most of them with high amounts of Bitcoin. Some examples:




Most of them have 21 outputs, some 20. These transactions most probably are a generated by a tumblr, bitcoin laundering service or maybe just some automated scripts.

Some examples of their transaction size vs transaction fee:

40000 / 2.9 Kb (2941 Byte) = 13333 satoshi/Kb

50000 / 3.5 Kb (3528 Byte) = 14285 Satoshi/Kb

So these are exactly the transactions that made the dump in Transaction Fees (satoshis) Paid per Kilobyte graph.

Now on Block 383284 (Mined by Antpool)

There is not even one transaction which follow the 21-output transaction characteristics (yeah I went through 2632 transactions manually to be sure!)

There are some huge P2SH transactions though:  3e3d5817092b91c88cab80fb9e142a0ef46728090414c088c1f610d0d4792480 7709609eb5ea042cc4e60e260a11e51bfb8c5f1fda037a94155634ad90400325

and also 87 inputs to 2 outputs:  639deafdcb68bd314765fa4580cad83b397eb7d30c3cb033ce74b0874afd3f19

and a lot more big transactions that is coming from BTCChina (don’t ask how I know, I just figured that out and I’m pretty sure.) AntPool and BTCChina, Eh? probably a deal to include their transactions.

Block 383285 (Mined be AntPool)

My guess is that there would be no 21-output like transactions. let’s see…

found one!  54dfa0a554dc1b43d8a38b2f0ac272feb20da5ad7ecf42216fa01138d104008f

and another one:  40162707f99cc0f1dc4f35c9dc372a9df5c7bc0677ec68acc708bac8434fde68

one more, my guess was totally wrong:  96219ae83845e43e87778e22e58f21d84e9385a023abe2500dc921ee7e843829

Another huge 28-inputs, 3-outputs P2SH transactions:  83a3b1b5f9433dad608a3cde601bf43cea8985cc229982c5f80fc0126adf053f

By experience I’d say this P2SH transaction was generated by BitGo, and probably is for an exchange that is using them as their Multisig HD wallet.

Here is a localbitcoins transaction in that block:  21635217b344560004b96f79e5c2939fefb114c69132cf21a3b2840432402158

There seems to be not that many of 21-output like transactions, I’m gonna stop checking this block and go to next ones, cause it seems like AntPool has its own partners. but this would make my initial assumptions weaker I guess.

Block 383286 (Mined be BitFury)

12~13-inputs 501-outputs FAUCETBOX.COM transactions:  5a43e3fd6b4e9c16df9a80891961101c6b9e2f230ce1da5b323faf5f81e60fc7 e1a2ca799d27409e88256aee65c072ae4deaa24a84a96303611cd4391b85d79d

There are a lot more of these faucetbox transactions, mostly have 500+ outputs, and apparently Faucetbox and bitfury have a deal, just by checking the fees that are really low.

83519 / 18.7 = 4466 Satoshi/Kb

80580 / 17.9 = 4501 Satoshi/Kb

Note: by Bitcoinfees estimation, if transaction has 5000 Satoshi/Kb it would take more than 60 minutes to confirm.

21-output transactions yeeey:


nope I guess that was all. whoever is behind 21-output like transactions is, has a deal with the miner that was named Unknown. So I guess I ended up empty handed on that subject.

Some huge transactions (500+inputs) with medium to low fees, that are most probably in contract with Bitfury to get confirmed, not sure about the identity though:

20e24e1cd0feb4bbc926fbc500cc1465674d015d69eb100d8922a80e0a6746f4 6198d7a0ec113ab5a83a8fc2a2fc9024b7d26c4cd34df4fa2e84b4fc6eba63b1

So My plan when I started writing this post was to figure out why that jump happened on the graphs, but somehow ended up just figuring out some random stuff about each block and miner/”company” relationship.

I haven’t slept in the last 48 hours, so feel free to call out my bullshit anywhere here.

would be happy to discuss any of the assumptions and hear yours.




Blockchain Analytics will be the new black Mon, 09 Nov 2015 06:33:16 +0000 Read More]]> Once upon a time I deposited some bitcoin in a darknet market …

I start following the coins in the blockchain…

Blockchain is this public ledger of all the transactions ever happened on Bitcoin network until right now.
Dakrnet Market is a marketplace that is only accessible through TOR network.

Almost all the markets have their own internal bitcoin wallet management that you have to deposit bitcoin to your account deposit address in order to have a positive balance to spend.

Thanks to for their great service.

following up the first attempt, I tried other available services for the same deposit address to see how important the visualization is.


At first I tried Jarvis by , I used to like their way of visualizing transactions, but for some reason their API seemed to be broken.

Actually the error on screen was:

Transaction-API-400: If ‘logicalOperator’ is null then all three fields, ‘field’, ‘comparisonOperator’ and ‘fieldValue’ must be present.

UPDATE: Apparently I was using older version of Jarvis UI that was using wrong API calls, and their API is working fine. Thanks to coinalytics for the fast response.

Then I tried numisight Blockchain explorer, that by my knowledge, was one of the first blockchain analysis tools. It used to be really fast, however apparently due to changes in underlying APIs and the closed-source nature of the project it has not been updated yet.

I found out that numisight is good if you want to find out if two addresses have a common transactions by crawling the transactions, however might not be the best option to get informations regarding the infrastructure broadcasting those transactions.



Disclaimer: These posts are just to share my experiences with anyone interested in this field. Even the songs on the background are the songs playing on Spotify while I’m working. There might not be any points achieved in the end.

BIP210 Proposal (DOA) Thu, 01 Oct 2015 03:30:13 +0000 Read More]]> Considering current P2SH (multisiginature) implementation in bitcoin-core [] ,for any set of 3 public keys we have six possible 2 out of 3 multisig addresses. The order of the keys in the set has direct effect on address generation and even signing one multisignature transaction.

let me show you what I mean:

let’s say we have these 3 addresses to begin with:

Address 0: 12irNBGCHnwjd8DN8YBJxvGv7kwYNv9q6B

Public Key: 03ea446154132cb6828711cee60ce99713130bba9d0e1c504086997b76b9e81995


Address 1: 1HjRTzGLofwaUk1YaZZJFuJLBxTr6PqQir

Public Key: 0312db381f3138882a0b313032659e27d8d4d8ea154c467532b815804b26b0b1df


Address 2: 1KmmW1wRBM65DNztaVczqFsz3qWhkKmPid

Public Key: 0382bd8f573c6e452084ed0cb1f61f6495eb48c1eb5f7c067cc933a229ed9d5982

All the possible orders:


keys[0], keys[1], keys[2] keys[0], keys[2], keys[1] keys[1], keys[0], keys[2] keys[2], keys[0], keys[1] keys[1], keys[2], keys[0] keys[2], keys[1], keys[0]


Or to be more exact all the possible 2 out of 3 multisig combinations:

0 <0232ad80a4683e51117cf14340f3fa6a96cd8909603038f8384403b380ae552a29>

1 <030e8e0d4c5d5442bd4daa598f8e36d7c3f230274deb6d014f633e5951597d1d4e>

2 <02f46cd541b8d3262b9f426dd04bde5c47e2a661ce20e0d2c1a203b268898637a8>

Multisig address: 38H6Ug5FQLkidbYnFsDybtZhbciQBMWKWM


0 <0232ad80a4683e51117cf14340f3fa6a96cd8909603038f8384403b380ae552a29>

2 <02f46cd541b8d3262b9f426dd04bde5c47e2a661ce20e0d2c1a203b268898637a8>

1 <030e8e0d4c5d5442bd4daa598f8e36d7c3f230274deb6d014f633e5951597d1d4e>

Multisig address: 3QYJynJXkdbW5AwHqhaLmuw4dxKqXWQHG2


1 <030e8e0d4c5d5442bd4daa598f8e36d7c3f230274deb6d014f633e5951597d1d4e>

0 <0232ad80a4683e51117cf14340f3fa6a96cd8909603038f8384403b380ae552a29>

2 <02f46cd541b8d3262b9f426dd04bde5c47e2a661ce20e0d2c1a203b268898637a8>

Multisig address: 3JbuTp76yX4XtxEhD3hee85P4eENvzSGop


2 <02f46cd541b8d3262b9f426dd04bde5c47e2a661ce20e0d2c1a203b268898637a8>

0 <0232ad80a4683e51117cf14340f3fa6a96cd8909603038f8384403b380ae552a29>

1 <030e8e0d4c5d5442bd4daa598f8e36d7c3f230274deb6d014f633e5951597d1d4e>

Multisig address: 333uo1hVEaju9Wz5xRDmfqQdcX1p9J3SSB


1 <030e8e0d4c5d5442bd4daa598f8e36d7c3f230274deb6d014f633e5951597d1d4e>

2 <02f46cd541b8d3262b9f426dd04bde5c47e2a661ce20e0d2c1a203b268898637a8>

0 <0232ad80a4683e51117cf14340f3fa6a96cd8909603038f8384403b380ae552a29>

Multisig address: 3P4UQoM6qkAdiWURRowa3fTTYdPM1i1dXw


2 <02f46cd541b8d3262b9f426dd04bde5c47e2a661ce20e0d2c1a203b268898637a8>

1 <030e8e0d4c5d5442bd4daa598f8e36d7c3f230274deb6d014f633e5951597d1d4e>

0 <0232ad80a4683e51117cf14340f3fa6a96cd8909603038f8384403b380ae552a29>

Multisig address: 3Q6owwdB7ckuF99R8DX4xPbjvZVttiHQzC

So we end up having:

All the possible 2 out of 3 multisig addresses: 

  1. 38H6Ug5FQLkidbYnFsDybtZhbciQBMWKWM
  2. 3QYJynJXkdbW5AwHqhaLmuw4dxKqXWQHG2
  3. 3JbuTp76yX4XtxEhD3hee85P4eENvzSGop
  4. 333uo1hVEaju9Wz5xRDmfqQdcX1p9J3SSB
  5. 3P4UQoM6qkAdiWURRowa3fTTYdPM1i1dXw
  6. 3Q6owwdB7ckuF99R8DX4xPbjvZVttiHQzC

As a software developer perspective this is madness, as a hacker bitcoiner kind of view, this is how everything should be in the first place, no limits on choices, per say.

But we need a standard in the software library level, at least to make sure a set of 3 keys would generate the sam emultisignature address on one application that was generated on the other.

BIP201 proposal:

 Lexicographically sort of pubkeys in multisig

(address generation and signing)

I’m glad I didn’t start writing the BIP proposal first and had to implement a multisig mult-device wallet. That’s when I realized It’s not such a great idea to sort addresses by default, because it would introduce some logical issues to multisig applications.

Let’s say we have the combination of (keys[2] ,keys[1] ,keys[0]), and here would be one of the multisignature wallet implementations that seems practical:

  1. Client makes the unsigned transaction
  2. Client signs the transaction using keys[0] and sends the partially signed transaction to the server
  3. Server receives the transaction
    1. checks the statements (multisig security stuff, while list/blacklist addresses or other implementation of multisig ideas)
    2. signs using keys[1] and broadcast to the network

So let’s say the server goes down and now it’s time to use your backup key to save your funds from the multisignature address. So let’s implement it this way as a practical -first way that comes in mind- implementation :

  1. Client makes the unsigned transaction
  2. Client signs the transaction using keys[0]
  3. Using the Back up signing tools Client signs the partially signed transaction using keys[2]
  4. Client broadcasts the transaction to the network

So the signed transaction ends up being invalid and client fails to broadcast it to bitcoin network.

Here is why []:

Warning icon OP_CHECKMULTISIG warning: The multisig verification process described above requires that signatures in the signature script be provided in the same order as their corresponding public keys in the pubkey script or redeem script. For example, the following combined signature and pubkey script will produce the stack and comparisons shown:

OP_0 <A sig><B sig> OP_2 <A pubkey> <B pubkey> <C pubkey> OP_3

Sig Stack       Pubkey Stack  (Actually a single stack)

———       ————

B sig           C pubkey

A sig           B pubkey

OP_0          A pubkey

1. B sig compared to C pubkey (no match)

2. B sig compared to B pubkey (match #1)

3. A sig compared to A pubkey (match #2)

Success: two matches found


But reversing the order of the signatures with everything else the same will fail, as shown below:

OP_0 <B sig> <A sig> OP_2 <A pubkey> <B pubkey> <C pubkey> OP_3

Sig Stack          Pubkey Stack  (Actually a single stack)

———            ————

A sig           C pubkey

B sig           B pubkey

OP_0          A pubkey

1. A sig compared to C pubkey (no match)

2. A sig compared to B pubkey (no match)

Failure, aborted: two signature matches required but none found so far, and there’s only one pubkey remaining


It’s not a big deal at all, it just means if you design your wallet system based on the described system above, the production wallet would fail to use the backup key to sign a transaction on some of the multisig addresses (with the one-third probability of happening)  and would need a redesigned client application to use the backup key first, that might end up changing the the designed concept of importing/signing with backup key on the application.


A quick look at Helix by Grams Thu, 25 Jun 2015 01:49:39 +0000 Read More]]> I read about Helix by Grams a week ago as the new best Bitcoin cleaner so I thought to give it a look. They call them selves as the best because it’s not just coin mixing service, but you would get clean bitcoins for your dirty ones, comparing to other coinmixing services that you would get some other dirty bitcoins for your not-so-dirty coins.

The first thing that got my attention was the neat design of the site and the service that is far modern and better than any other darknet sites I’ve even seen, it does not feel like you’re in darknet at all.

Screen Shot 2015-06-24 at 8.26.02 PM


Grams offer different services such as :

  • Helix Bitcoin cleaner with PGP 2FA and …
  • Helix Light Bitcoin cleaner without any registeration
  • Flow a redirect service for .onion sites (e.g. Helix site would be:
  • BitBall Darknet Lotto
  • TorAds Kinda like Google Ads but for darknet
  • InfoDesk Search Dark Market vendors

For now I’ll focus on Helix and Helix Light and see how they work.

 Helix by Grams

I’m really interested to know who’s behind this site, as the design perspective, they have cool designs and google like login page and search bars.

Helix login

In order to register, you need to have PGP encryption key and you will use your public key in the registration. This would be used as a mandatory two-factor Authentication every time you want to log in to the site.

Every login page would have a encrypted login token that you need to decrypt to be able to log in to your account:

Helix 2FA

This would decrypt as:

Login Token: b2b03fb35402ff0d416a5f448a99300c3be8779acb7306cf68a55bedbf1471e0f44b833aacb4a231f84ac3699ca6f764fc7be6efcdc02b0c956e26

They have some interesting Terms and Services:

Terms of Service


Account information
Grams will encrypt all passwords on the server so if the server gets compromised our user’s data will be secure.


Grams will encrypt all message with the recipient’s pgp key and store them on the server this way. The only message that will not be store using encryption are the messages from our system.

No spamming! if a users sends out messages to our users advertising products and/or sites that user will be banned.


Reviews are here to help the community and to stop scamming on the darkweb. If a user post fake reviews or derogatory reviews they will be warned. If it continues they will be banned.

Grams Words

All listings on Grams words or any other advertising features of grams must be approved before going live. If you change the content of the page the ad links to after it is approved or try posting listing to scam sites or scam vendors you will be banned and will not receive a refund for your advertisement.

Child Porn

As a community the darknet has decided child pornagraphy will not be tolerated. Any users posting or listing anything do with child pornagraphy will be banned immediatly! No exceptions.


Grams has spent a great deal of time trying to secure our server to keep all users data secure. No bitcoins or any information that could not be gathered simply by going to the market or sites is on the server. So please dont waste our time and yours by trying to hack the server. If we even suspect you are trying sql inject, manipulate the bitcoin balance, or any other form of hacking we will ban the user.


Grams reserves the right to ban any user for any reason. A user who gets banned will not be given a refund for any bitcoins they had in their grams account. You can dispute your ban with the administrator by email.

You need at least 0.01 BTC in your account to have an activated account, this could be used later on as your credit on the site.

I won’t go too much into these details as the purpose of this blog post is to see how they work underneath and on Blockchain level.

So after logging in and going to Bitcoin page, you will have a bitcoin address for 10 hours (resettable timer) that you can use to deposit bitcoins in, and then either activate Auto-Helix to withdraw the bitcoins to an specific address or manually request it.

Bitcoin Helix


And then it might take up to 8 hours for your coins (minus fees) to get deposited into your withdrawal address.

Helix Withdraw

It took mine around 4 hours to be complete and I received an encrypted auto-delete message saying that the transactions has been done.

Your Helix transaction has been completed.
0.02439024 BTC has been sent to 126upXXXXXXXXXXXXXXXXXXXXXXXDQ
Below is a list of the transaction hashes. Copy them for you records. This message has already been deleted out of the system for security.

Transaction hashes:

Have a good day.

So let’s dig deeper and see if we can figure out what happened there.

Here is my deposit address (generated be Helix) : 1LL2F7tXua3LJ9wgFfcZchpT31eSxLDJW6

Here is my withdrawal address ( 126up7M1PUebBk9g9mNXvTJRFgyRr75yDQ

as you can see on my withdrawal address I received 5 distinct transactions summing up to 0.02439024 BTC.

blockchain info

Now let’s follow each transaction and see if we can find any connection between those.

In the following picture (made by numisight), those two block squares are my deposit transactions. as you can see there’s not that much pattern going on in the transactions, either on the number of inputs/outputs nor the bitcoin value of each transaction.

BitIodine clusters the deposit address with 1999 other addresses that might be useful for future investigations.



Now let’s try where the “clean” bitcoins are coming from.

It’s interesting to see one connection when I traversed up the clean coins for a few transactions.


(Blue boxes are the inputs, Green boxes are the “clean” bitcoins I received)

let’s go crazy and open up as many transaction as possible.

(Blue boxes are the inputs, Green boxes are the "clean" bitcoins I received)

(Blue boxes are the inputs, Green boxes are the “clean” bitcoins I received)

It didn’t need that much craziness to get connected. now you can see there is a really complex connection between the inputs and the outputs. However this does not prove anything in specific, if you follow two distinct normal busy bitcoin addresses, it’s likely possible that they have some input transactions in common if you go deep enough, that just means there was a common address (same or not the same owner) in the transaction chain.

This is the first post of a series of posts!

]]> 2 195
Feel The Ball – Bitcoin Tipping Game Sun, 01 Feb 2015 18:33:09 +0000 Read More]]> [Post to be updated soon] never got the chance to write this blog, and it’s already too late for it. hopefully will write a better one for version 2.

This is the support post for the game release version 1.5


UPDATE (Oct 2015): This game paid over 100 rewards.

Feel the ball - rewards

]]> 11 191