From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1QwUX4-00084C-DF for bitcoin-development@lists.sourceforge.net; Thu, 25 Aug 2011 07:39:22 +0000 X-ACL-Warn: Received: from backup-server.nordu.net ([193.10.252.66]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) id 1QwUX2-0007qQ-P2 for bitcoin-development@lists.sourceforge.net; Thu, 25 Aug 2011 07:39:22 +0000 Received: from [109.105.106.197] ([109.105.106.197]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id p7P7dCWa017862 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 25 Aug 2011 09:39:13 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1244.3) From: =?iso-8859-1?Q?Michael_Gr=F8nager?= In-Reply-To: Date: Thu, 25 Aug 2011 09:39:12 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201108241215.36847.luke@dashjr.org> To: bitcoin-development@lists.sourceforge.net X-Mailer: Apple Mail (2.1244.3) X-Spam-Score: 0.0 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. 0.0 TO_NO_BRKTS_PCNT To: misformatted + percentage X-Headers-End: 1QwUX2-0007qQ-P2 Subject: Re: [Bitcoin-development] New standard transaction types: time to schedule a blockchain split? X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2011 07:39:22 -0000 Hi Gavin (the list escaped the cc...), I participated also in the hacakathon Sunday @ OnlyOneTV and I felt that = this had a strong chance to diverge. So - yes - I agree - no = "constitution" changes now. Further, I have thought later on on the = analogy of a clerk and a safe. WHen you enter the bank you hand over your money to the clerk (one key) = - then after the clerks wallet has been filled over the day _he_ = transfers the money to the safe (3 keys). My point is do we really need = the customer to bypass the clerk and have 3 key addresses, or could we = just leave it to the/a client to implement the multisign transaction = after the money has been received - as a transfer to a safe? This would = greatly simplify the problem and cover the vast majority of use cases. = Not covered in this is huge single transfers where the intruder of a = single key system finds it profitable to reveal their intrusion by = grabbing the entire wallet. Put in another way - do we *really* need to couple the securing of the = wallet to creating a new address type ? Cheers, M On 24/08/2011, at 19:57, Gavin Andresen wrote: > This discussion is convincing me that scheduling a blockchain split is > definitely the wrong idea at this time. We can revisit in N months, > when we've got a roadmap and nice unit tests and a bunch of > well-tested patches for fixing all of the things that aught to be > fixed when we DO decide a blockchain split is necessary. >=20 > There seems to be rough consensus that new, imperfect standard > transactions are a good-enough short term solution. >=20 > --=20 > -- > Gavin Andresen >=20 > = --------------------------------------------------------------------------= ---- > EMC VNX: the world's simplest storage, starting under $10K > The only unified storage solution that offers unified management=20 > Up to 160% more powerful than alternatives and 25% more efficient.=20 > Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development Michael Gronager, PhD Owner Ceptacle / NDGF Director, NORDUnet A/S Jens Juels Gade 33 2100 Copenhagen E Mobile: +45 31 62 14 01 E-mail: gronager@ceptacle.com