Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from <dgomez1092@gmail.com>) id 1YqqW1-0002Qu-Sp for bitcoin-development@lists.sourceforge.net; Fri, 08 May 2015 22:13:05 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.212.174 as permitted sender) client-ip=209.85.212.174; envelope-from=dgomez1092@gmail.com; helo=mail-wi0-f174.google.com; Received: from mail-wi0-f174.google.com ([209.85.212.174]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1YqqVy-0007mv-P4 for bitcoin-development@lists.sourceforge.net; Fri, 08 May 2015 22:13:05 +0000 Received: by wizk4 with SMTP id k4so45052175wiz.1 for <bitcoin-development@lists.sourceforge.net>; Fri, 08 May 2015 15:12:56 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.89.231 with SMTP id br7mr1647068wib.60.1431123176758; Fri, 08 May 2015 15:12:56 -0700 (PDT) Received: by 10.28.144.68 with HTTP; Fri, 8 May 2015 15:12:56 -0700 (PDT) In-Reply-To: <CAH+jCTye9QNVV8bv6ZAgEPcrE5K1J-q7gONE_m1x81+-5mpWHA@mail.gmail.com> References: <mailman.63969.1431119326.18600.bitcoin-development@lists.sourceforge.net> <CAH+jCTye9QNVV8bv6ZAgEPcrE5K1J-q7gONE_m1x81+-5mpWHA@mail.gmail.com> Date: Fri, 8 May 2015 15:12:56 -0700 Message-ID: <CAH+jCTwxjfEVog4JR+8kCvbBPoT50f322NV3T+8Bz-sTnK-yXQ@mail.gmail.com> From: Damian Gomez <dgomez1092@gmail.com> To: bitcoin-development@lists.sourceforge.net Content-Type: multipart/alternative; boundary=e89a8f3ba25594a14605159954a7 X-Spam-Score: -0.3 (/) 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 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (dgomez1092[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 0.2 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends in digit (dgomez1092[at]gmail.com) 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: 1YqqVy-0007mv-P4 Subject: Re: [Bitcoin-development] Bitcoin-development Digest, Vol 48, Issue 41 X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: <bitcoin-development.lists.sourceforge.net> List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, <mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe> List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development> List-Post: <mailto:bitcoin-development@lists.sourceforge.net> List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help> List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, <mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe> X-List-Received-Date: Fri, 08 May 2015 22:13:05 -0000 --e89a8f3ba25594a14605159954a7 Content-Type: text/plain; charset=UTF-8 let me continue my conversation: as the development of this transactions would be indiscated as a ByteArray of On Fri, May 8, 2015 at 3:11 PM, Damian Gomez <dgomez1092@gmail.com> wrote: > > Well zombie txns aside, I expect this to be resolved w/ a client side > implementation using a Merkle-Winternitz OTS in order to prevent the loss > of fee structure theougth the implementation of a this security hash that > eill alloow for a one-wya transaction to conitnue, according to the TESLA > protocol. > > We can then tally what is needed to compute tteh number of bit desginated > for teh completion og the client-side signature if discussin the > construcitons of a a DH key (instead of the BIP X509 protocol) > > > > > > On Fri, May 8, 2015 at 2:08 PM, < > bitcoin-development-request@lists.sourceforge.net> wrote: > >> Send Bitcoin-development mailing list submissions to >> bitcoin-development@lists.sourceforge.net >> >> To subscribe or unsubscribe via the World Wide Web, visit >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development >> or, via email, send a message with subject or body 'help' to >> bitcoin-development-request@lists.sourceforge.net >> >> You can reach the person managing the list at >> bitcoin-development-owner@lists.sourceforge.net >> >> When replying, please edit your Subject line so it is more specific >> than "Re: Contents of Bitcoin-development digest..." >> >> Today's Topics: >> >> 1. Re: Block Size Increase (Mark Friedenbach) >> 2. Softfork signaling improvements (Douglas Roark) >> 3. Re: Block Size Increase (Mark Friedenbach) >> 4. Re: Block Size Increase (Raystonn) (Damian Gomez) >> 5. Re: Block Size Increase (Raystonn) >> >> >> ---------- Forwarded message ---------- >> From: Mark Friedenbach <mark@friedenbach.org> >> To: Raystonn <raystonn@hotmail.com> >> Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net> >> Date: Fri, 8 May 2015 13:55:30 -0700 >> Subject: Re: [Bitcoin-development] Block Size Increase >> The problems with that are larger than time being unreliable. It is no >> longer reorg-safe as transactions can expire in the course of a reorg and >> any transaction built on the now expired transaction is invalidated. >> >> On Fri, May 8, 2015 at 1:51 PM, Raystonn <raystonn@hotmail.com> wrote: >> >>> Replace by fee is what I was referencing. End-users interpret the old >>> transaction as expired. Hence the nomenclature. An alternative is a new >>> feature that operates in the reverse of time lock, expiring a transaction >>> after a specific time. But time is a bit unreliable in the blockchain >>> >> >> >> ---------- Forwarded message ---------- >> From: Douglas Roark <doug@bitcoinarmory.com> >> To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net> >> Cc: >> Date: Fri, 8 May 2015 15:27:26 -0400 >> Subject: [Bitcoin-development] Softfork signaling improvements >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA512 >> >> Hello. I've seen Greg make a couple of posts online >> (https://bitcointalk.org/index.php?topic=1033396.msg11155302#msg11155302 >> is one such example) where he has mentioned that Pieter has a new >> proposal for allowing multiple softforks to be deployed at the same >> time. As discussed in the thread I linked, the idea seems simple >> enough. Still, I'm curious if the actual proposal has been posted >> anywhere. I spent a few minutes searching the usual suspects (this >> mailing list, Reddit, Bitcointalk, IRC logs, BIPs) and can't find >> anything. >> >> Thanks. >> >> - --- >> Douglas Roark >> Senior Developer >> Armory Technologies, Inc. >> doug@bitcoinarmory.com >> PGP key ID: 92ADC0D7 >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG/MacGPG2 v2.0.22 (Darwin) >> Comment: GPGTools - https://gpgtools.org >> >> iQIcBAEBCgAGBQJVTQ4eAAoJEGybVGGSrcDX8eMQAOQiDA7an+qZBqDfVIwEzY2C >> SxOVxswwxAyTtZNM/Nm+8MTq77hF8+3j/C3bUbDW6wCu4QxBYA/uiCGTf44dj6WX >> 7aiXg1o9C4LfPcuUngcMI0H5ixOUxnbqUdmpNdoIvy4did2dVs9fAmOPEoSVUm72 >> 6dMLGrtlPN0jcLX6pJd12Dy3laKxd0AP72wi6SivH6i8v8rLb940EuBS3hIkuZG0 >> vnR5MXMIEd0rkWesr8hn6oTs/k8t4zgts7cgIrA7rU3wJq0qaHBa8uASUxwHKDjD >> KmDwaigvOGN6XqitqokCUlqjoxvwpimCjb3Uv5Pkxn8+dwue9F/IggRXUSuifJRn >> UEZT2F8fwhiluldz3sRaNtLOpCoKfPC+YYv7kvGySgqagtNJFHoFhbeQM0S3yjRn >> Ceh1xK9sOjrxw/my0jwpjJkqlhvQtVG15OsNWDzZ+eWa56kghnSgLkFO+T4G6IxB >> EUOcAYjJkLbg5ssjgyhvDOvGqft+2e4MNlB01e1ZQr4whQH4TdRkd66A4WDNB+0g >> LBqVhAc2C8L3g046mhZmC33SuOSxxm8shlxZvYLHU2HrnUFg9NkkXi1Ub7agMSck >> TTkLbMx17AvOXkKH0v1L20kWoWAp9LfRGdD+qnY8svJkaUuVtgDurpcwEk40WwEZ >> caYBw+8bdLpKZwqbA1DL >> =ayhE >> -----END PGP SIGNATURE----- >> >> >> >> >> ---------- Forwarded message ---------- >> From: Mark Friedenbach <mark@friedenbach.org> >> To: "Raystonn ." <raystonn@hotmail.com> >> Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net> >> Date: Fri, 8 May 2015 13:40:50 -0700 >> Subject: Re: [Bitcoin-development] Block Size Increase >> Transactions don't expire. But if the wallet is online, it can >> periodically choose to release an already created transaction with a higher >> fee. This requires replace-by-fee to be sufficiently deployed, however. >> >> On Fri, May 8, 2015 at 1:38 PM, Raystonn . <raystonn@hotmail.com> wrote: >> >>> I have a proposal for wallets such as yours. How about creating all >>> transactions with an expiration time starting with a low fee, then >>> replacing with new transactions that have a higher fee as time passes. >>> Users can pick the fee curve they desire based on the transaction priority >>> they want to advertise to the network. Users set the priority in the >>> wallet, and the wallet software translates it to a specific fee curve used >>> in the series of expiring transactions. In this manner, transactions are >>> never left hanging for days, and probably not even for hours. >>> >>> -Raystonn >>> On 8 May 2015 1:17 pm, Aaron Voisine <voisine@gmail.com> wrote: >>> >>> As the author of a popular SPV wallet, I wanted to weigh in, in support >>> of the Gavin's 20Mb block proposal. >>> >>> The best argument I've heard against raising the limit is that we need >>> fee pressure. I agree that fee pressure is the right way to economize on >>> scarce resources. Placing hard limits on block size however is an >>> incredibly disruptive way to go about this, and will severely negatively >>> impact users' experience. >>> >>> When users pay too low a fee, they should: >>> >>> 1) See immediate failure as they do now with fees that fail to propagate. >>> >>> 2) If the fee lower than it should be but not terminal, they should see >>> degraded performance, long delays in confirmation, but eventual success. >>> This will encourage them to pay higher fees in future. >>> >>> The worst of all worlds would be to have transactions propagate, hang in >>> limbo for days, and then fail. This is the most important scenario to >>> avoid. Increasing the 1Mb block size limit I think is the simplest way to >>> avoid this least desirable scenario for the immediate future. >>> >>> We can play around with improved transaction selection for blocks and >>> encourage miners to adopt it to discourage low fees and create fee >>> pressure. These could involve hybrid priority/fee selection so low fee >>> transactions see degraded performance instead of failure. This would be the >>> conservative low risk approach. >>> >>> Aaron Voisine >>> co-founder and CEO >>> breadwallet.com >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> One dashboard for servers and applications across Physical-Virtual-Cloud >>> Widest out-of-the-box monitoring support with 50+ applications >>> Performance metrics, stats and reports that give you Actionable Insights >>> Deep dive visibility with transaction tracing using APM Insight. >>> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y >>> _______________________________________________ >>> Bitcoin-development mailing list >>> Bitcoin-development@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development >>> >>> >> >> >> ---------- Forwarded message ---------- >> From: Damian Gomez <dgomez1092@gmail.com> >> To: bitcoin-development@lists.sourceforge.net >> Cc: >> Date: Fri, 8 May 2015 14:04:10 -0700 >> Subject: Re: [Bitcoin-development] Block Size Increase (Raystonn) >> Hello, >> >> I was reading some of the thread but can't say I read the entire thing. >> >> I think that it is realistic to cinsider a nlock sixe of 20MB for any >> block txn to occur. THis is an enormous amount of data (relatively for a >> netwkrk) in which the avergage rate of 10tps over 10 miniutes would allow >> for fewasible transformation of data at this curent point in time. >> >> Though I do not see what extra hash information would be stored in the >> overall ecosystem as we begin to describe what the scripts that are >> atacrhed tp the blockchain would carry, >> >> I'd therefore think that for the remainder of this year that it is >> possible to have a block chain within 200 - 300 bytes that is more >> charatereistic of some feasible attempts at attaching nuanced data in order >> to keep propliifc the blockchain but have these identifiers be integral >> OPSIg of the the entiore block. THe reasoning behind this has to do with >> encryption standards that can be added toe a chain such as th DH algoritnm >> keys that would allow for a higher integrity level withinin the system as >> it is. Cutrent;y tyh prootocl oomnly controls for the amount of >> transactions through if TxnOut script and the publin key coming form teh >> lcoation of the proof-of-work. Form this then I think that a rate of higher >> than then current standard of 92bytes allows for GPUS ie CUDA to perfirm >> its standard operations of 1216 flops in rde rto mechanize a new >> personal identity within the chain that also attaches an encrypted instance >> of a further categorical variable that we can prsribved to it. >> >> I think with the current BIP7 prootclol for transactions there is an area >> of vulnerability for man-in-the-middle attacks upon request of bitcin to >> any merchant as is. It would contraidct the security of the bitcoin if it >> was intereceptefd iand not allowed to reach tthe payment network or if the >> hash was reveresed in orfr to change the value it had. Therefore the >> current best fit block size today is between 200 - 300 bytws (depending on >> how exciteed we get) >> >> >> >> Thanks for letting me join the conversation >> I welcomes any vhalleneged and will reply with more research as i figure >> out what problems are revealed in my current formation of thoughts (sorry >> for the errors but i am just trying to move forward ---> THE DELRERT KEY >> LITERALLY PREVENTS IT ) >> >> >> _Damian >> >> >> ---------- Forwarded message ---------- >> From: Raystonn <raystonn@hotmail.com> >> To: Mark Friedenbach <mark@friedenbach.org> >> Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net> >> Date: Fri, 8 May 2015 14:01:28 -0700 >> Subject: Re: [Bitcoin-development] Block Size Increase >> >> Replace by fee is the better approach. It will ultimately replace zombie >> transactions (due to insufficient fee) with potentially much higher fees as >> the feature takes hold in wallets throughout the network, and fee >> competition increases. However, this does not fix the problem of low tps. >> In fact, as blocks fill it could make the problem worse. This feature >> means more transactions after all. So I would expect huge fee spikes, or a >> return to zombie transactions if fee caps are implemented by wallets. >> >> -Raystonn >> On 8 May 2015 1:55 pm, Mark Friedenbach <mark@friedenbach.org> wrote: >> >> The problems with that are larger than time being unreliable. It is no >> longer reorg-safe as transactions can expire in the course of a reorg and >> any transaction built on the now expired transaction is invalidated. >> >> On Fri, May 8, 2015 at 1:51 PM, Raystonn <raystonn@hotmail.com> wrote: >> >> Replace by fee is what I was referencing. End-users interpret the old >> transaction as expired. Hence the nomenclature. An alternative is a new >> feature that operates in the reverse of time lock, expiring a transaction >> after a specific time. But time is a bit unreliable in the blockchain >> >> >> >> ------------------------------------------------------------------------------ >> One dashboard for servers and applications across Physical-Virtual-Cloud >> Widest out-of-the-box monitoring support with 50+ applications >> Performance metrics, stats and reports that give you Actionable Insights >> Deep dive visibility with transaction tracing using APM Insight. >> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y >> _______________________________________________ >> Bitcoin-development mailing list >> Bitcoin-development@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development >> >> > --e89a8f3ba25594a14605159954a7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">let me continue my conversation:=C2=A0<div><br></div><div>= as the development of this transactions would be indiscated=C2=A0</div><div= ><br></div><div>as a ByteArray of=C2=A0</div><div><br></div></div><div clas= s=3D"gmail_extra"><br><div class=3D"gmail_quote">On Fri, May 8, 2015 at 3:1= 1 PM, Damian Gomez <span dir=3D"ltr"><<a href=3D"mailto:dgomez1092@gmail= .com" target=3D"_blank">dgomez1092@gmail.com</a>></span> wrote:<br><bloc= kquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #cc= c solid;padding-left:1ex"><div dir=3D"ltr"><br><div>Well zombie txns aside,= =C2=A0I expect this to be resolved w/ a client side implementation using a= Merkle-Winternitz OTS in order to prevent the loss of fee structure theoug= th the implementation of a this security hash that eill alloow for a one-wy= a transaction to conitnue, according to the TESLA protocol. =C2=A0</div><di= v><br></div><div>We can then tally what is needed to compute tteh number of= bit desginated for teh completion og the client-side signature if discussi= n the construcitons of a a DH key (instead of the BIP X509 protocol) =C2=A0= </div><div><br></div><div><br></div><div><br></div><div><br></div><div clas= s=3D"gmail_extra"><br><div class=3D"gmail_quote"><div><div class=3D"h5">On = Fri, May 8, 2015 at 2:08 PM, <span dir=3D"ltr"><<a href=3D"mailto:bitco= in-development-request@lists.sourceforge.net" target=3D"_blank">bitcoin-dev= elopment-request@lists.sourceforge.net</a>></span> wrote:<br></div></div= ><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1= px #ccc solid;padding-left:1ex"><div><div class=3D"h5">Send Bitcoin-develop= ment mailing list submissions to<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 <a href=3D"mailto:bitcoin-development@lists.sou= rceforge.net" target=3D"_blank">bitcoin-development@lists.sourceforge.net</= a><br> <br> To subscribe or unsubscribe via the World Wide Web, visit<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 <a href=3D"https://lists.sourceforge.net/lists/= listinfo/bitcoin-development" target=3D"_blank">https://lists.sourceforge.n= et/lists/listinfo/bitcoin-development</a><br> or, via email, send a message with subject or body 'help' to<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 <a href=3D"mailto:bitcoin-development-request@l= ists.sourceforge.net" target=3D"_blank">bitcoin-development-request@lists.s= ourceforge.net</a><br> <br> You can reach the person managing the list at<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 <a href=3D"mailto:bitcoin-development-owner@lis= ts.sourceforge.net" target=3D"_blank">bitcoin-development-owner@lists.sourc= eforge.net</a><br> <br> When replying, please edit your Subject line so it is more specific<br> than "Re: Contents of Bitcoin-development digest..."<br> <br></div></div>Today's Topics:<br> <br> =C2=A0 =C2=A01. Re: Block Size Increase (Mark Friedenbach)<br> =C2=A0 =C2=A02. Softfork signaling improvements (Douglas Roark)<br> =C2=A0 =C2=A03. Re: Block Size Increase (Mark Friedenbach)<br> =C2=A0 =C2=A04. Re: Block Size Increase (Raystonn) (Damian Gomez)<br> =C2=A0 =C2=A05. Re: Block Size Increase (Raystonn)<br> <br><br>---------- Forwarded message ----------<br>From:=C2=A0Mark Friedenb= ach <<a href=3D"mailto:mark@friedenbach.org" target=3D"_blank">mark@frie= denbach.org</a>><br>To:=C2=A0Raystonn <<a href=3D"mailto:raystonn@hot= mail.com" target=3D"_blank">raystonn@hotmail.com</a>><br>Cc:=C2=A0Bitcoi= n Development <<a href=3D"mailto:bitcoin-development@lists.sourceforge.n= et" target=3D"_blank">bitcoin-development@lists.sourceforge.net</a>><br>= Date:=C2=A0Fri, 8 May 2015 13:55:30 -0700<br>Subject:=C2=A0Re: [Bitcoin-dev= elopment] Block Size Increase<br><div dir=3D"ltr">The problems with that ar= e larger than time being unreliable. It is no longer reorg-safe as transact= ions can expire in the course of a reorg and any transaction built on the n= ow expired transaction is invalidated.<br><div><div class=3D"gmail_extra"><= br><div class=3D"gmail_quote">On Fri, May 8, 2015 at 1:51 PM, Raystonn <spa= n dir=3D"ltr"><<a href=3D"mailto:raystonn@hotmail.com" target=3D"_blank"= >raystonn@hotmail.com</a>></span> wrote:<br><blockquote class=3D"gmail_q= uote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1e= x">Replace by fee is what I was referencing.=C2=A0 End-users interpret the = old transaction as expired.=C2=A0 Hence the nomenclature.=C2=A0 An alternat= ive is a new feature that operates in the reverse of time lock, expiring a = transaction after a specific time.=C2=A0 But time is a bit unreliable in th= e blockchain<br></blockquote></div></div></div></div> <br><br>---------- Forwarded message ----------<br>From:=C2=A0Douglas Roark= <<a href=3D"mailto:doug@bitcoinarmory.com" target=3D"_blank">doug@bitco= inarmory.com</a>><br>To:=C2=A0Bitcoin Dev <<a href=3D"mailto:bitcoin-= development@lists.sourceforge.net" target=3D"_blank">bitcoin-development@li= sts.sourceforge.net</a>><br>Cc:=C2=A0<br>Date:=C2=A0Fri, 8 May 2015 15:2= 7:26 -0400<br>Subject:=C2=A0[Bitcoin-development] Softfork signaling improv= ements<br>-----BEGIN PGP SIGNED MESSAGE-----<br> Hash: SHA512<br> <br> Hello. I've seen Greg make a couple of posts online<br> (<a href=3D"https://bitcointalk.org/index.php?topic=3D1033396.msg11155302#m= sg11155302" target=3D"_blank">https://bitcointalk.org/index.php?topic=3D103= 3396.msg11155302#msg11155302</a><br> is one such example) where he has mentioned that Pieter has a new<br> proposal for allowing multiple softforks to be deployed at the same<br> time. As discussed in the thread I linked, the idea seems simple<br> enough. Still, I'm curious if the actual proposal has been posted<br> anywhere. I spent a few minutes searching the usual suspects (this<br> mailing list, Reddit, Bitcointalk, IRC logs, BIPs) and can't find<br> anything.<br> <br> Thanks.<br> <br> - ---<br> Douglas Roark<br> Senior Developer<br> Armory Technologies, Inc.<br> <a href=3D"mailto:doug@bitcoinarmory.com" target=3D"_blank">doug@bitcoinarm= ory.com</a><br> PGP key ID: 92ADC0D7<br> -----BEGIN PGP SIGNATURE-----<br> Version: GnuPG/MacGPG2 v2.0.22 (Darwin)<br> Comment: GPGTools - <a href=3D"https://gpgtools.org" target=3D"_blank">http= s://gpgtools.org</a><br> <br> iQIcBAEBCgAGBQJVTQ4eAAoJEGybVGGSrcDX8eMQAOQiDA7an+qZBqDfVIwEzY2C<br> SxOVxswwxAyTtZNM/Nm+8MTq77hF8+3j/C3bUbDW6wCu4QxBYA/uiCGTf44dj6WX<br> 7aiXg1o9C4LfPcuUngcMI0H5ixOUxnbqUdmpNdoIvy4did2dVs9fAmOPEoSVUm72<br> 6dMLGrtlPN0jcLX6pJd12Dy3laKxd0AP72wi6SivH6i8v8rLb940EuBS3hIkuZG0<br> vnR5MXMIEd0rkWesr8hn6oTs/k8t4zgts7cgIrA7rU3wJq0qaHBa8uASUxwHKDjD<br> KmDwaigvOGN6XqitqokCUlqjoxvwpimCjb3Uv5Pkxn8+dwue9F/IggRXUSuifJRn<br> UEZT2F8fwhiluldz3sRaNtLOpCoKfPC+YYv7kvGySgqagtNJFHoFhbeQM0S3yjRn<br> Ceh1xK9sOjrxw/my0jwpjJkqlhvQtVG15OsNWDzZ+eWa56kghnSgLkFO+T4G6IxB<br> EUOcAYjJkLbg5ssjgyhvDOvGqft+2e4MNlB01e1ZQr4whQH4TdRkd66A4WDNB+0g<br> LBqVhAc2C8L3g046mhZmC33SuOSxxm8shlxZvYLHU2HrnUFg9NkkXi1Ub7agMSck<br> TTkLbMx17AvOXkKH0v1L20kWoWAp9LfRGdD+qnY8svJkaUuVtgDurpcwEk40WwEZ<br> caYBw+8bdLpKZwqbA1DL<br> =3DayhE<br> -----END PGP SIGNATURE-----<br> <br> <br> <br><br>---------- Forwarded message ----------<br>From:=C2=A0Mark Friedenb= ach <<a href=3D"mailto:mark@friedenbach.org" target=3D"_blank">mark@frie= denbach.org</a>><br>To:=C2=A0"Raystonn ." <<a href=3D"mailt= o:raystonn@hotmail.com" target=3D"_blank">raystonn@hotmail.com</a>><br>C= c:=C2=A0Bitcoin Development <<a href=3D"mailto:bitcoin-development@lists= .sourceforge.net" target=3D"_blank">bitcoin-development@lists.sourceforge.n= et</a>><br>Date:=C2=A0Fri, 8 May 2015 13:40:50 -0700<br>Subject:=C2=A0Re= : [Bitcoin-development] Block Size Increase<br><div dir=3D"ltr">Transaction= s don't expire. But if the wallet is online, it can periodically choose= to release an already created transaction with a higher fee. This requires= replace-by-fee to be sufficiently deployed, however.<br><div><div class=3D= "gmail_extra"><br><div class=3D"gmail_quote">On Fri, May 8, 2015 at 1:38 PM= , Raystonn . <span dir=3D"ltr"><<a href=3D"mailto:raystonn@hotmail.com" = target=3D"_blank">raystonn@hotmail.com</a>></span> wrote:<br><blockquote= class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc soli= d;padding-left:1ex"><p dir=3D"ltr">I have a proposal for wallets such as yo= urs.=C2=A0 How about creating all transactions with an expiration time star= ting with a low fee, then replacing with new transactions that have a highe= r fee as time passes.=C2=A0 Users can pick the fee curve they desire based = on the transaction priority they want to advertise to the network.=C2=A0 Us= ers set the priority in the wallet, and the wallet software translates it t= o a specific fee curve used in the series of expiring transactions.=C2=A0 I= n this manner, transactions are never left hanging for days, and probably n= ot even for hours.</p> <p dir=3D"ltr">-Raystonn<br> </p> <div class=3D"gmail_quote">On 8 May 2015 1:17 pm, Aaron Voisine <<a href= =3D"mailto:voisine@gmail.com" target=3D"_blank">voisine@gmail.com</a>> w= rote:<br type=3D"attribution"><blockquote style=3D"margin:0 0 0 .8ex;border= -left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">As the author of a = popular SPV wallet, I wanted to weigh in, in support of the Gavin's 20M= b block proposal.<div><br></div><div>The best argument I've heard again= st raising the limit is that we need fee pressure.=C2=A0 I agree that fee p= ressure is the right way to economize on scarce resources. Placing hard lim= its on block size however is an incredibly disruptive way to go about this,= and will severely negatively impact users' experience.<br><div><br></d= iv><div>When users pay too low a fee, they should:</div><div><br></div><div= >1) See immediate failure as they do now with fees that fail to propagate.<= /div><div><br></div><div>2) If the fee lower than it should be but not term= inal, they should see degraded performance, long delays in confirmation, bu= t eventual success. This will encourage them to pay higher fees in future.<= /div><div><br></div><div>The worst of all worlds would be to have transacti= ons propagate, hang in limbo for days, and then fail. This is the most impo= rtant scenario to avoid. Increasing the 1Mb block size limit I think is the= simplest way to avoid this least desirable scenario for the immediate futu= re.</div><div><br></div><div>We can play around with improved transaction s= election for blocks and encourage miners to adopt it to discourage low fees= and create fee pressure. These could involve hybrid priority/fee selection= so low fee transactions see degraded performance instead of failure. This = would be the conservative low risk approach.</div><div><br><div><div><div d= ir=3D"ltr"><div><div dir=3D"ltr"><div>Aaron Voisine</div><div>co-founder an= d CEO<br><a href=3D"http://breadwallet.com" target=3D"_blank">breadwallet.c= om</a></div></div></div></div></div></div></div></div></div> </blockquote></div><br>----------------------------------------------------= --------------------------<br> One dashboard for servers and applications across Physical-Virtual-Cloud<br= > Widest out-of-the-box monitoring support with 50+ applications<br> Performance metrics, stats and reports that give you Actionable Insights<br= > Deep dive visibility with transaction tracing using APM Insight.<br> <a href=3D"http://ad.doubleclick.net/ddm/clk/290420510;117567292;y" target= =3D"_blank">http://ad.doubleclick.net/ddm/clk/290420510;117567292;y</a><br>= _______________________________________________<br> Bitcoin-development mailing list<br> <a href=3D"mailto:Bitcoin-development@lists.sourceforge.net" target=3D"_bla= nk">Bitcoin-development@lists.sourceforge.net</a><br> <a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development= " target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment</a><br> <br></blockquote></div><br></div></div></div> <br><br>---------- Forwarded message ----------<br>From:=C2=A0Damian Gomez = <<a href=3D"mailto:dgomez1092@gmail.com" target=3D"_blank">dgomez1092@gm= ail.com</a>><br>To:=C2=A0<a href=3D"mailto:bitcoin-development@lists.sou= rceforge.net" target=3D"_blank">bitcoin-development@lists.sourceforge.net</= a><br>Cc:=C2=A0<br>Date:=C2=A0Fri, 8 May 2015 14:04:10 -0700<br>Subject:=C2= =A0Re: [Bitcoin-development] Block Size Increase (Raystonn)<br><div dir=3D"= ltr">Hello,=C2=A0<div><br></div><div>I was reading some of the thread but c= an't say I read the entire thing.=C2=A0</div><div><br></div><div>I thin= k that it is realistic to cinsider a nlock sixe of 20MB for any block txn t= o occur. THis is an enormous amount of data (relatively for a netwkrk) in w= hich the avergage rate of 10tps over 10 miniutes would allow for fewasible = transformation of data at this curent point in time.</div><div><br></div><d= iv>Though I do not see what extra hash information would be stored in the o= verall ecosystem as we begin to describe what the scripts that are atacrhed= tp the blockchain would carry,=C2=A0</div><div><br></div><div>I'd ther= efore think that for the remainder of this year that it is possible to have= a block chain within 200 - 300 bytes that is more charatereistic of some f= easible attempts at attaching nuanced data in order to keep propliifc the b= lockchain but have these identifiers be integral OPSIg of the the entiore b= lock. THe reasoning behind this has to do with encryption standards that ca= n be added toe a chain such as th DH algoritnm keys that would allow for a = higher integrity level withinin the system as it is. Cutrent;y tyh prootocl= oomnly controls for the amount of transactions through if TxnOut script an= d the publin key coming form teh lcoation of the proof-of-work. Form this t= hen I think that a rate of higher than then current standard of 92bytes all= ows for GPUS ie CUDA to perfirm its standard operations of =C2=A01216 flops= =C2=A0 in rde rto mechanize a new personal identity within the chain that = also attaches an encrypted instance of a further categorical variable that = we can prsribved to it.=C2=A0</div><div><br></div><div>I think with the cur= rent BIP7 prootclol for transactions there is an area of vulnerability for = man-in-the-middle attacks upon request of =C2=A0bitcin to any merchant as i= s. It would contraidct the security of the bitcoin if it was intereceptefd = iand not allowed to reach tthe payment network or if the hash was reveresed= in orfr to change the value it had. Therefore the current best fit block s= ize today is between 200 - 300 bytws (depending on how exciteed we get)</di= v><div><br></div><div><br></div><div><br></div><div>Thanks for letting me j= oin the conversation</div><div>I welcomes any vhalleneged and will reply wi= th more research as i figure out what problems are revealed in my current f= ormation of thoughts (sorry for the errors but i am just trying to move for= ward ---> THE DELRERT KEY LITERALLY PREVENTS IT )</div><div><br></div><d= iv><br></div><div>_Damian</div></div> <br><br>---------- Forwarded message ----------<br>From:=C2=A0Raystonn <= <a href=3D"mailto:raystonn@hotmail.com" target=3D"_blank">raystonn@hotmail.= com</a>><br>To:=C2=A0Mark Friedenbach <<a href=3D"mailto:mark@frieden= bach.org" target=3D"_blank">mark@friedenbach.org</a>><br>Cc:=C2=A0Bitcoi= n Development <<a href=3D"mailto:bitcoin-development@lists.sourceforge.n= et" target=3D"_blank">bitcoin-development@lists.sourceforge.net</a>><br>= Date:=C2=A0Fri, 8 May 2015 14:01:28 -0700<br>Subject:=C2=A0Re: [Bitcoin-dev= elopment] Block Size Increase<br><p dir=3D"ltr">Replace by fee is the bette= r approach.=C2=A0 It will ultimately replace zombie transactions (due to in= sufficient fee) with potentially much higher fees as the feature takes hold= in wallets throughout the network, and fee competition increases.=C2=A0 Ho= wever, this does not fix the problem of low tps.=C2=A0 In fact, as blocks f= ill it could make the problem worse.=C2=A0 This feature means more transact= ions after all.=C2=A0 So I would expect huge fee spikes, or a return to zom= bie transactions if fee caps are implemented by wallets.</p> <p dir=3D"ltr">-Raystonn<br> </p> <div class=3D"gmail_quote">On 8 May 2015 1:55 pm, Mark Friedenbach <<a h= ref=3D"mailto:mark@friedenbach.org" target=3D"_blank">mark@friedenbach.org<= /a>> wrote:<br type=3D"attribution"><blockquote style=3D"margin:0 0 0 .8= ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">The proble= ms with that are larger than time being unreliable. It is no longer reorg-s= afe as transactions can expire in the course of a reorg and any transaction= built on the now expired transaction is invalidated.<br><div><div><br><div= >On Fri, May 8, 2015 at 1:51 PM, Raystonn <span dir=3D"ltr"><<a href=3D"= mailto:raystonn@hotmail.com" target=3D"_blank">raystonn@hotmail.com</a>>= </span> wrote:<br><blockquote style=3D"margin:0 0 0 0.8ex;border-left:1px #= ccc solid;padding-left:1ex">Replace by fee is what I was referencing.=C2=A0= End-users interpret the old transaction as expired.=C2=A0 Hence the nomenc= lature.=C2=A0 An alternative is a new feature that operates in the reverse = of time lock, expiring a transaction after a specific time.=C2=A0 But time = is a bit unreliable in the blockchain<br></blockquote></div></div></div></d= iv> </blockquote></div><br>----------------------------------------------------= --------------------------<br> One dashboard for servers and applications across Physical-Virtual-Cloud<br= > Widest out-of-the-box monitoring support with 50+ applications<br> Performance metrics, stats and reports that give you Actionable Insights<br= > Deep dive visibility with transaction tracing using APM Insight.<br> <a href=3D"http://ad.doubleclick.net/ddm/clk/290420510;117567292;y" target= =3D"_blank">http://ad.doubleclick.net/ddm/clk/290420510;117567292;y</a><br>= _______________________________________________<br> Bitcoin-development mailing list<br> <a href=3D"mailto:Bitcoin-development@lists.sourceforge.net" target=3D"_bla= nk">Bitcoin-development@lists.sourceforge.net</a><br> <a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development= " target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment</a><br> <br></blockquote></div><br></div></div> </blockquote></div><br></div> --e89a8f3ba25594a14605159954a7--