Bitcoin Forum
June 20, 2019, 12:27:37 PM *
News: Latest Bitcoin Core release: 0.18.0 [Torrent] (New!)
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: Idea for uncensorable DNS  (Read 472 times)
theymos
Administrator
Legendary
*
Offline Offline

Activity: 3416
Merit: 5929


View Profile
April 29, 2019, 02:11:56 AM
Merited by joniboini (3), bones261 (2), TimeBits (2), ETFbitcoin (1), BitMaxz (1), HeRetiK (1), iasenko (1)
 #1

Maybe someone already thought of this, but in case not:

Goal

Provide a decentralized system to convert memorable short names like "bitcointalk.bit" into a small amount of data (512 B, say), while making it impossible for anyone by any means to take down or block names so registered.

Naïve solution

You can just put the name data into a block chain like Namecoin does, but this isn't ideal for (at least) these two reasons:
 - Miners and network participants can blacklist certain names, preventing them from operating. In the case of miners, only a majority of mining power is necessary to ban a name network-wide.
 - Network participants could perhaps be legally forced not to provide-for-download transactions/data related to certain domains. For example, a node operator could receive a DMCA takedown. (The exact legal details are debatable, but it's within the realm of possibility.)

(BTW, decentralized database systems usually have the same problem. Participants in the Tor hidden service DHT could refuse to provide service to certain hidden services which they blacklist, and if this happened on a wide scale it'd bring down the hidden service. I sketched out a possible solution for that problem in this post.)

Enhancement 1: time-delay encryption

Assume name data is being mined into blocks. Instead of having the blocks be immediately readable, the name data portion can be temporarily encrypted in this way:
 1. Hash together the concatenated hashes of the blocks with depth 20 through 120 or so to get a seed.
 2. Using the seed, choose a random pubkey point on a secp256k1-like curve. You get the point directly, not by producing a private key.
 3. Once you solve the block, you will asymmetrically encrypt the namedata portion to that pubkey.
 4. In order to solve the block, you need to brute-force the last not-yet-decrypted block from eg. ~24 hours ago, and include the private key in your new block. This is unsuitable as a timestamping proof-of-work, so after you do this and encrypt the namedata, you also have to timestamp your block hash using OpenTimestamps or similar.

Unlike eg. RSA, AFAIK all valid-looking secp256k1 pubkeys have a private key. Difficulty should be auto-adjusted to maintain the ~24-hour delay by producing modified versions of secp256k1 with smaller integer sizes.

You could also use symmetric crypto with a random instead of seeded key, but then the miner knows the key, so you can't use it for PoW. Also, although I don't use it in this post, it might be useful in some cases to allow people to encrypt transactions/data to one of these pubkeys.

This prevents miners from soft-forking out blocks which contain banned names. By the time they can test whether the block contains a banned name, it'll be deep in the chain and therefore difficult to undo.

Enhancement 2: mixing together namedata

Each block needs to contain a function which takes a name and produces the output data for that name. Typically this is done as just a list, but this makes it easy to modify the list. If a name is banned, nodes could republish block data with that name's data redacted. My solution to this is to construct the function so that all of the name data is jumbled together, it's not immediately obvious which names are contained in it (though you can test individual names), and you can't remove one name without affecting everything else. The best thing I've come up with for constructing such a function is:

 1. Let hash(name) = encHash and hash(encHash) = idxHash. The name's data is encrypted with the key encHash before being published to the network.
 2. Each miner generates a random key and encrypts idxHash and the name data before dealing with them, purely to ensure that they are uniformly random. This key is published in the block's unencrypted segment.
 3. Looking at all idxHash values in his candidate block, the miner attempts to find a most-minimal subset of their bits such that each idxHash is uniquely identified by as few bits as possible. (Note that duplicate idxHash values are not allowed.) The chosen bits can be in any order, and need not be contiguous. For example, a miner might find that bits 2,3,10,15,22,1,40,32,100,125 results in unique IDs for 500 entries. This is published in the final block.
 4. Using the smaller index value for each name, the miner constructs a truth table with the index as input bits and the double-encrypted name data as the output bits. When the block is nearly complete, the miner converts this truth table into an as-minimal-as-possible set of boolean formulas.

Example:
Say that you have these keys (name hashes) and values:
Code:
KEY     VALUE
6A80AE9 A1
CDE2E9D 22
14DB3CF B3
1F43947 24
2CA8297 45

(In reality the keys would be 256 bits long, the values would be perhaps 4096 bits long, and there would be many more pairs.)

First, I choose a small subset of bits from the input such that each pair has a unique value. I choose bits 11-8, giving a binary truth table like this:
Code:
IN   OUT
1010 10100001
1110 00100010
0011 10110011
1001 00100100
0010 01000101

And then I create boolean formulas from that, dictating the output of each bit 7-0:
Code:
e1 = i3&!i2&!i0;
e2 = i1&i0;
e3 = !i3&!i0;

o7 = e1 | e2;
o6 = e3;
o5 = !i1 | e1 | e2 | i2;
o4 = e2;
o3 = 0;
o2 = !i1 | e3;
o1 = e2 | i2;
o0 = e1 | e2 | e3;

That's the function. When given the a key, it produces the correct output. Eg. for input 0011 you get:
Code:
i3 = 0
i2 = 0
i1 = 1
i0 = 1

e1 = i3&!i2&!i0 = 0;
e2 = i1&i0 = 1;
e3 = !i3&!i0 = 0;

o7 = e1 | e2 = 1;
o6 = e3 = 0;
o5 = !i1 | e1 | e2 | i2 = 1;
o4 = e2 = 1;
o3 = 0;
o2 = !i1 | e3 = 0;
o1 = e2 | i2 = 1;
o0 = e1 | e2 | e3 = 1;

But you can't tell by looking at the function which keys were used to create it. You can test that it contains a name by trying to resolve the name using the function's data and seeing if it works, but if you want to remove it from the function, there's no way to do so without possibly ruining other keys, since you don't know what other keys are represented in the function, and everything is tangled together.

Sketch of the rest of a DNS

Every block should have a bloom filter matching the idxHash values within it, in the encrypted segment. To resolve a name, you'd go through every block in the past and check the name's idxHash against the bloom filter. If it passes the bloom filter, you reconstruct the data using the function explained above and try to decrypt it using its encHash. If it decrypts with a good MAC, then it's OK. You get the current name data by replaying its entire history of valid namedata updates, the first-ever of which will have a pubkey with which the rest are signed. Names might expire if not updated for a few years, to allow lost ones to return to the pool.

For payment, this is the best I could come up with: To register/update a name, you'd pay a "registrar" and give them the encrypted namedata update & idxHash. The registrar would send the namedata update to all miners along with a willing-to-pay price, signed with the registrar's own key. When a miner includes it (which the registrar & other miners can check by trying to find the idxHash in every future block once it's decrypted), the registrar pays a miner-address listed in the block the promised amount. Miners keep track of which registrars are actually paying them the promised amounts, and will blacklist any who stiff them. To start a new registrar, you might pay a miner an initial fee to get them to start listening to your transactions.

Miners would be constantly trying to brute-force the last unbroken encryption key from about a day ago. Unlike with normal cryptocurrencies, they wouldn't actually construct their final block until they found the solution. When they find it, they'd use OpenTimestamps to timestamp their block, wait for a timestamp-on-Bitcoin confirmation, and then broadcast it. To prevent withholding attacks, nodes would refuse to ever reorg unless the two candidate blocks are actually seen within minutes of each other. The brute-force difficulty might adjust only if the block interval goes outside of a pretty large range, which would allow for block generation to be more responsive to demand.

Flaws

When you first register a name, nobody has any idea what it is since registrars and miners only get the hash and the encrypted data. But once the name becomes publicly-known, registrars and miners could refuse to process matching idxHash updates. This may be somewhat annoying, but since a softfork banning the name network-wide isn't possible, enough darknet registrars/miners should exist to make this not too much of a problem.

To resolve a name, you have to download and scan through every past block. I think that blocks should be pretty small (perhaps about 25-50kB per 10k domain updates?), and the max block size could be set very restrictively. Scanning a single block should be extremely fast, and it's also parallelizable. But after many years, the history could accumulate to the point of being problematic, and I can't see a perfect way of resolving this. One optimization would be to require that every domain send at least one update a year, and require that every update contain a pointer to the first-ever update which created the name; then, if there are no conflicts in a year, you can just trust that one, and if there are conflicts, you can check through a subset of the whole history to figure out which claim is correct.

To prevent miners from filling up every block with domain-squatted domains, maybe there should be some additional cost for every registration. One way to do this would be to require a hashcash proof-of-work in the data for every new domain -- if it's not there, then the registration is ignored at resolve-time as if it didn't exist.

I wonder if it's theoretically possible to create a homomorphic encryption scheme where an encrypted registry database is maintained which nobody has the decryption keys for, but it's still possible to do lookups. That'd be ideal.

1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
1561033657
Hero Member
*
Offline Offline

Posts: 1561033657

View Profile Personal Message (Offline)

Ignore
1561033657
Reply with quote  #2

1561033657
Report to moderator
Try The Brand New Ethereum Game
50 Last Players Also Win The Bank
Works On Any iOS/Android Device With Standard Browser
Join Us On Telegram To Get Notified When You Can Win
COLOR PIXELS
AND WIN
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1561033657
Hero Member
*
Offline Offline

Posts: 1561033657

View Profile Personal Message (Offline)

Ignore
1561033657
Reply with quote  #2

1561033657
Report to moderator
gmaxwell
Moderator
Legendary
*
qt
Online Online

Activity: 2758
Merit: 2315



View Profile
April 29, 2019, 02:59:11 AM
Merited by theymos_away (10), bones261 (3), joniboini (3), ETFbitcoin (1), BitMaxz (1)
 #2

This prevents miners from soft-forking out blocks which contain banned names. By the time they can test whether the block contains a banned name, it'll be deep in the chain and therefore difficult to undo.
Well, not quite: the softfork could require that each block come with side information to decrypt all the names registered in it.  But at least they couldn't quietly pick and choose names.

Quote
function so that all of the name data is jumbled together, it's not immediately obvious which names are contained in it (though you can test individual names), and you can't remove one name without affecting everything else. The best thing I've come up with for constructing such a function is:

I think the tool you want is a locally decodable error correcting code. (some old discussion applying it to blocks)

For your use the idea is that you take all the data and using an error correcting code create an expanded version that gets committed.  When someone wants a record, they pick a random set of records from the very large set of possible records which could be used to decode the record they want.

If someone tries to censor a particular record, they'll have to refuse to answer queries that would be used to answer other records... rapidly finding themselves in a position of being unable to answer anything at all or else they'll leak enough information to recover the hidden record.

With this approach a system can be constructed with precise guarantees on the attacker's ability to censor. Though the relevant error correcting codes might have poor computational performance.

Ideally the thing users would query would be a database of all names, not a block... so that the interlocking set is the set of all names.

Quote
becomes publicly-known, registrars and miners could refuse to process matching idxHash updates.
I'm not sure why the timelock encryption couldn't be used to help with that.

This may be somewhat annoying, but since a softfork banning the name network-wide isn't possible, enough darknet registrars/miners should exist to make this not too much of a problem.

Quote
I wonder if it's theoretically possible to create a homomorphic encryption scheme where an encrypted registry database is maintained which nobody has the decryption keys for, but it's still possible to do lookups. That'd be ideal.

Depends on what you mean.

I mean,  instead of a database of names you could have a database of HASH(name).  You could even encrypt the records with HASH2(name), so unless you're aware of the name you don't see it--- makes it harder to go "fishing for offence".


I think what you probably want though is something that even knowing the name, you can't tell if a record contains a name?  That is sort of incompatible with lookup, by definition. ... unless you imagine that the users know some secret key that isn't known by the database operators, if so, then its trivial.





 
theymos
Administrator
Legendary
*
Offline Offline

Activity: 3416
Merit: 5929


View Profile
April 29, 2019, 05:55:49 AM
 #3

I think the tool you want is a locally decodable error correcting code. (some old discussion applying it to blocks)

Ah, good idea! It's not immediately obvious to me how you'd merge all of the data together, though.

Quote
I'm not sure why the timelock encryption couldn't be used to help with that.

In my boolean expression scheme, it seems necessary for miners to merge together all of the transactions with their true indexes, since this is important for performance and uncensorability, and merging can AFAICT only be done once. In a scheme based on error correcting codes, the time-delay encryption probably could be used here.

Quote
Depends on what you mean.

What I had in mind was an asymmetric lattice-based system where an encrypted database would be initialized by someone, but then the private key would be discarded. Then all network participants would have copies of the encrypted database and perform operations on it which would add/remove/update DNS data by encrypting the updates to the database's public key, but it (hopefully) wouldn't be possible to tweak the encrypted database directly in order to censor specific entries. Transactions would look like "apply UPDATE operation on your copy of the database using input <data encrypted to pubkey>".

However, as far as I can tell there'd be no way to get unencrypted data out of such a database in a controlled way, which you'd need to do in order to do lookups.

1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
100bitcoin
Sr. Member
****
Offline Offline

Activity: 551
Merit: 268


View Profile
April 29, 2019, 04:30:02 PM
 #4

Has not the idea of uncensorable DNS been proposed before, while Satoshi was around?

bitDNS - https://bitcointalk.org/index.php?topic=1790.0

theymos
Administrator
Legendary
*
Offline Offline

Activity: 3416
Merit: 5929


View Profile
April 29, 2019, 07:12:53 PM
 #5

Has not the idea of uncensorable DNS been proposed before, while Satoshi was around?

bitDNS - https://bitcointalk.org/index.php?topic=1790.0

I posted in that topic in 2010. Wink Still haven't given up on the idea.

The specific idea in that topic was basically Namecoin, but implemented sort of like a naïve colored coins thing on Bitcoin. Eventually it became Namecoin. In any case, it has the censorability issues I mentioned in my OP.

1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
gmaxwell
Moderator
Legendary
*
qt
Online Online

Activity: 2758
Merit: 2315



View Profile
April 30, 2019, 07:16:14 PM
 #6

Vaguely related to Theymos' post, I ran into this old post of mine today: https://en.bitcoin.it/wiki/User:Gmaxwell/namecoin_that_sucks_less
DaveF
Hero Member
*****
Offline Offline

Activity: 1100
Merit: 679


View Profile WWW
May 07, 2019, 02:41:29 AM
 #7

Unless I am missing something (which I may well be) although the concept is good, you would have to re-do how DNS is queried down to the desktop / iot level.
I can see this being useful for people who are tech knowledgeable but for a lot of people it's going to be an issue.

There have been other instances in the early 2000s with people trying something like this, I would have to dig up my work from 2001 / 2002 from a client who tried something similar. They were trying to get DNS queries out of certain areas that were blocking them. It worked well to a point, but due to performance issues and other equipment that could not run the custom app the project was scrapped. But I might still have some code pieces and notes around. They tried using it as an internal DNS server, but other issues (mostly performance) arose.

-Dave
AndreyVen
Newbie
*
Offline Offline

Activity: 28
Merit: 0


View Profile
May 08, 2019, 03:52:38 AM
 #8

Add to your idea: Preventing people from hoarding domains, you'll have to "maintain" validity say every 1 or two years. After x amount of blocks the registrations decays unless it is resubmitted within said timeframe by the owners private key.

This is especially true for short domains. Value increases exponentially the shorter the domain. You don't want people "hoarding" all the X.bit XX.bit XXX.bit and XXXX.bit domains. They should eventually end up in the hands of those who make the most of the short domains. You could even make the registration fee inversely proportional to the length of the domain. Say if you simply need 1000 domains for your backend network setup, you can register those for next to nothing if they are say something like networkdomainexample1112.bit while you pay 100 times the fee for say btc.bit.
OgNasty
Donator
Legendary
*
Offline Offline

Activity: 2954
Merit: 1690


I 💚 Bitcoin


View Profile
May 08, 2019, 08:59:55 AM
 #9

Has not the idea of uncensorable DNS been proposed before, while Satoshi was around?

bitDNS - https://bitcointalk.org/index.php?topic=1790.0

I posted in that topic in 2010. Wink Still haven't given up on the idea.

The specific idea in that topic was basically Namecoin, but implemented sort of like a naïve colored coins thing on Bitcoin. Eventually it became Namecoin. In any case, it has the censorability issues I mentioned in my OP.

Do you think it is not possible for Namecoin to overcome the potential censorship issues on it’s blockchain? I’ve always held onto the hope that Namecoin’s brightest days were still in front of it as it’s use case is one of the most justifiable I’ve seen.

Have you seen my prize winning cow? She’s out standing in her field.
100bitcoin
Sr. Member
****
Offline Offline

Activity: 551
Merit: 268


View Profile
May 09, 2019, 06:18:26 PM
 #10

Has not the idea of uncensorable DNS been proposed before, while Satoshi was around?

bitDNS - https://bitcointalk.org/index.php?topic=1790.0

I posted in that topic in 2010. Wink Still haven't given up on the idea.

The specific idea in that topic was basically Namecoin, but implemented sort of like a naïve colored coins thing on Bitcoin. Eventually it became Namecoin. In any case, it has the censorability issues I mentioned in my OP.

Do you think it is not possible for Namecoin to overcome the potential censorship issues on it’s blockchain? I’ve always held onto the hope that Namecoin’s brightest days were still in front of it as it’s use case is one of the most justifiable I’ve seen.

I'm guessing, you are a Namecoin HODLer. No? Roll Eyes

gentlemand
Legendary
*
Online Online

Activity: 2044
Merit: 1740


Baby Blue Panties


View Profile
May 11, 2019, 12:51:44 PM
 #11

I'm guessing, you are a Namecoin HODLer. No? Roll Eyes

You don't have to be a shill/bagholder to believe something's concept is worthwhile.

Poloniex, by far its biggest market, is delisting it so it looks like its future may recede to theory. Perhaps that'll reinvigorate the thinking behind it.


btj
Member
**
Offline Offline

Activity: 112
Merit: 14


View Profile
May 16, 2019, 06:48:19 PM
 #12

Nice idea.

But about about preventing peoples from bulk domain generation ?

Someone with a good machine can take all the first and high quality domain names in one day.
TimeBits
Member
**
Offline Offline

Activity: 154
Merit: 36


View Profile WWW
May 17, 2019, 02:01:11 AM
Last edit: May 17, 2019, 02:18:41 AM by TimeBits
 #13

Nice idea.

But about about preventing peoples from bulk domain generation ?

Someone with a good machine can take all the first and high quality domain names in one day.

I have a pretty good idea so people can have the same domain name, but their address could be at the end of the url to make it different

example

youtube.bit/1BDvQZjaAJH4ecZ8aL3fYgTi7rnn3o2thE
youtube.bit/35yTJTRLgSKcCshAer7XhA24PNJra8xrpW
youtube.bit/12cbQLTFMXRnSzktFkuoG3eHoMeFtpTu3S

So no matter what initial url you want, your address will be tied to it.

btw have they made a fix for the cloning address thing? I read something about it like 7 years. Is it still possible to just create a billion^10 addresses in the bitcoin wallet and obtain someone else's?  I know it would take years and the chances are really low, but if that is still a thing it needs to be fixed. I have a fix for that to. Well an idea to fix it, I am not a coder but I understand how it works a little.

A few things we could do, is have a timer in play so you can`t create a new address on the same .dat file for at least every 24 hours.
Could the blockchain not already know what addresses have been created and cancel out duplicates, not allow that address to be used again? can we just add another digit or number to the address "bank"?

I started a auto clicker a few years back just to spam create addresses in the bitcoin wallet, I think if I multi boxed it I would get someone else`s at some point in time? or is this fixed?
ETFbitcoin
Legendary
*
Offline Offline

Activity: 1680
Merit: 1809

Use SegWit and enjoy lower fees.


View Profile WWW
May 17, 2019, 05:45:26 PM
 #14

I have a pretty good idea so people can have the same domain name, but their address could be at the end of the url to make it different

example

youtube.bit/1BDvQZjaAJH4ecZ8aL3fYgTi7rnn3o2thE
youtube.bit/35yTJTRLgSKcCshAer7XhA24PNJra8xrpW
youtube.bit/12cbQLTFMXRnSzktFkuoG3eHoMeFtpTu3S

So no matter what initial url you want, your address will be tied to it.

Then your website domain would be :
1. Very long
2. Unattractive
3. Not rememberable

You might as well as share your website's IP which is shorter and easier to remember (only 0-9 for IPv4 and 0-F for IPv6).

btw have they made a fix for the cloning address thing? I read something about it like 7 years. Is it still possible to just create a billion^10 addresses in the bitcoin wallet and obtain someone else's?  I know it would take years and the chances are really low, but if that is still a thing it needs to be fixed. I have a fix for that to. Well an idea to fix it, I am not a coder but I understand how it works a little.

There are 2^160 possible address combination (excluding P2SH and Bech32 address format) and chances for address collusion is near zero.

There are few concern cryptographic hash with 160-bit length (such as SHA-1) is no longer secure, especially to collision attack. But don't forget to generate an address (from private key) is far slower than run a hash function. CMIIW.

A few things we could do, is have a timer in play so you can`t create a new address on the same .dat file for at least every 24 hours.
Could the blockchain not already know what addresses have been created and cancel out duplicates, not allow that address to be used again? can we just add another digit or number to the address "bank"?

I started a auto clicker a few years back just to spam create addresses in the bitcoin wallet, I think if I multi boxed it I would get someone else`s at some point in time? or is this fixed?

It's possible, but the wallet must have list of all address which used on blockchain.

TimeBits
Member
**
Offline Offline

Activity: 154
Merit: 36


View Profile WWW
May 18, 2019, 01:34:29 AM
Last edit: May 18, 2019, 02:05:54 AM by TimeBits
 #15


Then your website domain would be :
1. Very long
2. Unattractive
3. Not rememberable

There are 2^160 possible address combination (excluding P2SH and Bech32 address format) and chances for address collusion is near zero.

It's possible, but the wallet must have list of all address which used on blockchain.

1. You can name addresses yourself (just like you can name wallets) that is up to the user
2. ^
3  Bookmarks
Users could index the websites (vote thumbs up or thumbs down) so they can find the better youtube.com/whatever (like a darknet directory with levels of trust)

"There are 2^160 possible address combination (excluding P2SH and Bech32 address format) and chances for address collusion is near zero."

It needs to be 0
. I can make around 100,000 accounts a day or maybe in a hour or less actually on my household computer just running 1 bitcoin wallet and 1 auto clicker, Imagine a super computer multi boxing the same wallet 500x-500,000x or more.

Why not have a "if address already belongs to a user, double the AES or P2SH and Bech32 format" (sure address would be long in future but at least we won`t get duplicates)
"if address already belongs to user at double, triple the format" and so on.
or "if address is already in use, reroll address" - "if all addresses are in use double amount of characters allowed" - "if all addresses are in use triple amount of characters allowed"

Does this make sense to you?

What stops someone from doing this offline and connecting later and perhaps getting satoshi`s addresses than brute forcing the private key? Do we have a way to tell who created the address first?
(Yes, I know with today`s tech it will take a long time) but not in the future.

I just want bitcoin to be as safe as possible not just in my lifetime but for lifetimes, we seen the evolution of miners in 8 years laptops->desktops->farms of desktops->asics->farms of asics, what about in another 8?

The more air that gets pushed into a tire the more likely it is to pop, why not make the tire immortal?
ETFbitcoin
Legendary
*
Offline Offline

Activity: 1680
Merit: 1809

Use SegWit and enjoy lower fees.


View Profile WWW
May 18, 2019, 06:22:31 PM
Merited by LoyceV (1)
 #16

1. You can name addresses yourself (just like you can name wallets) that is up to the user
2. ^
3  Bookmarks
Users could index the websites (vote thumbs up or thumbs down) so they can find the better youtube.com/whatever (like a darknet directory with levels of trust)

1. If you meant vanity address, then overall domain is still long

Your idea is feasible if we compare it with darknet (such as Tor and I2P) which also don't have user-friendly domain.
But not when when we compare it with clear net which could have short, attractive and rememberable domain name.

"There are 2^160 possible address combination (excluding P2SH and Bech32 address format) and chances for address collusion is near zero."

It needs to be 0
. I can make around 100,000 accounts a day or maybe in a hour or less actually on my household computer just running 1 bitcoin wallet and 1 auto clicker, Imagine a super computer multi boxing the same wallet 500x-500,000x or more.

0 (Zero) probability? It's impossible unless we switched to cryptography where collusion is impossible (if it's exist)

Why not have a "if address already belongs to a user, double the AES or P2SH and Bech32 format" (sure address would be long in future but at least we won`t get duplicates)
"if address already belongs to user at double, triple the format" and so on.
or "if address is already in use, reroll address" - "if all addresses are in use double amount of characters allowed" - "if all addresses are in use triple amount of characters allowed"

Does this make sense to you?

Yes. Read my reply above.

Also, what stops user to modify wallet source-code to prevent "reformat address" when collusion if found?

TimeBits
Member
**
Offline Offline

Activity: 154
Merit: 36


View Profile WWW
May 19, 2019, 06:49:26 AM
Last edit: May 19, 2019, 07:50:12 AM by TimeBits
 #17


0 (Zero) probability? It's impossible unless we switched to cryptography where collusion is impossible (if it's exist)

Yes probably a good idea to switch or update.
All I know is when I make a account on a few different games or try and use a email that someone already has I get
"The username/email address is already in use"

Why not add that to the code?

I am not comfortable with "chances for address collusion is near zero" I want a system that address collusion is 0. I don`t think it would be to hard to cook up.

Also what stops someone from multi boxxing brute force (to run trillions of them at once on a single computer), Having the bruteforce program attached to a blockchain so all the brute forces know what the other one has already tried, and getting private keys in the near future? I really think they need to add fingerprint/eyescans/dna captcha`s to secure wallets.  That way someone actually needs your eyes to open your wallet.

Like this poopy example: https://www.youtube.com/watch?v=l4x0vOAu0lQ Proof of Person/Population, blockPOP
(we could also make them take there fingerprint from the left, or right or upside down (fingerprint captcha, kind of like the eye captcha in this video)
If we went as far as DNA, we could actually tell the person is dead on the blockchain and someone is using dna/spit/blood/piss or carbon imprint, Proof of Alive.

Pretty easy to spread malware keyloggers on most phones or even on the apple app store or google play store, take a look at this kid for example.
Skip like 5 mins in https://www.youtube.com/watch?v=zcUDFnTj4jI Showing how your iPHONE can SPY on you (Apple Store) ScreenTime, He literally could make a bunch of apps that are just keystroke/video and screen loggers.

I used to work for AT@T call center, I had 0 security clearance, I could jack anyone's pin or sin cards. Once I hooked up a guy with 500 phone accounts because he was trying to make his girlfriend win in a beauty contest, my manager told me so long as he has the sin cards to make the accounts for him. (phone verification is not the way to go)

What if I go into a public library or school and keylog those networks or take over the mcdonalds wifi.

Anyways, everything you do on apple or windows is keylogged anyways.

I mean I rather have myself as my key, rather than a password written down somewhere. I know a lot of people will think this is some "mark of the beast" stuff but when they start getting blockBRUTEFORCED they will use it.
actually you just need a database not even blockchain to do this.
TimeBits
Member
**
Offline Offline

Activity: 154
Merit: 36


View Profile WWW
May 19, 2019, 07:30:12 AM
Last edit: May 19, 2019, 07:44:19 AM by TimeBits
 #18

In the meantime I really hope Satoshi is using a keymixer or keyscrambler on his/her private keys, if he/she keeps the same password for long enough it is only a matter of time before someone cracks them. There is people already working on it I am sure.
Pages: [1]
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!