Bitcoin Forum
May 13, 2024, 02:00:35 AM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: Weighted Trust  (Read 1084 times)
dibbs (OP)
Newbie
*
Offline Offline

Activity: 22
Merit: 0


View Profile
October 10, 2011, 02:50:24 AM
 #1

I apologize in advance if this has been discussed already, but my search skills can be pretty terrible.

Wouldn't it be possible to partially fix the 50%+1 issue by having clients weigh how much they trust the source of new (and maybe even old) blocks? Basically, every time you generate 50 BTC, you get a new key pair with it, right? This key pair is associated with a generation time. If, when miners generate new blocks, they also demonstrate possession of their oldest key pair by signing something with it, we could decide to trust them more, since they've been around longer. This isn't perfect, but it'd at least up the requirements for prospective attackers.

Note: This is half-baked, so please go easy on me. Smiley I've no idea, for example, if it's too much of a burden on the network (particularly lightweight clients who don't have the full blockchain) to verify age like this.
1715565635
Hero Member
*
Offline Offline

Posts: 1715565635

View Profile Personal Message (Offline)

Ignore
1715565635
Reply with quote  #2

1715565635
Report to moderator
Remember that Bitcoin is still beta software. Don't put all of your money into BTC!
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
1715565635
Hero Member
*
Offline Offline

Posts: 1715565635

View Profile Personal Message (Offline)

Ignore
1715565635
Reply with quote  #2

1715565635
Report to moderator
mrb
Legendary
*
Offline Offline

Activity: 1512
Merit: 1027


View Profile WWW
October 10, 2011, 04:04:11 AM
 #2

I apologize in advance if this has been discussed already, but my search skills can be pretty terrible.

Wouldn't it be possible to partially fix the 50%+1 issue by having clients weigh how much they trust the source of new (and maybe even old) blocks? Basically, every time you generate 50 BTC, you get a new key pair with it, right? This key pair is associated with a generation time. If, when miners generate new blocks, they also demonstrate possession of their oldest key pair by signing something with it, we could decide to trust them more, since they've been around longer. This isn't perfect, but it'd at least up the requirements for prospective attackers.

Note: This is half-baked, so please go easy on me. Smiley I've no idea, for example, if it's too much of a burden on the network (particularly lightweight clients who don't have the full blockchain) to verify age like this.

Key pairs are not associated to a generation time. They are created at will and are independent of anything else.

If you are talking about signing blocks specifically with keys there associated to previously solved blocks, then how would the bootstrapping mechanism work? Which key would a first-time solver use to sign the block?
dibbs (OP)
Newbie
*
Offline Offline

Activity: 22
Merit: 0


View Profile
October 10, 2011, 04:40:22 AM
 #3

Key pairs are not associated to a generation time. They are created at will and are independent of anything else.
But they are associated with a first transaction (which has a date). Plus, I'm not talking about any old key pair:

Correct me if I'm wrong, but if you have a miner that mines 50 BTC, you receive those 50 BTC by generating a new key pair, and broadcasting your block solution and the public key to the network. The network then associates 50 BTC with that public key. Therefore, your key pair is associated with that generation, and thus, the time the generation transaction occurred.
mrb
Legendary
*
Offline Offline

Activity: 1512
Merit: 1027


View Profile WWW
October 10, 2011, 04:54:58 AM
 #4

Correct me if I'm wrong, but if you have a miner that mines 50 BTC, you receive those 50 BTC by generating a new key pair, and broadcasting your block solution and the public key to the network. The network then associates 50 BTC with that public key. Therefore, your key pair is associated with that generation, and thus, the time the generation transaction occurred.

Correct. In this case, my 2nd paragraph is my answer to you.
dibbs (OP)
Newbie
*
Offline Offline

Activity: 22
Merit: 0


View Profile
October 10, 2011, 04:58:39 AM
 #5

Oops, missed that.

Anyway, bootstrapping seems simple; just sign the block with the new key. That becomes your oldest block key. That means you are very young, and have only the default level of trust.
mrb
Legendary
*
Offline Offline

Activity: 1512
Merit: 1027


View Profile WWW
October 10, 2011, 06:19:47 AM
 #6

Your entire premise is that old keys/users are more trusted. It is dangerous to assume this. An attacker with much less than 50% of the computing power could outrun the legitimate chain on the simple merit that he owns (or illegitimately gain access to) an old enough key...

It would also further reduce the pseudo-anonymity of Bitcoin by correlating all blocks owned by one person by looking at which key signed them.

And it would unfairly advantage early-adopters with old keys, who are already advantaged by having mined a lot of coins at a historically low difficulties.
dibbs (OP)
Newbie
*
Offline Offline

Activity: 22
Merit: 0


View Profile
October 10, 2011, 03:44:12 PM
 #7

Your entire premise is that old keys/users are more trusted.  It is dangerous to assume this.
Right now, we extract trust from a majority vote. I'm just saying this could be another source to extract additional trust. Yes, I haven't ironed out all of the details. Let's iron them out. (And thanks for helping with this, btw).

An attacker with much less than 50% of the computing power could outrun the legitimate chain on the simple merit that he owns (or illegitimately gain access to) an old enough key...
To deal with this, keys could be registered (see below) and this registration could have a limited lifespan, and could be expired by anyone possessing a copy (if the legitimate owner retains a backup, he could send an expiration notice to the network, despite the attacker having a copy).

It would also further reduce the pseudo-anonymity of Bitcoin by correlating all blocks owned by one person by looking at which key signed them.
No, because keys registered as trust keys would have a limited lifespan, and should be expired/replaced on an on-going basis. 50%+1 attacks would likely be hit-and-runs. We probably only need the keys' registration to last a week to improve resiliency.

And it would unfairly advantage early-adopters with old keys
Not necessarily. We could require the key to be registered as a trust key at the time of block generation, in which case, during this feature's bootstrapping, everyone would have the default level of trust. Keys cannot be retroactively registered.

Thanks again. I hope something useful comes out of this discussion.
dibbs (OP)
Newbie
*
Offline Offline

Activity: 22
Merit: 0


View Profile
October 11, 2011, 12:36:21 AM
 #8

Nobody else? Is the idea not worth developing?
2112
Legendary
*
Offline Offline

Activity: 2128
Merit: 1068



View Profile
October 11, 2011, 12:45:26 AM
 #9

Is the idea not worth developing?
I think it is, but not at this stage in the Bitcoin lifetime. Lets wait one or two knees in the mining-lottery-ticket curve.

I was thinking a bit about placing trust not in peers but in exchanges. Exchanges are the part of the ecosystem that has the most stable cash flow. Lets say you regularly deal with MtGox. It would mean that you are willing to listen to MtGox if they broadcast a block-chain checkpoint. Something like that. Because they have a stable(-st) cash they should have the resources to cross-validate competing branches of the block-chain.

Please comment, critique, criticize or ridicule BIP 2112: https://bitcointalk.org/index.php?topic=54382.0
Long-term mining prognosis: https://bitcointalk.org/index.php?topic=91101.0
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!