* [bitcoin-dev] Block size adjustment idea - expedience fees + difficulty scaling proportional to block size (+ fee pool) [not found] ` <CAAt2M1-LZQ1yE1CezFA+hr+=de-RVJ7wzkq-t969BC7OL6dWwg@mail.gmail.com> @ 2017-03-30 9:34 ` Natanael 2017-03-30 10:04 ` Luke Dashjr 2017-03-30 18:41 ` Natanael 0 siblings, 2 replies; 6+ messages in thread From: Natanael @ 2017-03-30 9:34 UTC (permalink / raw) To: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 8618 bytes --] I had these following ideas as I was thinking about how to allow larger blocks without incentivizing the creation of excessively large blocks. I don't know how much of this is novel, I'd appreciate if anybody could link to any relevant prior art. I'm making no claims on this, anything novel in here is directly released into public domain. In short, I'm trying to rely on simple but direct incentives to improve the behavior of Bitcoin. Feedback requested. Some simulations requested, see below if you're willing to help. Any questions are welcome. --- Expedience fees. Softfork compatible. You want to really make sure your transaction gets processed quickly? Transactions could have a second fee type, a specially labeled anyone-can-spend output with an op_return value defining a "best-before" block number and some function describing the decline of the fee value for every future block, such that before block N the miners can claim the full expedience fee + the standard fee (if any), between block N+1 and N+X the miner can claim a reduced expedience fee + standard fee, afterwards only the standard fee. When a transaction is processed late such that not the full expedience fee can be claimed, the remainder of the expedience fee output is returned to the specified address among the inputs/outputs (could be something like in#3 for the address used by the 3rd UTXO input). This would have to be done for all remaining expedience fees within the last transaction in the block, inserted there by the miner. These additional UTXO:s does increase overhead somewhat, but hopefully not by too much. If we're going to modify the transaction syntax eventually, then we could take the chance to design for this to reduce overhead. My current best idea for how to handle returned expedience fees in multiuser transactions (coinjoin, etc) is to donate it to an agreed upon address. For recurring donation addresses (the fee pool included!), this reduces the number of return UTXO:s in the fee processing transaction. The default client policy may be to split the entire fee across an expedience fee and a fee pool donation, where the donation part becomes larger the later the transaction gets processed. This is expected to slow down the average inclusion speed of already delayed transactions, but they remain profitable to include. The dynamics here is simple, a miner is incentivized to process a transaction with an expedience fee before a standard fee of the same value-per-bit in order to not reduce the total value of the available fees of all standing transactions they can process. The longer they wait, the less total fees available. Sidenote: a steady stream of expedience fees reduces the profitability of block withholding attacks (!), at some threshold it should make it entirely unprofitable vs standard mining. This is due to the increased risk of losing valuable expedience fees added after you finished your first block (as the available value will be reduced in your block #2, vs what other miners can claim while still mining on that previous block). (Can somebody verify this with simulations?) --- Fee pool. Softfork compatible. We want to smooth out fee payments too for the future when the subsidy drops, to prevent deliberate forking to steal fees. We can introduce a designated P2SH anyone-can-spend fee pool address. The miner can never claim the full fees from his block or claim the full amount in the pool, only some percentage of both. The remainder goes back into the pool (this might be done at the end of the same expedience fee processing transaction described above). Anybody can deliberately pay to the pool. The fee pool is intended to act as a "buffer" such that it remains profitable to not try to steal fees but to just mine normally, even during relatively extreme fee value variance (consider the end of a big international shopping weekend). The fee value claimed by the miners between blocks is allowed to vary, but we want to avoid order-of-magnitude size variation (10x). We do however want the effect of expedience fees to have an impact. Perhaps some logarithmic function can smooth it out? Forcing larger fees to be distributed over longer time periods? --- Block size dependent difficulty scaling. Hardfork required. Larger blocks means greater difficulty - but it doesn't scale linearly, rather a little less than linearly. That means miners can take a penalty in difficulty to claim a greater number of high fee transactions in the same amount of time (effectively increasing "block size bitrate"), increasing their profits. When such profitable fees aren't available, they have to reduce block size. In other words, the users literally pay miners to increase block size (or don't pay, which reduces it). (Sidenote: I am in favor of combining this with the idea of a 32 MB max blocksize (or larger), with softforked scheduled lower size caps (perhaps starting at 4 MB max) that grows according to a schedule. This reduces the risk of rapidly increasing load before we have functional second layer scaling in place.) In order for a miner to profit from adding additional transactions, their fees must exceed the calculated cost of the resulting difficulty penalty to make it worth it to create a larger block. Such loads are expected during international shopping weekends. With only a few available high value transactions the incentive becomes the reverse, to create a smaller block with lower difficulty to faster claim those fees. To keep the average 10 minute block rate and to let this mechanism shift the "block size bitrate" as according to the fee justified block size changes, we set an Expected blocksize value that changes over time, and we change the difficulty target into the Standard difficulty target, where each block must reach a Scaled difficulty target . In terms of math we do something like this: Scaled difficulty = Standard difficulty * f(blocksize), where f would likely be some logarithmic function, and blocksize is defined in terms of units of Expected blocksize (a block 1.5x larger than Expected blocksize gets a value of 1.5). When we retarget the Standard difficulty and Expected blocksize we do this: Standard difficulty = Network hashrate per 10 minutes (approximately same as before, but now we take the Scaled difficulty of the last period's previous blocks into consideration) Standard blocksize = Recent average effective block bitrate = (sum of recent (weighted!) block sizes / length of timeperiod) / number of blocks in a retargeting period. Thus, generating larger blocks drives up the long term standard block bitrate, smaller blocks reduces it, in both cases we strive to average 1 block per 10 minutes. Combining this with expedience fees makes it even more effective; There's always a cutoff for where a miner stops including unprocessed transactions and let the rest remain for the next block. For standard fees, this would result in a fairly static block size and transactions backlog. With expedience fees your transaction can bypass standard fees with same value-per-bit, as explained above, because otherwise the miners reduces the value of their future expected fees. The more people that do this, the greater incentive to not delay transactions and instead increase the blocksize. (Can somebody help with the math here? I want simulations of this.) (Sidenote: I'm in favor of RBF, replace-by-fee. This makes the above work much more smoothly. Anybody relying on the security of unconfirmed transactions for any significant value *have to* rely on some kind of incentive protected multisignature transaction, including LN type second layer schemes. The other option is just not secure.) If load is low then you can add a high expedience fee to incentivize the creation of a smaller block with your transaction, since difficulty will be reduced for the smaller block. This means the miner has a higher chance of beating the competition. Adding additional lower fee transactions may reduce his average value-per-bit to become less profitable. Miners simply aim to maximize their fees-per-bit, while also paying as little as possible in mining costs. To make this work as intended for those willing to explicitly pay to reduce block size, one could tag such an expedience fee with a maximum allowed blocksize (where the fee will be claimed in such a smaller block if it is the more profitable option), such that it won't be countered by others making more high expedience fees to increase blocksize. Note: I'm not particularly in favor of this idea, just mentioning the possibility. [-- Attachment #2: Type: text/html, Size: 10427 bytes --] ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [bitcoin-dev] Block size adjustment idea - expedience fees + difficulty scaling proportional to block size (+ fee pool) 2017-03-30 9:34 ` [bitcoin-dev] Block size adjustment idea - expedience fees + difficulty scaling proportional to block size (+ fee pool) Natanael @ 2017-03-30 10:04 ` Luke Dashjr [not found] ` <CAAt2M1-57SMT4WT-4_pdkTPyybQgr2ZuQZW_KW2ZwhTQ7HEnqg@mail.gmail.com> 2017-03-30 18:41 ` Natanael 1 sibling, 1 reply; 6+ messages in thread From: Luke Dashjr @ 2017-03-30 10:04 UTC (permalink / raw) To: bitcoin-dev, Natanael On Thursday, March 30, 2017 9:34:31 AM Natanael via bitcoin-dev wrote: > You want to really make sure your transaction gets processed quickly? > Transactions could have a second fee type, a specially labeled > anyone-can-spend output with an op_return value defining a "best-before" > block number and some function describing the decline of the fee value for > every future block, such that before block N the miners can claim the full > expedience fee + the standard fee (if any), between block N+1 and N+X the > miner can claim a reduced expedience fee + standard fee, afterwards only > the standard fee. Minor detail: OP_RETURN doesn't work like that. You'd need OP_DROP. > When a transaction is processed late such that not the full expedience fee > can be claimed, the remainder of the expedience fee output is returned to > the specified address among the inputs/outputs (could be something like > in#3 for the address used by the 3rd UTXO input). This would have to be > done for all remaining expedience fees within the last transaction in the > block, inserted there by the miner. Inputs don't have addresses, and addresses should only ever be used once. You might be able to fix this by increasing the value of the change, though. It would require a new signature-check opcode at the very least. I don't see a purpose to this proposal. Miners always mine as if it's their *only* chance to get the fee, because if they don't, another miner will. Ie, after 1 block, the fee effectively drops to 0 already. > --- > > Fee pool. Softfork compatible. The standard problem with these is that miners are incentivised to publish their own "out of band fee" address so they get all the fee directly. Luke ^ permalink raw reply [flat|nested] 6+ messages in thread
[parent not found: <CAAt2M1-57SMT4WT-4_pdkTPyybQgr2ZuQZW_KW2ZwhTQ7HEnqg@mail.gmail.com>]
[parent not found: <CAAt2M1-3R7rY55=QgkP8xUs=SDHxyNQV_fshbi89a9KzcwWfLQ@mail.gmail.com>]
* Re: [bitcoin-dev] Block size adjustment idea - expedience fees + difficulty scaling proportional to block size (+ fee pool) [not found] ` <CAAt2M1-3R7rY55=QgkP8xUs=SDHxyNQV_fshbi89a9KzcwWfLQ@mail.gmail.com> @ 2017-03-30 10:19 ` Natanael 0 siblings, 0 replies; 6+ messages in thread From: Natanael @ 2017-03-30 10:19 UTC (permalink / raw) To: Luke Dashjr; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 1328 bytes --] Den 30 mars 2017 12:04 skrev "Luke Dashjr" <luke@dashjr•org>: I don't see a purpose to this proposal. Miners always mine as if it's their *only* chance to get the fee, because if they don't, another miner will. Ie, after 1 block, the fee effectively drops to 0 already. I believe that with correctly configured incentives, you can make it more profitable to delay some transactions with lower fees but still include them in the next block then to include them all at once. This would smooth out the inclusion of transactions. This may require changing the difficulty scaling from using a simple logarithm to a function that first behaves like a logarithm up to some multiple of the standard block size, after which difficulty starts increasing faster and reaches a greater-than-linear ratio in expected required hash per mined bit. Perhaps tipping over at around a blocksize 3x the standard blocksize. Since the standard blocksize increases with continous load after retargeting, the blocksize at which this happens also increases. Also, together with the above the fee pool does slightly counteract what you say, as they'll get a share via the pool when there's less transactions available the next time they create a block (like insurance). For a user, what's the incentive to pay an individual miner the fee directly? [-- Attachment #2: Type: text/html, Size: 1977 bytes --] ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [bitcoin-dev] Block size adjustment idea - expedience fees + difficulty scaling proportional to block size (+ fee pool) 2017-03-30 9:34 ` [bitcoin-dev] Block size adjustment idea - expedience fees + difficulty scaling proportional to block size (+ fee pool) Natanael 2017-03-30 10:04 ` Luke Dashjr @ 2017-03-30 18:41 ` Natanael 2017-03-31 4:14 ` Natanael 1 sibling, 1 reply; 6+ messages in thread From: Natanael @ 2017-03-30 18:41 UTC (permalink / raw) To: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 1523 bytes --] Den 30 mars 2017 11:34 skrev "Natanael" <natanael.l@gmail•com>: Block size dependent difficulty scaling. Hardfork required. Larger blocks means greater difficulty - but it doesn't scale linearly, rather a little less than linearly. That means miners can take a penalty in difficulty to claim a greater number of high fee transactions in the same amount of time (effectively increasing "block size bitrate"), increasing their profits. When such profitable fees aren't available, they have to reduce block size. In other words, the users literally pay miners to increase block size (or don't pay, which reduces it). This can be simplified if we do get a fee pool (less hardfork code, more softfork code), except that the effect will be partially reduced by the mining subsidy until it approximately reaches parity with average total fees. We don't need to alter difficulty calculation. Instead we alter the percentage of the fees that the miner gets to claim VS what he have to donate to the pool based on the size of the block he generated. Larger block = smaller percentage of fees. This is another way to pay for blocksize. The effect of this is that on average, miners that generate smaller blocks takes a share of what otherwise would be part of the mining profits of those generating larger blocks. We would need to keep pieces of the section from above on expected blocksize calculation. Because the closer you are to the expected blocksize, the more you keep. And thus we need to adjust it according to usage. [-- Attachment #2: Type: text/html, Size: 2337 bytes --] ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [bitcoin-dev] Block size adjustment idea - expedience fees + difficulty scaling proportional to block size (+ fee pool) 2017-03-30 18:41 ` Natanael @ 2017-03-31 4:14 ` Natanael 2017-03-31 4:15 ` Natanael 0 siblings, 1 reply; 6+ messages in thread From: Natanael @ 2017-03-31 4:14 UTC (permalink / raw) To: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 1523 bytes --] Den 30 mars 2017 11:34 skrev "Natanael" <natanael.l@gmail•com>: Block size dependent difficulty scaling. Hardfork required. Larger blocks means greater difficulty - but it doesn't scale linearly, rather a little less than linearly. That means miners can take a penalty in difficulty to claim a greater number of high fee transactions in the same amount of time (effectively increasing "block size bitrate"), increasing their profits. When such profitable fees aren't available, they have to reduce block size. In other words, the users literally pay miners to increase block size (or don't pay, which reduces it). This can be simplified if we do get a fee pool (less hardfork code, more softfork code), except that the effect will be partially reduced by the mining subsidy until it approximately reaches parity with average total fees. We don't need to alter difficulty calculation. Instead we alter the percentage of the fees that the miner gets to claim VS what he have to donate to the pool based on the size of the block he generated. Larger block = smaller percentage of fees. This is another way to pay for blocksize. The effect of this is that on average, miners that generate smaller blocks takes a share of what otherwise would be part of the mining profits of those generating larger blocks. We would need to keep pieces of the section from above on expected blocksize calculation. Because the closer you are to the expected blocksize, the more you keep. And thus we need to adjust it according to usage. [-- Attachment #2: Type: text/html, Size: 2405 bytes --] ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [bitcoin-dev] Block size adjustment idea - expedience fees + difficulty scaling proportional to block size (+ fee pool) 2017-03-31 4:14 ` Natanael @ 2017-03-31 4:15 ` Natanael 0 siblings, 0 replies; 6+ messages in thread From: Natanael @ 2017-03-31 4:15 UTC (permalink / raw) To: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 1706 bytes --] Sorry for sending a double, hit the wrong button... Den 31 mars 2017 06:14 skrev "Natanael" <natanael.l@gmail•com>: > > > Den 30 mars 2017 11:34 skrev "Natanael" <natanael.l@gmail•com>: > > Block size dependent difficulty scaling. Hardfork required. > > Larger blocks means greater difficulty - but it doesn't scale linearly, > rather a little less than linearly. That means miners can take a penalty in > difficulty to claim a greater number of high fee transactions in the same > amount of time (effectively increasing "block size bitrate"), increasing > their profits. When such profitable fees aren't available, they have to > reduce block size. > > In other words, the users literally pay miners to increase block size (or > don't pay, which reduces it). > > > This can be simplified if we do get a fee pool (less hardfork code, more > softfork code), except that the effect will be partially reduced by the > mining subsidy until it approximately reaches parity with average total > fees. > > We don't need to alter difficulty calculation. > Instead we alter the percentage of the fees that the miner gets to claim > VS what he have to donate to the pool based on the size of the block he > generated. > Larger block = smaller percentage of fees. This is another way to pay for > blocksize. The effect of this is that on average, miners that generate > smaller blocks takes a share of what otherwise would be part of the mining > profits of those generating larger blocks. > > We would need to keep pieces of the section from above on expected > blocksize calculation. Because the closer you are to the expected > blocksize, the more you keep. And thus we need to adjust it according to > usage. > [-- Attachment #2: Type: text/html, Size: 2851 bytes --] ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2017-03-31 4:15 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <CAAt2M1_x8zbN-vmgDEUQQvzrtonEKydb+B-P53ibCimVfnd-CA@mail.gmail.com>
[not found] ` <CAAt2M1-yWfqp+Ap=XUMiNro9oz=00WcJBSY1uVH3SrQ6GQ7Rig@mail.gmail.com>
[not found] ` <CAAt2M1-z5nS35sn37B_cH=S6oxFVf8Myptw-rMLCQ21a-uL9nw@mail.gmail.com>
[not found] ` <CAAt2M1_Rnejikvxd-X9SLdprS9rpq6b25aau0OSrWJu2YABMXw@mail.gmail.com>
[not found] ` <CAAt2M1_NbWM66dOdP7U9AMGdE4-NB2OyN-SWLkD-P32SPLYRmQ@mail.gmail.com>
[not found] ` <CAAt2M19_xUJy+=7mkmNxWR=J_=cjAjAnwkzbeTfFEx5s9FBTew@mail.gmail.com>
[not found] ` <CAAt2M19u9ZYjonPc_ViPFNzk_VBrUBJoB6yrqq_6=EAtvGt7HQ@mail.gmail.com>
[not found] ` <CAAt2M19HO2PE88wKQLiV+WicwoTY=5HV1LcpYQcK2f=nhsL=Kg@mail.gmail.com>
[not found] ` <CAAt2M1-_=oeeeFy5_gGdEz_iw=Eo3xzkF6R4fzpbM3x4C6pr2g@mail.gmail.com>
[not found] ` <CAAt2M1_-kby6Cy+P5aofoQXwUWfk8=wDqMO3c=z=rAwDvzbwkA@mail.gmail.com>
[not found] ` <CAAt2M1_eCcf7EoyTiJTHzUPaxWE_dY14oRsbYG7J1TDRQMUDvw@mail.gmail.com>
[not found] ` <CAAt2M1-4K+6TAab6mv3PnBckZS=X6eCbfDwkMbXo45_d+dpo+A@mail.gmail.com>
[not found] ` <CAAt2M1_kmvBsXOyX2k25JDHyQj8mwVG5vtat3nibG9Sv=NC-KQ@mail.gmail.com>
[not found] ` <CAAt2M1-jZdvdz85tREdNdZJJK6btzsYvB3x9rMntB01rE-QC6Q@mail.gmail.com>
[not found] ` <CAAt2M19UOmFya9jo25jWDpEDh6MEfKKHHtq3=QZP9XBkLbda7g@mail.gmail.com>
[not found] ` <CAAt2M18Le_UNDFk+4x_=UdxX9SdoAQu6RpgCt5qDV79hJh_QUA@mail.gmail.com>
[not found] ` <CAAt2M1_uRxkhsYY8c93LEh=knW1MQF7vNZ_xJbqSJihTFhEuqg@mail.gmail.com>
[not found] ` <CAAt2M187ei5=CvaCjbsLuUM3cHjAb6qs=SeRQdjYBuJxsXSaWw@mail.gmail.com>
[not found] ` <CAAt2M1885LuLJ-2=KL8sEMvutM_U3RFZ-nd25p_3k4-YkBrD=Q@mail.gmail.com>
[not found] ` <CAAt2M19121uJiZu+ctJ0cHqJHp3JCvTHJYC6ACzP3_N+ZfxUHA@mail.gmail.com>
[not found] ` <CAAt2M18VCKgcLDX2Y1Z+hHOehdEOhu4en9JOtNO63_8Y2Ne+rg@mail.gmail.com>
[not found] ` <CAAt2M1--M7rT4khAFADopRig+GA+6n6_6hCK8LbV=cS_YAs+QA@mail.gmail.com>
[not found] ` <CAAt2M1_2MaY55U7mNirP6KTjGbKRu_BMxwLFrRg5pdAd+83trg@mail.gmail.com>
[not found] ` <CAAt2M1-dH3LFsPc-s1iPMQ8mWM4NqY5vmrpxuP1kdjHhNXEqLA@mail.gmail.com>
[not found] ` <CAAt2M18Ty69L_7vfHv8sRmUEnW5K1VZzKRdxDMBANDt10LvD_A@mail.gmail.com>
[not found] ` <CAAt2M1-Sq-+_0tgKOz_gQkCnBx2Lp=ugp2CQKaz97KHLvdcpdw@mail.gmail.com>
[not found] ` <CAAt2M19Woysa0_HM7ZsiF14Tv4hVuRE69Eann=_fpOy2gTQV7A@mail.gmail.com>
[not found] ` <CAAt2M1_itWrpDDVYXOaeQbk6r=B_K9Ow3dD9NvMtU_GGWH5mxA@mail.gmail.com>
[not found] ` <CAAt2M18sQ-q_yyOVqM-am7rjPHz24hOmi+wo1pCVxuMTcNoHww@mail.gmail.com>
[not found] ` <CAAt2M18062gaODy6FHqQw42Mhkg1Srs98W5xADcEgb9GcCn+Mw@mail.gmail.com>
[not found] ` <CAAt2M1_GBXbOi=GUu7mohRqatZGue4DVtPO5CXZmtjKs-vEqEw@mail.gmail.com>
[not found] ` <CAAt2M19UCAfTq+VyE178ASkjPb8EWm4o2zTPf7UGpNuKeeYcJg@mail.gmail.com>
[not found] ` <CAAt2M19oxbgpeOMtonEe2xpoit2imPO4M5XZCw4Sap2VMT8zBQ@mail.gmail.com>
[not found] ` <CAAt2M1_SriFNUcLJfsHNucr3rO8az4BkHVDX0e=_FAproGk6zw@mail.gmail.com>
[not found] ` <CAAt2M19hjVSk1Lv-6qLgVTK1f283bQzRWy+yz-iiWi9_6z4s2w@mail.gmail.com>
[not found] ` <CAAt2M19Lz_FKA-sDbC1P=1RMznd1tWSdpJsbZbH04SeZ-mqJxQ@mail.gmail.com>
[not found] ` <CAAt2M1_+x7Sby-4ygyGPxQv87OhP2wpzP=hZEeUD_Aq9JPFsDw@mail.gmail.com>
[not found] ` <CAAt2M1-cKQNsD-W4yZOkExx=K2d2YM2C93dmDEReFPP3VLa-2Q@mail.gmail.com>
[not found] ` <CAAt2M1-x4H6FK6HL-8F-jr0nDg0VpZGCNkOVeWnP7e_UTUxX-w@mail.gmail.com>
[not found] ` <CAAt2M195V7ynWe5tFd023hs4S06WWZGBXUFKLJfoc-U4Gw99HQ@mail.gmail.com>
[not found] ` <CAAt2M18axXYYd4QDOo+q4_3Fb5-wyZRM9CzZ5G0vrdfMAmG25A@mail.gmail.com>
[not found] ` <CAAt2M187Fvz0s=M5esfGe2q8O2CXdMAfBtTi+eVA9hQ86jYvVw@mail.gmail.com>
[not found] ` <CAAt2M19Pc7LAW2SRCfSOWwNnUNR-dkVfn-6iTdLOBcasrqGs6A@mail.gmail.com>
[not found] ` <CAAt2M18=qpQqPwy95vw+T5tkZTo457cp5ZHnJOkV+0kfCWW7Hg@mail.gmail.com>
[not found] ` <CAAt2M19YGM6j3vRwuM5Oe9F0vjvbTjvqT0AT5-G6ZPQ8npo6uw@mail.gmail.com>
[not found] ` <CAAt2M1_f+BbCEnkaPSCTMgw3oVkiueTr_dF0aDZS1XuZj2bxyg@mail.gmail.com>
[not found] ` <CAAt2M185GrxytKYTwfZUGBmBH8OD2-VQUuxcja5HtFWLg2rsnw@mail.gmail.com>
[not found] ` <CAAt2M18KpJqJpN+cBuXNYHbmsGMn7qa5ZZRP5JYTxLPWE2-G0w@mail.gmail.com>
[not found] ` <CAAt2M1-NO2FErh15A67aigzULWeEPYB6yaR7_RynGr5_DCaRwQ@mail.gmail.com>
[not found] ` <CAAt2M1-nLu69zUPrZhaxLYemd17nh-tMPa6+UYqoeGzufjjxEA@mail.gmail.com>
[not found] ` <CAAt2M1-q8SeBPLFmjNZ-rtBbm2RN1NKN9H-3T0px3w21tEjHPQ@mail.gmail.com>
[not found] ` <CAAt2M1--o0EgVwVi8dM5Rr-PdkPjmv90tE8K7keFMAmGWY7=aA@mail.gmail.com>
[not found] ` <CAAt2M1_2Ajj1BfKRcHzABSt0sDYsc6PAeQfR=VPBG0c1Rmxn0g@mail.gmail.com>
[not found] ` <CAAt2M18EVqAKz8K+QZhVfUZGjeAdP43mQQhmO6_D4i8377Bn+Q@mail.gmail.com>
[not found] ` <CAAt2M19yftfzDLu1vRis_Ui_MZJN65Gy+Lyd+JMdaELfyc4atg@mail.gmail.com>
[not found] ` <CAAt2M1_9V60dbDxvkmYVYPFZWVu6nNzWjS_E0icCKUq9jPZkXQ@mail.gmail.com>
[not found] ` <CAAt2M1-9TJnpY6PAwjrOYU6WKTUY65uJ4Rg5mXXSbmb-NC+1dw@mail.gmail.com>
[not found] ` <CAAt2M1-gyMP+t+z3DrTVQEQmDhm6jdXEs8=Vm9biUCT_bVWNzQ@mail.gmail.com>
[not found] ` <CAAt2M18GKgjhUgSx0eo9XgQDehh2YgV0O2Q6Wbjkzk2dkAjy-w@mail.gmail.com>
[not found] ` <CAAt2M19hUmRaL2QyB37i-3eHtS9RCxrDVUDJGi8qsMyF2DSujQ@mail.gmail.com>
[not found] ` <CAAt2M1_5spX+8JsVykcc8O7jzk2a9cZBvgZm6UQwGDA4v3d+FA@mail.gmail.com>
[not found] ` <CAAt2M1_0hjmtNwLvGbR_BGaMyhJ78+dBN7HxCkMAp-EbnLwhZg@mail.gmail.com>
[not found] ` <CAAt2M18qRi6BQ+=2mabg1+qkgo5E9t-S5Co0uEtL76J_HOdtmg@mail.gmail.com>
[not found] ` <CAAt2M1-McXyTYuMzD+ysv9ZUgPvSRSW7XjqhVKPZqLuS_DLZqw@mail.gmail.com>
[not found] ` <CAAt2M19xJRUQG9ucpQoOQX=NJ9Vsv2wUTemDtNR672yOFNgWqg@mail.gmail.com>
[not found] ` <CAAt2M182Ttc=Q2Zxu+_vtJ+Jp4hoWiY0wHtLd4pX5=iGJUvnAQ@mail.gmail.com>
[not found] ` <CAAt2M18h6w9ctxudjaQLczkUXRRROXH=BmXL=ye45TvOs6w1Fg@mail.gmail.com>
[not found] ` <CAAt2M1-ErU2SLLDFXWFshPABB5mEe-NcORwXvUHxyCP_i47NHw@mail.gmail.com>
[not found] ` <CAAt2M1_9CP0DHGKw-t4s35Rgi-RR9Tw0rYtC1ogyNzvnZT1V+Q@mail.gmail.com>
[not found] ` <CAAt2M1-uNX=VStfcVkRQGX4X1PQAvNKG_p7zCPCMnz=pERhuQg@mail.gmail.com>
[not found] ` <CAAt2M1-eosLcpceRi=VK2+cjxoPDiWc78h8=xBFwFER+=Bd1aQ@mail.gmail.com>
[not found] ` <CAAt2M18hRp8X9RwUTo5oouGGBrvf2FKs+D_jRhMMH+5RPi6Htg@mail.gmail.com>
[not found] ` <CAAt2M19Ucc05MTtPwAV_gVfGY11shDTQ=42jCjLP-YD3jxGq1Q@mail.gmail.com>
[not found] ` <CAAt2M1_2QqqYvf4YKyBZHru441cfv9eLP+W20L9TFhBA2iOz2w@mail.gmail.com>
[not found] ` <CAAt2M18JmZupZwzD+TdQibHHpfgecps5pF+8SKkZVevhvBD=bg@mail.gmail.com>
[not found] ` <CAAt2M1--V_5a6Wqj8BNF_rx4ejbep46iEEWSANu-qTxUsMgWGQ@mail.gmail.com>
[not found] ` <CAAt2M19unyFm5qCDDhGMSSooHk9TeHJs6fAn8kocS9gYY0TvcQ@mail.gmail.com>
[not found] ` <CAAt2M1_omDTW0XK4etoo+vbZLBGSCVGzBKKW3eVm_8GJGqNV9w@mail.gmail.com>
[not found] ` <CAAt2M1-bqeqtB8S1BFQb-Tm2wx=QU8eVSu4gjxS=ZYyT=aL9xg@mail.gmail.com>
[not found] ` <CAAt2M1-LBX=16yO3QdFpKSjFqLErQsW_suWb9fgGrHuHO81eZg@mail.gmail.com>
[not found] ` <CAAt2M1-zxJJ9DdVMXRA9avarjjUbE_TgjhrD-JzwcTK6FtgGeg@mail.gmail.com>
[not found] ` <CAAt2M19a=gd6Pg+BJQpwgdUi7MOUaNw497Zk0hw=FN2ZR2jsXg@mail.gmail.com>
[not found] ` <CAAt2M18D6-hYanWVMUd3pK3BhRL4Q_zFSP_Z4=rPuah2X=o2WA@mail.gmail.com>
[not found] ` <CAAt2M1-ETfspsYX4qAd_d==F9jTAsjHU8p9-Fs-P=KUYD8TRvg@mail.gmail.com>
[not found] ` <CAAt2M18i=L4MFMC+uzNRPwUZbbzCZbuuk2SJTzQqTZLAU64+sw@mail.gmail.com>
[not found] ` <CAAt2M1-quYTuhr9yXKyJzoxPg4vcLeRMTPX5GemJ+hGT4WbDwg@mail.gmail.com>
[not found] ` <CAAt2M18mSF_xPOUmjCWAyOkX=vKC0EdSEvMiBC-eNeZa=2u0_g@mail.gmail.com>
[not found] ` <CAAt2M19LrjODH+t3FJKfdtm2KOUTu1ZX_rF+EZhxoHc-Wi8Fow@mail.gmail.com>
[not found] ` <CAAt2M18QjPrjh9nAjfaZ4QHOdvzC3-2sMoMwBna-Q4r+P=1d_A@mail.gmail.com>
[not found] ` <CAAt2M19U5tXpERL9+Q5f4WMvCOMjoxn6VCemz=Urn4LHPZbfNA@mail.gmail.com>
[not found] ` <CAAt2M1_s2x6H6_sFMBHj1N4Gaft-V3hFiKbSq1f4sCEmsz+NfA@mail.gmail.com>
[not found] ` <CAAt2M18K2MUCa5eCoYsZntr9UaC9ie9rNdAzBi5XKgk_k+a-QA@mail.gmail.com>
[not found] ` <CAAt2M19=HQos=aC4wo2drv-wH1_Br1BCLxKu5AkOJYQFmrkzFQ@mail.gmail.com>
[not found] ` <CAAt2M1-ttJA=tPbVcj6xyGyt_B1jOi0s9f+KDcdEz5R+ewgbow@mail.gmail.com>
[not found] ` <CAAt2M1_-uy4uzN9ViN8ogXYmjr7KPUWmsXuiVgQ_qMoeDDHPvg@mail.gmail.com>
[not found] ` <CAAt2M18ws+P2Yg-6CF3Uff6gOU2NXubG6M2B2aq7XsBZk+BMVQ@mail.gmail.com>
[not found] ` <CAAt2M1_qy4wqpT+Cs+owg8Hbf3GePv3XPGkW-EDJECYJrRmAZQ@mail.gmail.com>
[not found] ` <CAAt2M1-Ty-DXGVd6GnWvWNkDg9MA3+Zqr6-kAOO-0D7iFZ4qeQ@mail.gmail.com>
[not found] ` <CAAt2M198u71tFgdCQZcKJQBJWf4=PRjhA49CbXT8nX5AtqXkyQ@mail.gmail.com>
[not found] ` <CAAt2M1-LZQ1yE1CezFA+hr+=de-RVJ7wzkq-t969BC7OL6dWwg@mail.gmail.com>
2017-03-30 9:34 ` [bitcoin-dev] Block size adjustment idea - expedience fees + difficulty scaling proportional to block size (+ fee pool) Natanael
2017-03-30 10:04 ` Luke Dashjr
[not found] ` <CAAt2M1-57SMT4WT-4_pdkTPyybQgr2ZuQZW_KW2ZwhTQ7HEnqg@mail.gmail.com>
[not found] ` <CAAt2M1-3R7rY55=QgkP8xUs=SDHxyNQV_fshbi89a9KzcwWfLQ@mail.gmail.com>
2017-03-30 10:19 ` Natanael
2017-03-30 18:41 ` Natanael
2017-03-31 4:14 ` Natanael
2017-03-31 4:15 ` Natanael
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox