From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WxgGT-0007Gi-7I for bitcoin-development@lists.sourceforge.net; Thu, 19 Jun 2014 17:36:45 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of greenmangosystems.com designates 209.85.128.176 as permitted sender) client-ip=209.85.128.176; envelope-from=drice@greenmangosystems.com; helo=mail-ve0-f176.google.com; Received: from mail-ve0-f176.google.com ([209.85.128.176]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1WxgGR-0002kP-CA for bitcoin-development@lists.sourceforge.net; Thu, 19 Jun 2014 17:36:45 +0000 Received: by mail-ve0-f176.google.com with SMTP id db12so2599443veb.21 for ; Thu, 19 Jun 2014 10:36:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=2/BmW19mDy/+9ggBdEh3sc+CqvBgQmTO67PraHBXsVE=; b=Ge0S1jQnEywNApWiTH4ZPJ7s79wJIph7MQUkDOhRHSEULrZE6B+IVTuiHAmReTCaWx /7Bn7sqGJiRu7YYErZ+OyUEpJrzw2OcBMSlFgK1cMAW5xxoMW35ocTbGNuxWQLhIKcGQ Hu2sV/pV5QLH09l6KTYFqF8+pf+XcjVQA+pMVb9DfZ13+1SfbJHf+sr35vbBRXqsXySB 9aCtY/u6Upirx50EgBkvLXuhlfOMDlbDR/ozes66HOqxRhbLXjy1Hdm1aZr4ysfO0jVQ f8H8jzUDyES98J2zhMVc83bM5w2O4Snm9MQUFybhzALDzEwLk/Ebq5NltUps4AgmM8dO BlBA== X-Gm-Message-State: ALoCoQnjpjy/edkvkLPfU3SoAMWeOcdgEDUeIedyomf6VE/sbRsS2oNi7KAKmrt7n+AOSCuOinkm MIME-Version: 1.0 X-Received: by 10.52.191.68 with SMTP id gw4mr1311479vdc.65.1403199397140; Thu, 19 Jun 2014 10:36:37 -0700 (PDT) Received: by 10.58.123.35 with HTTP; Thu, 19 Jun 2014 10:36:36 -0700 (PDT) In-Reply-To: References: Date: Thu, 19 Jun 2014 10:36:36 -0700 Message-ID: From: Daniel Rice To: Mike Hearn Content-Type: multipart/alternative; boundary=089e013a219c9db10004fc33d139 X-Spam-Score: -0.6 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1WxgGR-0002kP-CA Cc: Bitcoin Dev , Lawrence Nahum Subject: Re: [Bitcoin-development] instant confirmation via payment protocol backwards compatible proto buffer extension 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, 19 Jun 2014 17:36:45 -0000 --089e013a219c9db10004fc33d139 Content-Type: text/plain; charset=UTF-8 > Supporting it in the protocol is easy. Building such a thing: that's hard. Decentralised automated reputation systems are complex and subtle. Bitcoin is valuable as a protocol because it is truly decentralized. The complexity involved in building this system was expansive, but I think we can all agree it was worth the trouble. With this particular topic of instant transactions it seems we have to be very careful about pushing Bitcoin in a centralized direction for the sake of a simple quick solution. Building an automated system to solve the instant transaction problem will be difficult, but also well worth the effort, and exactly like you're saying Mike, I just want to make sure the door is left open protocol wise for a robust solution in the future. On Wed, Jun 18, 2014 at 9:09 AM, Mike Hearn wrote: > I think that's true if you assume that the instant provider list is based >> on a by hand created list of accepted instant providers. That's how VISA >> works now and that's why I was asking for an approach where the >> trusted_instant_providers list is scalable because that seems very >> dangerous. >> > > Supporting it in the protocol is easy. Building such a thing: that's hard. > Decentralised automated reputation systems are complex and subtle. > > I don't feel strongly about whether the field should be "optional" or > "repeated", 100% of implementations in the forseeable future would just > look at the first item and ignore the rest. But if later someone did crack > this problem it would lead to a simple upgrade path. So perhaps you're > right and the protobuf should allow multiple signatures. It means a new > sub-message to wrap the pki_type, pki_data and signature fields into one, > and then making that repeated. > > Up to Lawrence. > --089e013a219c9db10004fc33d139 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
>=C2=A0Supporting it in the protocol is easy. Building such a thing: t= hat's hard. Decentralised automated reputation systems are complex and = subtle.=C2=A0

Bitcoin is valuable as a protocol b= ecause it is truly decentralized. The complexity involved in building this = system was expansive, but I think we can all agree it was worth the trouble= . With this particular topic of instant transactions it seems we have to be= very careful about pushing Bitcoin in a centralized direction for the sake= of a simple quick solution. Building an automated system to solve the inst= ant transaction problem will be difficult, but also well worth the effort, = and exactly like you're saying Mike, I just want to make sure the door = is left open protocol wise for a robust solution in the future.


On Wed,= Jun 18, 2014 at 9:09 AM, Mike Hearn <mike@plan99.net> wrote:<= br>
I think that's true if you assume that the insta= nt provider list is based on a by hand created list of accepted instant pro= viders. That's how VISA works now and that's why I was asking for a= n approach where the trusted_instant_providers list is scalable because tha= t seems very dangerous.

Supporting it in the protocol = is easy. Building such a thing: that's hard. Decentralised automated re= putation systems are complex and subtle.=C2=A0

I d= on't feel strongly about whether the field should be "optional&quo= t; or "repeated", 100% of implementations in the forseeable futur= e would just look at the first item and ignore the rest. But if later someo= ne did crack this problem it would lead to a simple upgrade path. So perhap= s you're right and the protobuf should allow multiple signatures. It me= ans a new sub-message to wrap the pki_type, pki_data and signature fields i= nto one, and then making that repeated.

Up to Lawrence.

--089e013a219c9db10004fc33d139--