# 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 and vout
# This becomes the privkey for a 3rd point.


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


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

address_point = ECaddition(ECaddition(scan_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).decode('hex'))

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

send_to_address_pub = ECmultiply(send_to_address_priv, SECP256k1_generator_point)

send_to_address_test = Base58CheckEncode(ripemd160(sha256(address_point)))

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 calculcations 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.



I would like to hear any comments / questions.

- dabura667

"""