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 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 ; 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: References: Date: Fri, 8 May 2015 15:13:21 -0700 Message-ID: From: Damian Gomez 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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 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 >>> To: Raystonn >>> Cc: Bitcoin Development >>> 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 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 >>> To: Bitcoin Dev >>> 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 >>> To: "Raystonn ." >>> Cc: Bitcoin Development >>> 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 . 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 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 >>> 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 >>> To: Mark Friedenbach >>> Cc: Bitcoin Development >>> 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 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 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



On Fri, May 8, 2015 at 3:12 PM, Damian = Gomez <dgomez1092@gmail.com> wrote:
let me continue my conversation:=C2=A0
<= br>
as the development of this transactions would be indiscated= =C2=A0

as a ByteArray of=C2=A0

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

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

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




<= br>
On Fri, May 8, 2015 at 2:08 PM, <bitcoin-development-request@lists.sourcefor= ge.net> wrote:
=
Send Bitcoin-development mailing list submissions to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 bitcoin-development@lists.sourceforge.net

To subscribe or unsubscribe via the World Wide Web, visit
=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://lists.sourceforge.n= et/lists/listinfo/bitcoin-development
or, via email, send a message with subject or body 'help' to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 bitcoin-development-request@lists.s= ourceforge.net

You can reach the person managing the list at
=C2=A0 =C2=A0 =C2=A0 =C2=A0 bitcoin-development-owner@lists.sourc= eforge.net

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Bitcoin-development digest..."

Today's Topics:

=C2=A0 =C2=A01. Re: Block Size Increase (Mark Friedenbach)
=C2=A0 =C2=A02. Softfork signaling improvements (Douglas Roark)
=C2=A0 =C2=A03. Re: Block Size Increase (Mark Friedenbach)
=C2=A0 =C2=A04. Re: Block Size Increase (Raystonn) (Damian Gomez)
=C2=A0 =C2=A05. Re: Block Size Increase (Raystonn)


---------- Forwarded message ----------
From:=C2=A0Mark Friedenb= ach <mark@frie= denbach.org>
To:=C2=A0Raystonn <raystonn@hotmail.com>
Cc:=C2=A0Bitcoi= n Development <bitcoin-development@lists.sourceforge.net>
= Date:=C2=A0Fri, 8 May 2015 13:55:30 -0700
Subject:=C2=A0Re: [Bitcoin-dev= elopment] Block Size Increase
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>
On Fri, May 8, 2015 at 1:51 PM, Raystonn <raystonn@hotmail.com> wrote:
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


---------- Forwarded message ----------
From:=C2=A0Douglas Roark= <doug@bitco= inarmory.com>
To:=C2=A0Bitcoin Dev <bitcoin-development@li= sts.sourceforge.net>
Cc:=C2=A0
Date:=C2=A0Fri, 8 May 2015 15:2= 7:26 -0400
Subject:=C2=A0[Bitcoin-development] Softfork signaling improv= ements
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hello. I've seen Greg make a couple of posts online
(https://bitcointalk.org/index.php?topic=3D103= 3396.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@bitcoinarm= ory.com
PGP key ID: 92ADC0D7
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: GPGTools - http= s://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
=3DayhE
-----END PGP SIGNATURE-----




---------- Forwarded message ----------
From:=C2=A0Mark Friedenb= ach <mark@frie= denbach.org>
To:=C2=A0"Raystonn ." <raystonn@hotmail.com>
C= c:=C2=A0Bitcoin Development <bitcoin-development@lists.sourceforge.n= et>
Date:=C2=A0Fri, 8 May 2015 13:40:50 -0700
Subject:=C2=A0Re= : [Bitcoin-development] Block Size Increase
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.

On Fri, May 8, 2015 at 1:38 PM= , Raystonn . <raystonn@hotmail.com> wrote:

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.

-Raystonn

On 8 May 2015 1:17 pm, Aaron Voisine <voisine@gmail.com> w= rote:
As the author of a = popular SPV wallet, I wanted to weigh in, in support of the Gavin's 20M= b block proposal.

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.

When users pay too low a fee, they should:

1) See immediate failure as they do now with fees that fail to propagate.<= /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>

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.

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.

Aaron Voisine
co-founder an= d CEO
breadwallet.c= om

----------------------------------------------------= --------------------------
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-de= velopment




---------- Forwarded message ----------
From:=C2=A0Damian Gomez = <dgomez1092@gm= ail.com>
To:=C2=A0bitcoin-development@lists.sourceforge.net
Cc:=C2=A0
Date:=C2=A0Fri, 8 May 2015 14:04:10 -0700
Subject:=C2= =A0Re: [Bitcoin-development] Block Size Increase (Raystonn)
Hello,=C2=A0

I was reading some of the thread but c= an't say I read the entire thing.=C2=A0

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.

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

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

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)



Thanks for letting me j= oin the conversation
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 )


_Damian


---------- Forwarded message ----------
From:=C2=A0Raystonn <= raystonn@hotmail.= com>
To:=C2=A0Mark Friedenbach <mark@friedenbach.org>
Cc:=C2=A0Bitcoi= n Development <bitcoin-development@lists.sourceforge.net>
= Date:=C2=A0Fri, 8 May 2015 14:01:28 -0700
Subject:=C2=A0Re: [Bitcoin-dev= elopment] Block Size Increase

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.

-Raystonn

On 8 May 2015 1:55 pm, Mark Friedenbach <mark@friedenbach.org<= /a>> wrote:
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.

On Fri, May 8, 2015 at 1:51 PM, Raystonn <raystonn@hotmail.com>= wrote:
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

----------------------------------------------------= --------------------------
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-de= velopment




--f46d041828080f830f051599565e--