# This is a proposal to eliminate the need for OP_RETURN to relay

# First lets take an utxo that we own and try to send it to a stealth address.

# Info of utxo:

prev_hash = 'f3ebd0b3534518c23f439aac836ff207d6414b6530aecf1e0fff1d413774f994'
vout = '06' # The 7th output.
amount = 0.03170609 # in BTC

# The address I am using to send from in this example is 1FHxvwCfFz3B1VZSAQa71qWGyDbxdfamh4


# Normally, this is where we would generate an ephemeral pubkey.
# But instead, the sender, having entered the password for signature, reveals the private key
# to the above address.

privkey = Decrypt(encrypted_privkey) # lets assume privkey is in bigint format.

shared_secret = ECmultiply(privkey, scan_pubkey) # scan_pubkey of recipient
shared_secret_priv = sha256(shared_secret)
shared_secret_pub = ECmultiply(shared_secret_priv, SECP256k1_generator_point)

# We have in effect, used the senders key as the ephemeral key. Since the pubkey must be
# included in the ScriptSig, the recipient can know the shared secret without
# the tx looking obviously like a stealth transaction.

# Here is where I thought: Oh, but if I send more bitcoins from the same address to the
# same stealth address... the resulting send_to address will be the same! address reuse! OMG

# Now comes the solution. We take the hash of concatenated scan_pubkey, prev_hash, vout, and index
# index is only used in the case where the same input is used with the same stealth address in the
# same transaction. So if my input is fefe...fefe:3 and I have two outputs sending to Stealth Address Xyz...
# Then the first one uses '00' and the second uses '01' etc.
index = '00'


# This becomes the privkey for a 3rd point.


vout_priv = sha256((scan_pubkey + prev_hash + vout + index).decode('hex'))
vout_pub = ECmultiply(vout_priv, SECP256k1_generator_point)


# Now we have 3 points: spend_pubkey, shared_secret_pub, and vout_pub.
# Add all three together.

address_point = ECaddition(ECaddition(spend_pubkey, shared_secret_pub), vout_pub)
# As ECadd is communicative, order of addition doesnt matter

send_to_address = Base58CheckEncode(ripemd160(sha256(address_point)))

# create the output sending to the above address. Sending is finished.


# For the recipient:
# First, lets assume he knows what tx is to him from some outside source.
# (I will mention the search method later)

# He searches the ScriptSig of each input for any pubkeys, and tries them in order.
# (normal p2kh will have 1 pubkey per input)

# He notices the pubkey of the first input (which is prev_hash)

pubkey = '0309430d1bea1b90a59523f2892cd26084808394ce5cc7ea4b6ecbec0a63480c8c'

shared_secret = ECmultiply(scan_privkey, pubkey) # pubkey from ScriptSig x scan_privkey
shared_secret_priv = sha256(shared_secret)


# Then he looks at the vout index and prevhash used in the input.

vout_priv = sha256((scan_pubkey + prev_hash + vout + index).decode('hex'))


# Adds together the three privkeys to (hopefully) generate the address.

send_to_address_priv = (spend_privkey + shared_secret_priv + vout_priv) % N # Mod order of the curve.

# Generate the address and check all outputs in the transaction to see if it is there.
send_to_address_pub = ECmultiply(send_to_address_priv, SECP256k1_generator_point)
send_to_address_test = Base58CheckEncode(ripemd160(sha256(send_to_address_pub)))

assert send_to_address_test == send_to_address

# If the addresses are equal, then you now have the private key,
# and the only information necessary was the txid.



"""
Lets talk about performance:

If we look at the procedures for send and receive with the old OP_RETURN
method (I left out simple things like adding bigints and modding the order of the curve etc.)

Old send   : ECmult > sha256 > ECmult > ECadd > sha256 > ripemd160
ECmult x 2
ECadd x 1
sha256 x 2
ripemd160 x 1

Old receive: ECmult > sha256 > ECmult > sha256 > ripemd160
ECmult x 2
sha256 x 2
ripemd160 x 1


Looking at the New method I explained above and comparing:

New send   : ECmult > sha256 > ECmult > sha256 > ECmult > ECadd > ECadd > sha256 > ripemd160
ECmult x 3
ECadd x 2
sha256 x 3
ripemd160 x 1
Compare: Increase of 1 of each (ECmult, ECadd, sha256)

New receive: ECmult > sha256 > sha256 > ECmult > sha256 > ripemd160
ECmult x 2
sha256 x 3
ripemd160 x 1
Compare: Increase of 1 sha256

The heavy lifting is on the receiving end (as you must now iterate through every single ScriptSig
and compare against all output addresses.) but luckily the receiving calculations only increased by one sha256.

To narrow down the txes you need to search... I was wondering if the input that was used to generate the address
could change the sequence (the one that is normally 0xffffffff at the end of each input) to hash to the prefix...
or even match the sequence msb bits to the prefix bits etc.

Caveats:
1. Can't send to stealth from Trezor using this method. (as you need to multiply your private key with the scan_pubkey)
   Unless Trezor allowed for performing ECmultiplication on the device, and Trezor returns the shared secret.

2. When thinking about coinjoin and other aspects where multiple people spending to multiple stealth addresses, if we consider coinjoin, we must check every input of every transaction against our info... which is costly. Doing things to mark inputs as stealth info (maybe changing the sequence value) could be considered... but for 100% stealth and 100% no way to discern stealth from normal... there seems to be no other way than to check every input.

However: that being said... it eliminates the requirement for the OP_RETURN table on Obelisk servers... and it's not much more strenuous than running a full node. (having to scan every input of every transaction etc. when blocks come in) but it will be more strenuous for SPV servers, as upon every block they will have to send every transaction to each user... it will also be hard to do on mobile devices (drain battery)... obviously the wallet file would store the most recently checked block so that it doesn't check from the beginning every time...

Perhaps a mode where the wallet doesn't actively search, but users need to input the txid or something that they receive from the sender might be good for mobile...

I would like to hear any comments / questions.

- dabura667

"""