Re: [Bitcoin-development] Bitcoin-development Digest, Vol 48, Issue 41

[Damian Gomez <dgomez1092@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 12952 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 17633 bytes --]