Bitcoin Forum
August 08, 2024, 02:53:04 PM *
News: Latest Bitcoin Core release: 27.1 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 [2]  All
  Print  
Author Topic: SegWit is a waste of disk space?  (Read 3413 times)
simonbtc
Newbie
*
Offline Offline

Activity: 16
Merit: 0


View Profile
May 04, 2016, 07:52:24 PM
 #21

And when you've done that, tada you have segwit (specifically, you get the _exact_ construction that was used in elements alpha).  But a version of it with a ugly construction that requires every Bitcoin speaking program to upgrade _simultaneously_, and invalidates any pre-created nlocktimed transactions which _will_ confiscate some amount of users' Bitcoins (because some parties have been signing payments then destroying private keys as a time-lock-safe mechanism).

Isn't this a user problem rather than a protocol issue?  First, the protocol doesn't specify that a user must destroy their private key when creating nLockTimed transactions.  Second, since there's no guarantee that any given transaction will ever be successfully mined, it doesn't seem prudent to pre-sign transactions which sit off-chain and only become valid for broadcast and potential mining in some distant future whilst also deleting the private key.  If this destructive behaviour can be condoned, it beggars belief that zero conf transactions are considered unsafe.
achow101
Moderator
Legendary
*
expert
Offline Offline

Activity: 3472
Merit: 6797


Just writing some code


View Profile WWW
May 04, 2016, 08:04:19 PM
 #22

And when you've done that, tada you have segwit (specifically, you get the _exact_ construction that was used in elements alpha).  But a version of it with a ugly construction that requires every Bitcoin speaking program to upgrade _simultaneously_, and invalidates any pre-created nlocktimed transactions which _will_ confiscate some amount of users' Bitcoins (because some parties have been signing payments then destroying private keys as a time-lock-safe mechanism).

Isn't this a user problem rather than a protocol issue?  First, the protocol doesn't specify that a user must destroy their private key when creating nLockTimed transactions.  Second, since there's no guarantee that any given transaction will ever be successfully mined, it doesn't seem prudent to pre-sign transactions which sit off-chain and only become valid for broadcast and potential mining in some distant future whilst also deleting the private key.  If this destructive behaviour can be condoned, it beggars belief that zero conf transactions are considered unsafe.
While that is a user issue, it is not something that changing the protocol should mess with. If you change the protocol and you cause several users to suddenly have transactions that they just sent suddenly be invalid, you will anger many users and potentially cause them to stop using Bitcoin.

About destroying the keys, there are some companies that provide multisig addresses and a pre-signed timelocked transaction to allow users to withdraw their balance should the service suddenly go down. If the service went down and this change happened, those users would no longer be able to access their coins.

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!