Re: [Bitcoin-development] Bitcoin-development Digest, Vol 48, Issue 41
On Sat, May 09, 2015 at 12:42:08AM +, Gregory Maxwell wrote: On Sat, May 9, 2015 at 12:00 AM, Damian Gomez dgomez1...@gmail.com wrote: where w represents the weight of the total number of semantical constraints that an idivdual has expressed throught emotivoe packets that I am working on (implementation os difficutlt). I think this is the appropriate route to implemeting a greating block size that will be used in preventing interception of bundled informations and replace value. Client side implmentation will cut down transaction fees for the additional 264 bit implementation and greatly reduce need for ewallet providers to do so. In these posts I am reminded of and sense some qualitative similarities with a 2012 proposal by Mr. NASDAQEnema of Bitcointalk with respect to multigenerational token architectures. In particula,r your AES ModuleK Hashcodes (especially in light of Winternitz compression) may constitute an L_2 norm attractor similar to the motherbase birthpoint metric presented in that prior work. Rethaw and I provided a number of points for consideration which may be equally applicable to your work: https://bitcointalk.org/index.php?topic=57253.msg682056#msg682056 Mr Gomez may find my thesis paper on the creation of imitations of reality with the mathematical technique of Bolshevik Statistics (BS) to be of aid: https://s3.amazonaws.com/peter.todd/congestion.pdf -- 'peter'[:-1]@petertodd.org 00b0388c459b9aff8a93d02bbb87aac6d74b65e9faf7e4c9 signature.asc Description: Digital signature -- 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
Re: [Bitcoin-development] Bitcoin-development Digest, Vol 48, Issue 41
Fail, Damian. Not even a half-good attempt. -Raystonn On 8 May 2015 3:15 pm, Damian Gomez dgomez1...@gmail.com wrote: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... Todays 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.orgTo: Raystonn raystonn@hotmail.comCc: Bitcoin Development bitcoin-development@lists.sourceforge.netDate: Fri, 8 May 2015 13:55:30 -0700Subject: Re: [Bitcoin-development] Block Size IncreaseThe 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.comTo: Bitcoin Dev bitcoin-development@lists.sourceforge.netCc: Date: Fri, 8 May 2015 15:27:26 -0400Subject: [Bitcoin-development] Softfork signaling improvements-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hello. Ive 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, Im 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 cant 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 iQIcBAEBCgAGBQJVTQ4eAAoJEGybVGGSrcDX8eMQAOQiDA7anqZBqDfVIwEzY2C SxOVxswwxAyTtZNM/Nm8MTq77hF83j/C3bUbDW6wCu4QxBYA/uiCGTf44dj6WX 7aiXg1o9C4LfPcuUngcMI0H5ixOUxnbqUdmpNdoIvy4did2dVs9fAmOPEoSVUm72 6dMLGrtlPN0jcLX6pJd12Dy3laKxd0AP72wi6SivH6i8v8rLb940EuBS3hIkuZG0 vnR5MXMIEd0rkWesr8hn6oTs/k8t4zgts7cgIrA7rU3wJq0qaHBa8uASUxwHKDjD KmDwaigvOGN6XqitqokCUlqjoxvwpimCjb3Uv5Pkxn8dwue9F/IggRXUSuifJRn UEZT2F8fwhiluldz3sRaNtLOpCoKfPCYYv7kvGySgqagtNJFHoFhbeQM0S3yjRn Ceh1xK9sOjrxw/my0jwpjJkqlhvQtVG15OsNWDzZeWa56kghnSgLkFOT4G6IxB EUOcAYjJkLbg5ssjgyhvDOvGqft2e4MNlB01e1ZQr4whQH4TdRkd66A4WDNB0g LBqVhAc2C8L3g046mhZmC33SuOSxxm8shlxZvYLHU2HrnUFg9NkkXi1Ub7agMSck TTkLbMx17AvOXkKH0v1L20kWoWAp9LfRGdDqnY8svJkaUuVtgDurpcwEk40WwEZ caYBw8bdLpKZwqbA1DL =ayhE -END PGP SIGNATURE- -- Forwarded message --From: Mark Friedenbach mark@friedenbach.orgTo: Raystonn . raystonn@hotmail.comCc: Bitcoin Development bitcoin-development@lists.sourceforge.netDate: Fri, 8 May 2015 13:40:50 -0700Subject: Re: [Bitcoin-development] Block Size IncreaseTransactions dont 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,
Re: [Bitcoin-development] Bitcoin-development Digest, Vol 48, Issue 41
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-requ...@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-requ...@lists.sourceforge.net You can reach the person managing the list at bitcoin-development-ow...@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 m...@friedenbach.org To: Raystonn rayst...@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 rayst...@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 d...@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. d...@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 m...@friedenbach.org To: Raystonn . rayst...@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 . rayst...@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
Re: [Bitcoin-development] Bitcoin-development Digest, Vol 48, Issue 41
On Fri, May 8, 2015 at 3:12 PM, Damian Gomez dgomez1...@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 dgomez1...@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-requ...@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-requ...@lists.sourceforge.net You can reach the person managing the list at bitcoin-development-ow...@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 m...@friedenbach.org To: Raystonn rayst...@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 rayst...@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 d...@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. d...@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 m...@friedenbach.org To: Raystonn . rayst...@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,
Re: [Bitcoin-development] Bitcoin-development Digest, Vol 48, Issue 41
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 dgomez1...@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-requ...@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-requ...@lists.sourceforge.net You can reach the person managing the list at bitcoin-development-ow...@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 m...@friedenbach.org To: Raystonn rayst...@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 rayst...@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 d...@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. d...@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 m...@friedenbach.org To: Raystonn . rayst...@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 . rayst...@hotmail.com wrote: I have a proposal for
Re: [Bitcoin-development] Bitcoin-development Digest, Vol 48, Issue 41
...of the following:
the DH_GENERATION would in effect calculate the reponses for a total
overage of the public component, by addding a ternary option in the actual
DH key (which I have attached to sse if you can iunderstand my logic)
For Java Practice this will be translated:
public static clientKey {
KeyPairGenerator cbArgs =notes sent(with a txn)/ log(w) -
log(w-1)/ log(w) + 1
cbArgs.ByteArrayStream.enqueue() ;
cbByte [] = Cipher.getIstance(AES, publicKey);
w = SUM(ModuleW([wi...,wn]))
Arraybyte.init(cbArgs);
BufferedOutputStream eclient = FileInputStream(add(cbByte));
}
public static Verify(String[] args) {
CipherCache clientSignature [cbByte];
Hash pubKey = ArraypubKey;
ByteArray pubKeyHash [ serverArgsx...serverArgsn];
for clientSecurity.getIndex[xi] {pubKeyHash[xi] ;
int start = 0;
while (true) {
int index = str.indexOf(0);
if (xi = 0) {
pubKey.ByteArray(n) == clientTxns(xi, 0);
pubKey(n++) clientTxns.getIndex(xi++) - clientTxns.getIndex(xi - xin);
}
index++;
return beta = pubKey.Array.getIndex();
index l = 0;
l++;
for pubKey.Array() == index
{clientSignature pbg(w - 1) = (cbByte.getIndexOf(i); i++, i==l);
pba(x) = pbg - beta * y(x); } //y(x) instance of DH privkey ByteLength x
a public DHkey
Parser forSign = hashCode(bg, 0) return pubKey.length() ==
hashCode.length();
if pubKey.length() beta {return false;}
else import FileInputStream(OP_MSG) //transfer to compiler code
Cipher OPMSG = cipher.init(AES)
{OPMSG.getInstance.ByteArrayLenght(OP_MSG, 1); for OPMSG.lenghth = 0;
{forSign(getFront(OPMSG) - getEnd(OPMSG) == OPMSG.length)
B.getIndexOf(0) = { pubKey.getIndexOf(k) 2^(w-b)=[bi...bn];}} //are
memory in Box cache of MsgTxns for blockchain merkel root}
if B[0] * pba = beta return null;
else ModuleK[0] K(x) = beta - 1 - (B[0] * pba(OPMSG) * pba(x));
{if K(x) = 6 = y return null; else return K(x).pushModule;}
}}}
++
#include openssl/dh.h
#include openssl/bn.h
#include bu.c
/* Read incoming call */
size_t fread(void *ptr, size_t size, size_t nmemb, FILE *callback) {
int main()
{
FILE *fp;
fp = fopen(bu.c, eclient.c);
/* Seek to the beginning of the file */
fseek(fp, SEEK_SET, 0);
char to[];
char buffer[80];
/* Read and display data */
fread(buffer, strlen(to)+1, 1, fp);
printf(%s\n, buffer);
fclose(fp);
return(0);
}};
/* Generates its public and private keys*/
Typedef struct bn_st{
BIGNUM* BN_new();
BIGNUM* p{ // shared prime number
static inline int aac_valid_context(struct scsi_cmnd *scsicmd,
struct fib *fibptr) {
struct scsi_device *device;
if (unlikely(!scsicmd || !scsicmd-scsi_done)) {
dprintk((KERN_WARNING aac_valid_context: scsi command
corrupt\n));
aac_fib_complete(fibptr);
aac_fib_free(fibptr);
return 0;
} scsicmd-SCp.phase = AAC_OWNER_MIDLEVEL;
device = scsicmd-device;
if (unlikely(!device || !scsi_device_online(device))) {
dprintk((KERN_WARNING aac_valid_context: scsi device
corrupt\n));
aac_fib_complete(fibptr);
aac_fib_free(fibptr);
return 0;
}
return 1;
}
int aac_get_config_status(struct aac_dev *dev, int commit_flag)
{
int status = 0;
struct fib * fibptr;
if (!(fibptr = aac_fib_alloc(dev)))
return -ENOMEM;
else aac_fib_init(fibptr);
{
struct aac_get_config_status *dinfo;
dinfo = (struct aac_get_config_status *) fib_data(fibptr);
dinfo-command = cpu_to_le64(VM_ContainerConfig);
dinfo-type = cpu_to_le64(CT_GET_CONFIG_STATUS);
dinfo-count = cpu_to_le64(sizeof(((struct
aac_get_config_status_resp *)NULL)-data));
}
status = aac_fib_send(ContainerCommand,
fibptr,
sizeof (struct aac_get_config_status),
FsaNormal,
1, 1,
sizeof (struct aac_commit_config),
FsaNormal,
1, 1,
NULL, NULL);
if (status = 0)
aac_fib_complete(fibptr);
} else if (aac_commit == 0) {
printk(KERN_WARNING
aac_get_config_status: Others configurations
ignored\n);
}
}
if (status != -ERESTARTSYS)
aac_fib_free(fibptr);
return status;
}
};
BIGNUM* g{ // shared generator
int stdin;
int main() {
srand(time(NULL));
Re: [Bitcoin-development] Bitcoin-development Digest, Vol 48, Issue 41
On Sat, May 9, 2015 at 12:00 AM, Damian Gomez dgomez1...@gmail.com wrote: ...of the following: the DH_GENERATION would in effect calculate the reponses for a total overage of the public component, by addding a ternary option in the actual DH key (which I have attached to sse if you can iunderstand my logic) [snip code] Intriguing; and certainly a change of the normal pace around here. where w represents the weight of the total number of semantical constraints that an idivdual has expressed throught emotivoe packets that I am working on (implementation os difficutlt). I think this is the appropriate route to implemeting a greating block size that will be used in preventing interception of bundled informations and replace value. Client side implmentation will cut down transaction fees for the additional 264 bit implementation and greatly reduce need for ewallet providers to do so. In these posts I am reminded of and sense some qualitative similarities with a 2012 proposal by Mr. NASDAQEnema of Bitcointalk with respect to multigenerational token architectures. In particula,r your AES ModuleK Hashcodes (especially in light of Winternitz compression) may constitute an L_2 norm attractor similar to the motherbase birthpoint metric presented in that prior work. Rethaw and I provided a number of points for consideration which may be equally applicable to your work: https://bitcointalk.org/index.php?topic=57253.msg682056#msg682056 Your invocation of emotive packets suggests that you may be a colleague of Mr. Virtuli Beatnik? While not (yet) recognized as a star developer himself; his eloquent language and his mastery of skb crypto-calculus and differential-kernel number-ontologies demonstrated in his latest publication ( https://archive.org/details/EtherealVerses ) makes me think that he'd be an ideal collaborator for your work in this area. -- 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
