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