MinAddress : Now remember your addresses easily

BurtW

Legendary

Offline

Activity: 2646
Merit: 1130

All paid signature campaigns should be banned.

Re: MinAddress : Now remember your addresses easily

September 16, 2014, 04:06:31 PM

#121

This has become one of my favorite theads. So nice and peaceful. I am sorry that we have gone somewhat off the main topic of the MinAddress proposal and web site but on the bright side we are keeping this MinAddress thread active and well bumped.

Our family was terrorized by Homeland Security. Read all about it here: http://www.jmwagner.com/ and http://www.burtw.com/ Any donations to help us recover from the $300,000 in legal fees and forced donations to the Federal Asset Forfeiture slush fund are greatly appreciated!

CIYAM

Legendary

Offline

Activity: 1890
Merit: 1075

Ian Knowles - CIYAM Lead Developer

Re: MinAddress : Now remember your addresses easily

September 16, 2014, 04:06:49 PM

#122

Quote from: BurtW on September 16, 2014, 04:00:27 PM

BTW Peter is one of my favorite people in the whole world. Not only for his work on stealth addresses but because of this post:

https://bitcointalk.org/index.php?topic=563925.0

Agreed - I do like his idea a lot.

With CIYAM anyone can create 100% generated C++ web applications in literally minutes.

GPG Public Key | 1ciyam3htJit1feGa26p2wQ4aw6KFTejU

jl2012

Legendary

Offline

Activity: 1792
Merit: 1092

Re: MinAddress : Now remember your addresses easily

September 16, 2014, 05:25:27 PM

#123

Quote from: BurtW on September 15, 2014, 07:56:51 PM

Quote from: tspacepilot on September 15, 2014, 06:05:50 PM

... in order to adhere to an abstract principle that not everyone agrees with or thinks about.

Where the abstract principle you are talking about is address reuse. I don't consider this an "abstract" issue.

Address reuse is the single largest internal threat to the long term viability of Bitcoin. It is the single largest threat that we can do something about within the Bitcoin community. Address reuse should be discouraged by any and all means possible. Companies, individuals, charities, etc. who continue to reuse addresses should be boycotted until they change their ways. Deterministic key pair generation should be used for all periodic payments, all donation addresses, all mining pool payouts, and all other times when multiple payments are made from one entity to another entity.

Ideally all addresses would be used only once and contain only two transactions: a single funding transaction followed by an eventual single spending transaction. All change should go to a fresh address every time.

I wish the protocol enforced these rules. If it were possible to make this change it is the only change to the protocol I personally would support at this time.

Do you know the implication of your wish? That means miners and full nodes have to keep ALL transaction record FOREVER because they have to make sure the addresses in a new block have never been used before.

Donation address: 374iXxS4BuqFHsEwwxUuH3nvJ69Y7Hqur3 (Bitcoin ONLY)
LRDGENPLYrcTRssGoZrsCT1hngaH3BVkM4 (LTC)
PGP: D3CC 1772 8600 5BB8 FF67 3294 C524 2A1A B393 6517

tspacepilot

Legendary

Offline

Activity: 1456
Merit: 1076

I may write code in exchange for bitcoins.

Re: MinAddress : Now remember your addresses easily

September 16, 2014, 05:57:20 PM

#124

Thanks so much for the informative discussion. I now have a general understanding of the argument which connects address reuse to fungibility. The steps are that (1) address reuse weakens privacy, (2) weakened privacy can lead to a fractured network because miners and users may decide not to interact with certain addresses. I'm (still) not convinced, but I appreciate the discussion. I'm going to check out the threads that BurtW linked us to.

Commenting here on the argument as I understand it, it seems there are some weaknesses on (1) and (2). On (1), can't I reuse an address many many times in an anonymous fashion? That is, it may be that address reuse might aid a private detective in figuring out the personal details of a particular user, but it also might be that it doesn't help at all or that the private detective fails to identify the user despite their address resuse. Say a particulare mining node connected through TOR keeps sending mined bitcoins to an address 1bitcoinanon... What do we know about 1bitcoinanon....beyond the fact that presumably this is the same person reusing an address? In fact, it could be a group of people sharing an address (maybe they sent the address and private key to each other via ssl email). Can't you imagine all sorts of such scenarios?

On (2), I want to present the opposite sort of rebutal than I did for (1). That is, can't users start to whitelist/blacklist each other without knowing personal details?

To summarize, I understand the argument as this linear chain:

address resuse helps people discover each others details-->people who know each others details can dispute personaly-->personal disputes can lead to a fractured/less fungible bitcoin network

But for me:

+ I question whether address resuse necessarily leads to discovery of details and
+ I suggest that people may dispute without knowing personal details.

Cheers!

ffe

Sr. Member

Offline

Activity: 308
Merit: 250

Re: MinAddress : Now remember your addresses easily

September 16, 2014, 09:21:39 PM

#125

Quote from: jl2012 on September 16, 2014, 05:25:27 PM

Quote from: BurtW on September 15, 2014, 07:56:51 PM

Quote from: tspacepilot on September 15, 2014, 06:05:50 PM

... in order to adhere to an abstract principle that not everyone agrees with or thinks about.

Where the abstract principle you are talking about is address reuse. I don't consider this an "abstract" issue.

Address reuse is the single largest internal threat to the long term viability of Bitcoin. It is the single largest threat that we can do something about within the Bitcoin community. Address reuse should be discouraged by any and all means possible. Companies, individuals, charities, etc. who continue to reuse addresses should be boycotted until they change their ways. Deterministic key pair generation should be used for all periodic payments, all donation addresses, all mining pool payouts, and all other times when multiple payments are made from one entity to another entity.

Ideally all addresses would be used only once and contain only two transactions: a single funding transaction followed by an eventual single spending transaction. All change should go to a fresh address every time.

I wish the protocol enforced these rules. If it were possible to make this change it is the only change to the protocol I personally would support at this time.

Do you know the implication of your wish? That means miners and full nodes have to keep ALL transaction record FOREVER because they have to make sure the addresses in a new block have never been used before.

A protocol CAN be created to enforce no re-use. It just requires some extra work by the sender and receiver. I haven’t thought it through but it would be based on creating a new public key from another one similar to the way that HD wallets (BIP32) allow the SAFE derivation of child public keys from parent public keys.

Let’s see:
1.   The sender looks up the address he wants to send to. If it is unspent, he sends to it.
2.   If it is spent (and remember we only spend ONCE. The full amount...)
   he can derive the public key from the spending transaction, call it Y.
3.   He creates a new shared secret (Diffie Hellman) between his key and Y.
4.   He uses the shared secret and Y to generate a new public key, Y’, for the recipient and calculates an address from it.
5.   He sends to that new address.

The recipient can check every transaction to see whether it is his:
1.   He knows the sender’s public key (it was a spending transaction for the sender).
2.   He calculates the shared secret. This allows him to recreate BOTH his new public key and his new private key.
3.   He can spend the coins at a later time.

In all of this, what’s important is that ONLY the sender and receiver know the shared secret. Also the shared secret is unique to each transaction by the assumption of only one spend, hence only one use of the transmitter’s public key.

This is all a lot of work and probably could be made more efficient.

Finally, if you don’t want people sending more than once to your address, publish a RECEIVING public key that remains constant long term. It is never sent-to but is used in generating all the shared secrets the senders will need.

jl2012

Legendary

Offline

Activity: 1792
Merit: 1092

Re: MinAddress : Now remember your addresses easily

September 17, 2014, 02:30:05 AM

#126

Quote from: ffe on September 16, 2014, 09:21:39 PM

Quote from: jl2012 on September 16, 2014, 05:25:27 PM

Quote from: BurtW on September 15, 2014, 07:56:51 PM

Quote from: tspacepilot on September 15, 2014, 06:05:50 PM

... in order to adhere to an abstract principle that not everyone agrees with or thinks about.

Where the abstract principle you are talking about is address reuse. I don't consider this an "abstract" issue.

Address reuse is the single largest internal threat to the long term viability of Bitcoin. It is the single largest threat that we can do something about within the Bitcoin community. Address reuse should be discouraged by any and all means possible. Companies, individuals, charities, etc. who continue to reuse addresses should be boycotted until they change their ways. Deterministic key pair generation should be used for all periodic payments, all donation addresses, all mining pool payouts, and all other times when multiple payments are made from one entity to another entity.

Ideally all addresses would be used only once and contain only two transactions: a single funding transaction followed by an eventual single spending transaction. All change should go to a fresh address every time.

I wish the protocol enforced these rules. If it were possible to make this change it is the only change to the protocol I personally would support at this time.

Do you know the implication of your wish? That means miners and full nodes have to keep ALL transaction record FOREVER because they have to make sure the addresses in a new block have never been used before.

A protocol CAN be created to enforce no re-use. It just requires some extra work by the sender and receiver. I haven’t thought it through but it would be based on creating a new public key from another one similar to the way that HD wallets (BIP32) allow the SAFE derivation of child public keys from parent public keys.

Let’s see:
1. The sender looks up the address he wants to send to. If it is unspent, he sends to it.
2. If it is spent (and remember we only spend ONCE. The full amount...)
he can derive the public key from the spending transaction, call it Y.
3. He creates a new shared secret (Diffie Hellman) between his key and Y.
4. He uses the shared secret and Y to generate a new public key, Y’, for the recipient and calculates an address from it.
5. He sends to that new address.

The recipient can check every transaction to see whether it is his:
1. He knows the sender’s public key (it was a spending transaction for the sender).
2. He calculates the shared secret. This allows him to recreate BOTH his new public key and his new private key.
3. He can spend the coins at a later time.

In all of this, what’s important is that ONLY the sender and receiver know the shared secret. Also the shared secret is unique to each transaction by the assumption of only one spend, hence only one use of the transmitter’s public key.

This is all a lot of work and probably could be made more efficient.

Finally, if you don’t want people sending more than once to your address, publish a RECEIVING public key that remains constant long term. It is never sent-to but is used in generating all the shared secrets the senders will need.

I am not sure what you mean by "enforce". If you mean "transactions with address re-use are invalid", I have already explained why it won't work.

What you describe is essentially "stealth address". It facilitates no re-use but not enforces it.

Donation address: 374iXxS4BuqFHsEwwxUuH3nvJ69Y7Hqur3 (Bitcoin ONLY)
LRDGENPLYrcTRssGoZrsCT1hngaH3BVkM4 (LTC)
PGP: D3CC 1772 8600 5BB8 FF67 3294 C524 2A1A B393 6517

deepceleron

Legendary

Offline

Activity: 1512
Merit: 1025

Re: MinAddress : Now remember your addresses easily

October 11, 2014, 09:29:39 AM
Last edit: December 04, 2017, 10:28:14 PM by deepceleron

#127

As long as we are pondering useless stuff..

Quote from: ak111in on September 08, 2014, 02:01:27 PM

Full address to Min-Address Conversion:
#Take the full address and find the block in which the first transaction to address occurs.The block number is the converted to hex-code and forms the first part of Min-Address.
#Get all the receiving addresses in the block and do a case insensitive comparison to find the minimum number of initial characters which uniquely identify the address, this forms the second part of the Min-Address.

It occurs to me that this could be more compact.

Let's take a random recently-seen address:

This is your min-address format:
4f4d6-1pi9

Instead of block number + firstbits of a block, we can get all the information from the structure of transactions in the blockchain, and then encode it smartly.

We can find the first occurrence of a payment to an address, and then refer to it by block_number->transaction_number->txout_number

We can call this micro-address. It can be the base58 encode of a bitstream-type encoding of the above data:

Most-significant-bit placeholder
1st bit set to 1

block number:

bit 0 - len of block count:
0 - 23 bits
1 - 31 bits

bit 1-24 or bit 1-32:
23 bit length: (blocks 0-7fffff) (blocks 0-524287)
31 bit length: add 00800000 (0-7fffffff + 00800000) (blocks 524288-8912895)

transaction number in block:

bit 0-2: length: number of words + 2 - 3 bits

000: 5 bit length (0-31)
001: 9 bit length (0-511)
010: 13 bit length (0-8191)
...
111: 25 bit length (0-33554431)

vout number:
bit 0-1: length: number of words + 2 - 2 bits

00: 6 bit length (0-63)
01: 10 bit length (0-1023)
10: 14 bit length (0-16383)
11: 18 bit length (0-262143)

for my example address:

block 234822, 0x39546h : 000000000000000006880233f89f572f006fd5dad0d1729d6d81622e8921e15f
transaction #18, 0x11h : fe17ff4c6df314cc708b2bab011a6327b61ffce81b4f7948ca8c6e7d3ee46105
vout #3, 0x02h: address 1Pi9uP6YMqbvbrQ1b7m6qzAS5ejN7mSwWR

encoding base58(bitstream):
MSB 1: 1
block# bits: 0 00000111001010101000110
trans# bits: 000 10001
vout# bits: 00 00000010

>>> hex(0b1000000111001010101000110000100010000000010)
'0x40e55184402L'

>>> bitcoin.changebase('1000000111001010101000110000100010000000010',2,58)
'329UugoB'

So I get an eight-character micro-address of 329UugoB.

The length here doesn't vary based on how many bitcoin address characters it takes to be unique within a block. It only gets longer after block 524287 or if there was a huge block and the transaction also had many outs. I'm sure even more optimized encoding could be thought up to minimize the average address lookup bits required.