From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id CB6AE7AF for ; Fri, 24 Jul 2015 01:42:18 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from st11p02im-asmtp001.me.com (st11p02im-asmtp001.me.com [17.172.220.113]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 1A07EA9 for ; Fri, 24 Jul 2015 01:42:18 +0000 (UTC) Received: from [10.52.6.2] (unknown [101.78.135.131]) by st11p02im-asmtp001.me.com (Oracle Communications Messaging Server 7.0.5.35.0 64bit (built Mar 31 2015)) with ESMTPSA id <0NRY00F2NY2DN510@st11p02im-asmtp001.me.com> for bitcoin-dev@lists.linuxfoundation.org; Fri, 24 Jul 2015 01:42:17 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151,1.0.33,0.0.0000 definitions=2015-07-24_01:2015-07-22, 2015-07-23, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1412110000 definitions=main-1507240022 Sun-Java-System-SMTP-Warning: Lines longer than SMTP allows found and wrapped. Content-type: text/plain; charset=gb2312 MIME-version: 1.0 (1.0) From: Jean-Paul Kogelman X-Mailer: iPhone Mail (12H143) In-reply-to: <0E15E07E-E21C-4541-869A-3C34CBA35774@gmail.com> Date: Fri, 24 Jul 2015 09:42:12 +0800 Content-transfer-encoding: quoted-printable Message-id: <9AC88C7C-4BA4-4DF2-913F-9DC6874BD19D@me.com> References: <55B113AF.40500@thinlink.com> <6F436293-9E2B-461C-B105-FC4CF9EBFC69@gmail.com> <42BF7FEB-320F-43BE-B3D9-1D76CB8B9975@gmai> <346D4CE0-E00D-4ABB-B131-EFA1416CB20C@me.com> <29363BE6-72A7-4D06-A974-C52BA12FD8BD@gmail.com> <55FFBC8F-A3C9-4109-89C7-AC359FBBD478@me.com> <4734381C-2000-4D9B-9099-DDE3D38D64A3@me.com> <0E15E07E-E21C-4541-869A-3C34CBA35774@gmail.com> To: Eric Lombrozo X-Spam-Status: No, score=-3.8 required=5.0 tests=BAYES_00,MIME_QP_LONG_LINE, RCVD_IN_DNSWL_LOW,RP_MATCHES_RCVD autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: Jean-Paul Kogelman via bitcoin-dev Subject: Re: [bitcoin-dev] Bitcoin Core and hard forks X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2015 01:42:18 -0000 Miners could include their fee tiers in the coinbase, but this is obviously o= pen to manipulation, with little recourse (unless they are a pool and miners= move away because of it).=20 In any event, I think that trying out a solution that is both simple and inv= olves the least number of parties necessary is preferable. Have miners set their tiers, have users select the level of quality they wan= t, ignore the block size. Miners will adapt their tiers depending on how many transactions actually en= d up in them. If for example they set the first tier to be $1 to be included= in the current block and no user chooses that level of service, they've obv= iously priced themselves out of the market. The opposite is also true; if a t= ier is popular they can choose to increase the cost of that tier. jp=20 > On Jul 24, 2015, at 9:28 AM, Eric Lombrozo wrote: >=20 > I suppose you can use a timelocked output that is spendable by anyone you c= ould go somewhat in this direction=A1=ADthe thing is it still means the wall= et must make fee estimations rather than being able to get a quick quote. >=20 >> On Jul 23, 2015, at 6:25 PM, Jean-Paul Kogelman = wrote: >>=20 >> I think implicit QoS is far simpler to implement, requires less parties a= nd is closer to what Bitcoin started out as: a peer-to-peer digital cash sys= tem, not a peer-to-let-me-handle-that-for-you-to-peer system. >>=20 >> jp >>=20 >>> On Jul 24, 2015, at 9:08 AM, Eric Lombrozo wrote: >>>=20 >>> By using third parties separate from individual miners that do bidding o= n your behalf you get a mechanism that allows QoS guarantees and shifting th= e complexity and risk from the wallet with little computational resources to= a service with abundance of them. Using timelocked contracts it=A1=AFs poss= ible to enforce the guarantees. >>>=20 >>> Negotiating directly with miners via smart contracts seems difficult at b= est. >>>=20 >>>=20 >>>> On Jul 23, 2015, at 6:03 PM, Jean-Paul Kogelman via bitcoin-dev wrote: >>>>=20 >>>> Doesn't matter. >>>>=20 >>>> It's not going to be perfect given the block time variance among other f= actors but it's far more workable than guessing whether or not your transact= ion is going to end up in a block at all. >>>>=20 >>>> jp >>>>=20 >>>>=20 >>>>> On Jul 24, 2015, at 8:53 AM, Peter Todd wrote: >>>>>=20 >>>>> -----BEGIN PGP SIGNED MESSAGE----- >>>>> Hash: SHA256 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>> On 23 July 2015 20:49:20 GMT-04:00, Jean-Paul Kogelman via bitcoin-de= v wrote: >>>>>>=20 >>>>>> And it's obvious how a size cap would interfere with such a QoS schem= e. >>>>>> Miners wouldn't be able to deliver the below guarantees if they have t= o >>>>>> start excluding transactions. >>>>>=20 >>>>> As mining is a random, poisson process, obviously giving guarantees wi= thout a majority of hashing power isn't possible. >>>>>=20 >>>>>=20 >>>>> -----BEGIN PGP SIGNATURE----- >>>>>=20 >>>>> iQE9BAEBCAAnIBxQZXRlciBUb2RkIDxwZXRlQHBldGVydG9kZC5vcmc+BQJVsYyK >>>>> AAoJEMCF8hzn9Lnc47AH/28WlecQLb37CiJpcvXO9tC4zqYEodurtB9nBHTSJrug >>>>> VIEXZW53pSTdd3vv2qpGIlHxuYP8QmDSATztwQLuN6XWEszz7TO8MXBfLxKqZyGu >>>>> i83WqSGjMAfwqjl0xR1G7PJgt4+E+0vaAFZc98vLCgZnedbiXRVtTGjhofG1jjTc >>>>> DFMwMZHP0eqWTwtWwqUvnA7PTFHxdqoJruY/t1KceN+JDbBCJWMxBDswU64FXcVH >>>>> 0ecsk9nhLMyylBX/2v4HjCXyayocH8jQ+FpLSP0xxERyS+f1npFX9cxFMq24uXqn >>>>> PcnZfLfaSJ6gMbmhbYG5wYDKN3u732j7dLzSJnMW6jk=3D >>>>> =3DLY1+ >>>>> -----END PGP SIGNATURE----- >>>> _______________________________________________ >>>> bitcoin-dev mailing list >>>> bitcoin-dev@lists.linuxfoundation.org >>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >=20