From: Damian Gomez <dgomez1092@gmail•com>
To: bitcoin-development@lists•sourceforge.net
Subject: Re: [Bitcoin-development] Bitcoin-development Digest, Vol 48, Issue 41
Date: Fri, 8 May 2015 15:13:21 -0700 [thread overview]
Message-ID: <CAH+jCTxYnT+oOmxXRF-dA8F02wVMZ-en2HW1cs2+Kn290j6T3Q@mail.gmail.com> (raw)
In-Reply-To: <CAH+jCTwxjfEVog4JR+8kCvbBPoT50f322NV3T+8Bz-sTnK-yXQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 13327 bytes --]
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
>>>
>>>
>>
>
[-- Attachment #2: Type: text/html, Size: 18062 bytes --]
next prev parent reply other threads:[~2015-05-08 22:13 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <mailman.63969.1431119326.18600.bitcoin-development@lists.sourceforge.net>
2015-05-08 22:11 ` Damian Gomez
2015-05-08 22:12 ` Damian Gomez
2015-05-08 22:13 ` Damian Gomez [this message]
2015-05-09 0:00 ` Damian Gomez
2015-05-09 0:42 ` Gregory Maxwell
2015-05-09 16:39 ` Peter Todd
2015-05-08 22:19 Raystonn
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAH+jCTxYnT+oOmxXRF-dA8F02wVMZ-en2HW1cs2+Kn290j6T3Q@mail.gmail.com \
--to=dgomez1092@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox