Bitcoin Forum
May 07, 2021, 02:19:45 PM *
News: Latest Bitcoin Core release: 0.21.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 [2]  All
  Print  
Author Topic: Implementation of push / auto update feature on bitcoin (per configuration)  (Read 2505 times)
gmaxwell
Moderator
Legendary
*
qt
Offline Offline

Activity: 3416
Merit: 5122



View Profile
September 16, 2013, 02:15:39 PM
 #21

What I'd like to see is a hybrid model in which a large quorum (maybe 20-30 people) is required to sign for an auto update, and the people in that group agree to only sign for an auto update for security-sensitive fixes. The recent mod zero bug would qualify for instance, but fee changes wouldn't. Thus most upgrades would still roll out slowly, but if a buffer overflow or other way to compromise bitcoind was discovered the community could patch itself fast.
An idea I find attractive is to have the ability to have signers who can only give "negative karma"— these keys could be issued pretty liberally, since the only risk is that they delay an update. This models what we already believe to be the primary existing source of assurance: "if something bad is done, someone somewhere will sound an alarm". Coupled with suitable delays this could be pretty powerful.

The tricky part is having a jamming resistant way to get their negative views out to people.
1620397185
Hero Member
*
Offline Offline

Posts: 1620397185

View Profile Personal Message (Offline)

Ignore
1620397185
Reply with quote  #2

1620397185
Report to moderator
1620397185
Hero Member
*
Offline Offline

Posts: 1620397185

View Profile Personal Message (Offline)

Ignore
1620397185
Reply with quote  #2

1620397185
Report to moderator
1620397185
Hero Member
*
Offline Offline

Posts: 1620397185

View Profile Personal Message (Offline)

Ignore
1620397185
Reply with quote  #2

1620397185
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1620397185
Hero Member
*
Offline Offline

Posts: 1620397185

View Profile Personal Message (Offline)

Ignore
1620397185
Reply with quote  #2

1620397185
Report to moderator
1620397185
Hero Member
*
Offline Offline

Posts: 1620397185

View Profile Personal Message (Offline)

Ignore
1620397185
Reply with quote  #2

1620397185
Report to moderator
Peter Todd
Legendary
*
expert
Offline Offline

Activity: 1106
Merit: 1052


View Profile
September 16, 2013, 02:32:02 PM
 #22

The tricky part is having a jamming resistant way to get their negative views out to people.

It's too bad we don't have some kind of data structure that is automatically replicated to all Bitcoin nodes, and has some kind of "fee/KB" mechanism to discourage spamming it.

gmaxwell
Moderator
Legendary
*
qt
Offline Offline

Activity: 3416
Merit: 5122



View Profile
September 16, 2013, 02:43:46 PM
 #23

It's too bad we don't have some kind of data structure that is automatically replicated to all Bitcoin nodes, and has some kind of "fee/KB" mechanism to discourage spamming it.
I'm not sure that I'd want to promote mined transactions as a jamming resistant communications channel. Especially since, you know, it's not actually jamming resistant, and it's not hard to imagine examples where the miners would actually be interested in jamming NAKs on an update.
Mike Hearn
Legendary
*
expert
Offline Offline

Activity: 1526
Merit: 1018


View Profile
September 16, 2013, 03:22:53 PM
 #24

Perfect enemy of the good yadda yadda. The current alert broadcast mechanism would probably work OK for that. Hopefully it'd hardly ever be used. The difficult bit would be testing it in the real world.
Peter Todd
Legendary
*
expert
Offline Offline

Activity: 1106
Merit: 1052


View Profile
September 16, 2013, 03:25:39 PM
Merited by gmaxwell (1)
 #25

It's too bad we don't have some kind of data structure that is automatically replicated to all Bitcoin nodes, and has some kind of "fee/KB" mechanism to discourage spamming it.
I'm not sure that I'd want to promote mined transactions as a jamming resistant communications channel. Especially since, you know, it's not actually jamming resistant, and it's not hard to imagine examples where the miners would actually be interested in jamming NAKs on an update.

NAK's in the blockchain don't need to be exclusive though. For instance the protocol can be that NAK's are just some signed data, and you don't care how you get the data. For some scenarios putting it in the blockchain is great - the dev team goes crazy and backdoors the RNG - for others you're going to have to hope some other jam-proof communication mechanism works, like P2P distributed alerts or DNS seeds or whatever.

The big advantage of the blockchain is that many attacks aren't going to be very useful unless the target is synced with the network. Someone might, say, backdoor the RNG or make transactions be signed using nonces the attacker can predict. But users whose clients do manage to sync with the network will see the alert and not upgrade, and the ones that don't (because the attacker isolated them) are likely to do fewer transactions because they notice their client is acting funny and tx's aren't confirming or whatever.

Obviously the attacker could also fake parts of the GUI to make it looks like tx's are confirming, but now the number of lines of code they need to hijack just got even larger, making the attack even ever to spot.

Pages: « 1 [2]  All
  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!