path: root/04/fa8ceebe5a13cec53ec947cda6bfa72916db87

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 <dgomez1092@gmail.com>) id 1YqqWQ-0000OC-5Q
	for bitcoin-development@lists.sourceforge.net;
	Fri, 08 May 2015 22:13:30 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
	designates 74.125.82.52 as permitted sender)
	client-ip=74.125.82.52; envelope-from=dgomez1092@gmail.com;
	helo=mail-wg0-f52.google.com; 
Received: from mail-wg0-f52.google.com ([74.125.82.52])
	by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1YqqWN-0003Bj-If
	for bitcoin-development@lists.sourceforge.net;
	Fri, 08 May 2015 22:13:30 +0000
Received: by wgic8 with SMTP id c8so57481649wgi.1
	for <bitcoin-development@lists.sourceforge.net>;
	Fri, 08 May 2015 15:13:21 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.180.99.39 with SMTP id en7mr1599459wib.31.1431123201587;
	Fri, 08 May 2015 15:13:21 -0700 (PDT)
Received: by 10.28.144.68 with HTTP; Fri, 8 May 2015 15:13:21 -0700 (PDT)
In-Reply-To: <CAH+jCTwxjfEVog4JR+8kCvbBPoT50f322NV3T+8Bz-sTnK-yXQ@mail.gmail.com>
References: <mailman.63969.1431119326.18600.bitcoin-development@lists.sourceforge.net>
	<CAH+jCTye9QNVV8bv6ZAgEPcrE5K1J-q7gONE_m1x81+-5mpWHA@mail.gmail.com>
	<CAH+jCTwxjfEVog4JR+8kCvbBPoT50f322NV3T+8Bz-sTnK-yXQ@mail.gmail.com>
Date: Fri, 8 May 2015 15:13:21 -0700
Message-ID: <CAH+jCTxYnT+oOmxXRF-dA8F02wVMZ-en2HW1cs2+Kn290j6T3Q@mail.gmail.com>
From: Damian Gomez <dgomez1092@gmail.com>
To: bitcoin-development@lists.sourceforge.net
Content-Type: multipart/alternative; boundary=f46d041828080f830f051599565e
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: 1YqqWN-0003Bj-If
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:30 -0000

--f46d041828080f830f051599565e
Content-Type: text/plain; charset=UTF-8

On Fri, May 8, 2015 at 3:12 PM, Damian Gomez <dgomez1092@gmail.com> wrote:

> 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
>>>
>>>
>>
>

--f46d041828080f830f051599565e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><br></div><div><br></div></div><div class=3D"gmail_ex=
tra"><br><div class=3D"gmail_quote">On Fri, May 8, 2015 at 3:12 PM, Damian =
Gomez <span dir=3D"ltr">&lt;<a href=3D"mailto:dgomez1092@gmail.com" target=
=3D"_blank">dgomez1092@gmail.com</a>&gt;</span> wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><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 class=3D"HOEnZb"><div class=3D"h5"><div class=3D"gmail_extra"><=
br><div class=3D"gmail_quote">On Fri, May 8, 2015 at 3:11 PM, Damian Gomez =
<span dir=3D"ltr">&lt;<a href=3D"mailto:dgomez1092@gmail.com" target=3D"_bl=
ank">dgomez1092@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gma=
il_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-lef=
t:1ex"><div dir=3D"ltr"><br><div>Well zombie txns aside, =C2=A0I expect thi=
s to be resolved w/ a client side implementation using a Merkle-Winternitz =
OTS in order to prevent the loss of fee structure theougth the implementati=
on of a this security hash that eill alloow for a one-wya transaction to co=
nitnue, according to the TESLA protocol. =C2=A0</div><div><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 discussin the construcitons=
 of a a DH key (instead of the BIP X509 protocol) =C2=A0</div><div><br></di=
v><div><br></div><div><br></div><div><br></div><div class=3D"gmail_extra"><=
br><div class=3D"gmail_quote"><div><div>On Fri, May 8, 2015 at 2:08 PM,  <s=
pan dir=3D"ltr">&lt;<a href=3D"mailto:bitcoin-development-request@lists.sou=
rceforge.net" target=3D"_blank">bitcoin-development-request@lists.sourcefor=
ge.net</a>&gt;</span> wrote:<br></div></div><blockquote class=3D"gmail_quot=
e" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">=
<div><div>Send Bitcoin-development 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 &#39;help&#39; 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 &quot;Re: Contents of Bitcoin-development digest...&quot;<br>
<br></div></div>Today&#39;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 &lt;<a href=3D"mailto:mark@friedenbach.org" target=3D"_blank">mark@frie=
denbach.org</a>&gt;<br>To:=C2=A0Raystonn &lt;<a href=3D"mailto:raystonn@hot=
mail.com" target=3D"_blank">raystonn@hotmail.com</a>&gt;<br>Cc:=C2=A0Bitcoi=
n Development &lt;<a href=3D"mailto:bitcoin-development@lists.sourceforge.n=
et" target=3D"_blank">bitcoin-development@lists.sourceforge.net</a>&gt;<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">&lt;<a href=3D"mailto:raystonn@hotmail.com" target=3D"_blank"=
>raystonn@hotmail.com</a>&gt;</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=
 &lt;<a href=3D"mailto:doug@bitcoinarmory.com" target=3D"_blank">doug@bitco=
inarmory.com</a>&gt;<br>To:=C2=A0Bitcoin Dev &lt;<a href=3D"mailto:bitcoin-=
development@lists.sourceforge.net" target=3D"_blank">bitcoin-development@li=
sts.sourceforge.net</a>&gt;<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&#39;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&#39;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&#39;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 &lt;<a href=3D"mailto:mark@friedenbach.org" target=3D"_blank">mark@frie=
denbach.org</a>&gt;<br>To:=C2=A0&quot;Raystonn .&quot; &lt;<a href=3D"mailt=
o:raystonn@hotmail.com" target=3D"_blank">raystonn@hotmail.com</a>&gt;<br>C=
c:=C2=A0Bitcoin Development &lt;<a href=3D"mailto:bitcoin-development@lists=
.sourceforge.net" target=3D"_blank">bitcoin-development@lists.sourceforge.n=
et</a>&gt;<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&#39;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">&lt;<a href=3D"mailto:raystonn@hotmail.com" =
target=3D"_blank">raystonn@hotmail.com</a>&gt;</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 &lt;<a href=
=3D"mailto:voisine@gmail.com" target=3D"_blank">voisine@gmail.com</a>&gt; 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&#39;s 20M=
b block proposal.<div><br></div><div>The best argument I&#39;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&#39; 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 =
&lt;<a href=3D"mailto:dgomez1092@gmail.com" target=3D"_blank">dgomez1092@gm=
ail.com</a>&gt;<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&#39;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&#39;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 ---&gt; 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 &lt;=
<a href=3D"mailto:raystonn@hotmail.com" target=3D"_blank">raystonn@hotmail.=
com</a>&gt;<br>To:=C2=A0Mark Friedenbach &lt;<a href=3D"mailto:mark@frieden=
bach.org" target=3D"_blank">mark@friedenbach.org</a>&gt;<br>Cc:=C2=A0Bitcoi=
n Development &lt;<a href=3D"mailto:bitcoin-development@lists.sourceforge.n=
et" target=3D"_blank">bitcoin-development@lists.sourceforge.net</a>&gt;<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 &lt;<a h=
ref=3D"mailto:mark@friedenbach.org" target=3D"_blank">mark@friedenbach.org<=
/a>&gt; 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">&lt;<a href=3D"=
mailto:raystonn@hotmail.com" target=3D"_blank">raystonn@hotmail.com</a>&gt;=
</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>
</div></div></blockquote></div><br></div>

--f46d041828080f830f051599565e--