Re: [Bitcoin-development] Long-term mining incentives
I hope to keep continuing this conversations. Pardon my absence, but I
don't alway feel like I have much to contribute especially if it's not
techincal.
On my part I have been a proponent, of an alterrnativ consensus, that
begins shifting away from teh current cooinbase reward system in order to
reduce mining on the whole and thus limit those who do mine to do so on a
level of integrity.
I took a look at the ethereum blog on weak subjectivity, it does seem to be
a good transtition to use a gravity schema to be implemented in a Log
Structured Merge tree in order to find doscrepancy in forks.
Using this sama data structure could still be used in a consensus model. In
terms of how nodes communicate on teh network their speed and latency
communication are at least halfway solved based off their intereactions
(kernel software changes) with how nodes write and read memory { smp_wrb()
|| smp_rmb() } This would allow for a connection on the
Let me provide a use case: Say that we wanted to begin a new model for
integrity, then the current value for integrity would utilize a OTS from
the previous hash in order to establish the previous owner address of the
block it was previously part of. THE MAIN ISSUE here is being able to
verify, which value of integrity is useful for being able to establish a
genesis block. A paper by Lee Ewe (2001) called *The Byzantine General's
Problem* gives insight as to how a O(n^c) model is suitable to send a
message w/ value through out the system, each node is then sent a
read-invalidate request in order to change their cache logs for old system
memory in a new fixed address. Upon consensus of this value the rest of the
brainer {1st recipeients} nodes would be able to send a forward
propagation of the learnt value and, after acceptance the value would then
be backpropagated to the genesis block upoon every round in orderr to set a
deterministic standard for the dynamic increase of integrity of the system.
In POW systems the nonce generated would be the accumulation of the
integrity within a system and what their computatiuonal exertion in terms
of the overall rate of integrity increase in the system as the new coinbase
- this value then is assigned and signed to the hash and teh Merkel Root
as two layers encoded to its base and then reencrypted using EDCSA from
the 256 to 512 bit transformation so that the new address given has a
validity that cannot be easily fingerprinted and the malleability of teh
transaction becomes much more difficult due to the overall 2 ^ 28
verification stamp provided to the new hash. The parameters T T r P
(Trust value) - foud in the new coinbase or the scriptSig
( Hidden) - found in the Hash, and the merkel root hash
(TRust overall) R = within the target range for new nonces and address
locations
Paradigm (integrity) = held within the genesis block as a backpropogated
solution
Using this signature then the nodes would then be able to communicate and
transition the memory resevres for previous transaction on the block based
on the byzantine consensus. What noone has yet mentioned which I have
forgotten too, is how these datacenters of pool woul be supported w/out
fees. I will thrw that one out to all of you. The current consensus system
leaves room for orp[haned transactions if there were miltiple signature
requests the queue would be lined up based off integrity values in order to
have the most effective changes occcur first.
I have some more thoughts and will continue working on the techinical
vernacular and how a noob developer and decent computer science student
could make such an mplementation a reality. Thanks in advance for
listengin to this.
Thank you to Greg Maxwell for allowing us to liosten to his talk online,
was hearing while writing this. And to Krzysztof Okupsi and Paul
McKenny(Memory Barriers Hardware View for Software hackers) for their help
in nudging my brain and the relentles people behind the scenes who make all
our minds possible.
On Wed, May 13, 2015 at 4:26 AM,
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: Long-term mining incentives (Thomas Voegtlin)
2. Re: Long-term mining incentives (Tier Nolan)
3. Re: Long-term mining incentives (Alex Mizrahi)
4. Re: Proposed alternatives to the 20MB stepfunction (Tier
Nolan)
5. Re: Block Size Increase (Oliver
Re: [Bitcoin-development] Bitcoin-development Digest, Vol 48, Issue 62
Hllo
I want to build from a conversation that I had w/ Peter (T?) regarding the
increase in block size in the bitcoin from its's current structure would be
the proposasl of an prepend to the hash chain itself that would be the
first DER decoded script in order to verify integrity(trust) within a set
of transactions and the originiator themselves.
It is my belief that the process to begin a new encryption tool using a
variant of the WinterNitz OTS for its existential unforgeability to be the
added signatures with every Wallet transaction in order to provide a
consesnus systemt that takes into accont a personal level of intergrity for
the intention fo a transaction to occur. This signature would then be
hashes for there to be an intermediate proxy state that then verifies and
evaluates the trust fucntion for the receiving trnsactions. This
evaluation loop would itself be a state in which the mining power and the
rewards derived from them would be an increased level of integrity as
provided for the brainers of a systems who are then the signatuers of
the transaction authenticity, and additiaonally program extranonces of x
bits {72} in order to have a double valid signature that the rest of the
nodes would accept in order to have a valid address from which to be able
to continuously receive transactions.
There is a level of diffculty in obtaining brainers, fees would only apply
uin so much as they are able to create authentic transactions based off the
voting power of the rest of the received nodes. The greater number of
faults within the system from a brainer then the more, so would his
computational power be restricted in order to provide a reward feedback
system. This singularity in a Byzantine consensus is only achieved if the
route of an appropriate transformation occurs, one that is invariant to the
participants of the system, thus being able to provide initial vector
transformations from a person's online identity is the responsibilty that
we have to ensure and calulate a lagrangian method that utilisizes a set of
convolutional neural network funcitons [backpropagation, fuzzy logic] and
and tranformation function taking the vectors of tranformations in a
kahunen-loeve algorithm and using the convergence of a baryon wave function
in order to proceed with a baseline reading of the current level of
integrity in the state today that is an instance of actionable acceleration
within a system.
This is something that I am trying to continue to parse out. Therefore
there are still heavy questions to be answered(the most important being the
consent of the people to measure their own levels of integrity through
mined information) There must always be the option to disconnect from a
transactional system where payments occur in order to allow a level of
solace and peace within individuals -- withour repercussions and a seperate
system that supports the offline realm as well. (THis is a design problem)
Ultimately, quite literally such a transaction system could exist to
provide detailed analysis that promotes integrity being the basis for
sharing information. The fee structure would be eliminated, due to the
level of integrity and procesing power to have messages and transactions
and reviews of unfiduciary responsible orgnizations be merited as highly
true (.9 in fizzy logic) in order to promote a well-being in the state.
That is its own reward, the strenght of having more processing speed.
FYI(thank you to peter whom nudged my thinking and interest (again) in this
area. )
This is something I am attempting to design in order to program it. Though
I am not an expert and my technology stack is limited to java and c (and my
issues from it). I provided a class the other day the was pseudo code for
the beginning of the consensus. Now I might to now if I am missing any of
teh technical paradigms that might make this illogical? I now with the
advent of 7petabyte computers one could easily store 2.5 petabytes of human
information for just an instance of integrity not to mention otehr
emotions.
*Also, might someone be able to provide a bit of information on Bitcoin
core project?*
thank you again. Damain.
On Mon, May 11, 2015 at 10:29 AM,
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. Fwd: Bitcoin core 0.11 planning (Wladimir)
2. Re: Bitcoin core 0.11 planning (Wladimir)
3. Long-term
Re: [Bitcoin-development] Bitcoin-development Digest, Vol 48, Issue 63
Btw How awful that I didn't cite my sources, please exucse me, this is
definitely not my intention sometimes I get too caught up in my own
excitemtnt
1) Martin, J., Alvisi, L., Fast Byzantine Consensus. *IEEE Transactions on
Dependable and Secure Computing. 2006. *3(3) doi: ? Please see
John-Phillipe Martin and Lorenzo ALvisi
2) https://eprint.iacr.org/2011/191.pdf One_Time Winternitz Signatures.
On Mon, May 11, 2015 at 1:20 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: Bitcoin-development Digest, Vol 48, Issue 62 (Damian Gomez)
-- Forwarded message --
From: Damian Gomez dgomez1...@gmail.com
To: bitcoin-development@lists.sourceforge.net
Cc:
Date: Mon, 11 May 2015 13:20:46 -0700
Subject: Re: [Bitcoin-development] Bitcoin-development Digest, Vol 48,
Issue 62
Hllo
I want to build from a conversation that I had w/ Peter (T?) regarding the
increase in block size in the bitcoin from its's current structure would be
the proposasl of an prepend to the hash chain itself that would be the
first DER decoded script in order to verify integrity(trust) within a set
of transactions and the originiator themselves.
It is my belief that the process to begin a new encryption tool using a
variant of the WinterNitz OTS for its existential unforgeability to be the
added signatures with every Wallet transaction in order to provide a
consesnus systemt that takes into accont a personal level of intergrity for
the intention fo a transaction to occur. This signature would then be
hashes for there to be an intermediate proxy state that then verifies and
evaluates the trust fucntion for the receiving trnsactions. This
evaluation loop would itself be a state in which the mining power and the
rewards derived from them would be an increased level of integrity as
provided for the brainers of a systems who are then the signatuers of
the transaction authenticity, and additiaonally program extranonces of x
bits {72} in order to have a double valid signature that the rest of the
nodes would accept in order to have a valid address from which to be able
to continuously receive transactions.
There is a level of diffculty in obtaining brainers, fees would only apply
uin so much as they are able to create authentic transactions based off the
voting power of the rest of the received nodes. The greater number of
faults within the system from a brainer then the more, so would his
computational power be restricted in order to provide a reward feedback
system. This singularity in a Byzantine consensus is only achieved if the
route of an appropriate transformation occurs, one that is invariant to the
participants of the system, thus being able to provide initial vector
transformations from a person's online identity is the responsibilty that
we have to ensure and calulate a lagrangian method that utilisizes a set of
convolutional neural network funcitons [backpropagation, fuzzy logic] and
and tranformation function taking the vectors of tranformations in a
kahunen-loeve algorithm and using the convergence of a baryon wave function
in order to proceed with a baseline reading of the current level of
integrity in the state today that is an instance of actionable acceleration
within a system.
This is something that I am trying to continue to parse out. Therefore
there are still heavy questions to be answered(the most important being the
consent of the people to measure their own levels of integrity through
mined information) There must always be the option to disconnect from a
transactional system where payments occur in order to allow a level of
solace and peace within individuals -- withour repercussions and a seperate
system that supports the offline realm as well. (THis is a design problem)
Ultimately, quite literally such a transaction system could exist to
provide detailed analysis that promotes integrity being the basis for
sharing information. The fee structure would be eliminated, due to the
level of integrity and procesing power to have messages and transactions
and reviews of unfiduciary responsible orgnizations be merited as highly
true (.9 in fizzy logic) in order to promote a well-being in the state.
That is its own reward, the strenght of having more processing speed.
FYI(thank you to peter whom nudged my thinking and interest
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 -- 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
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
Re: [Bitcoin-development] Bitcoin-development Digest, Vol 48, Issue 41
));
total rand() %10 + 1 endl;
return stdin};
};
BIGNUM* priv_key{// private parameter (DH value x)
x = BN_GENERATOR_KEY_2
};
BIGNUM* pub_key{ // public parameter (DH value g^x)
g^x = BN_GENERATOR_KEY_2 e DH_GENERATOR_KEY_5
};
// ohm
int BN_num_bytes(const BIGNUM* bn) {
void binary(int);
void main(void) {
int bn;
cout 80;
cin BIGNUM;
if (cin 0)
cout Errors.\n;
else {
cout number converted to binary is: ;
binary(cin);
cout endl;
}
}
void binary(int cin) {
int remainder;
if(cin = 1) {
cout cin;
return cout;
}
remainder = BIGNUM%2;
binary(BIGNUM 1);
cout remainder;
}
};
void BN_free(BIGNUM* len) {
void reverse(len){
binarylen/10::value 1 | len % 10;
int len;
if (len = 80){
return 80 -- len
}
else (len 80) {
return len - 80
}
}
};
int BN_bn2bin(const BIGNUM* bn, unsigned char* to);
BIGNUM* BN_bin2bn(const unsigned char* s, int len,
BIGNUM* ret);
}DH;
int DH_compute_key(unsigned char* key, BIGNUM* callback,
DH* dh) {
if key != callback
return NULL`
else return p_privkey dh
};
/* Exchanges dh-pub_key with the server*/
int efx_nic_alloc_buffer(struct efx_nic *BIGNUM, struct efx_buffer *buffer,
unsigned int len, gfp_t gfp_flags)
{
buffer-addr = dma_zalloc_coherent(efx-pci_dev-dev, len,
buffer-dma_addr, gfp_flags);
if (!buffer-addr)
return -ENOMEM;
return kvm_alloc;
};
struct kvm_alloc(*KVM_CPUID_SIGNATURE VICI* bn kvm_vcpu *virt)
{KVM_CPUID_SIGNATURE= signature[10]};
};
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.
(mr patrick mccorry its the tab functionality in my keyboard during my
formatiing )
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
