Re: [bitcoin-dev] new BIP: Self balancing between excessively low/high fees and block size
On Sun, 7 Apr 2019 at 17:45, simondev1 via bitcoin-dev wrote: > ==Implementation== > Sort transactions by FeeInSatoshiPerByte (lowest first) > For each transaction starting from lowest FeeInSatoshiPerByte: Sum up the > bytes of space used so far. Check if summed up bytes of space used so far is > smaller or equal than the formula result. > If this is valid for each transaction then the blocksize is valid. Doesn't this break CPFP? I think to avoid that you'll need to rework your proposed algorithm to treat chains of transactions as a group. (And note that you could have multiple transactions in one block that depend on the same "parent" transaction, also in the same block.) ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] new BIP: Self balancing between excessively low/high fees and block size
Good morning simondev1, It seems the algorithm would greatly increase validation time. In particular, if the current limit is removed (as in hardforked proposal) then a 1Tb block can be used to attack the network, since sorting would require looking through the entire block. Thus, validation time would still limit the practical block sizes that can be deployed with this. Regards, ZmnSCPxj Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Sunday, April 7, 2019 4:50 PM, simondev1 via bitcoin-dev wrote: > Dear bitcoin developers, > > New BIP: https://github.com/bitcoin/bips/pull/774 > > ==Abstract== > Logarithm of transaction fee limits block size. > > ==Motivation== > Keep block space small. > Waste less with spam transactions. > Auto balance Fees: Increase very low fees, Descrease very high fees. > Allow larger size when sender pays a lot. > Allow wallets to calculate/display how much average free block space there is > for each fee price. > Allow senders to have more control about how the fee/priority of their > transaction will behave, especially in the case of increased adoption in the > future. > > ==Specification== > Every transaction has to fit into the following block space: > Input variable 'FeeInSatoshiPerByte': Must be positive or 0 > type: double > unit: Satishi per byte > Output: > type: uint > unit: bytes > Formula: > floor( log10( 1.1 + FeeInSatoshiPerByte ) * 1024 * 1024 ) > > ==Implementation== > Sort transactions by FeeInSatoshiPerByte (lowest first) > For each transaction starting from lowest FeeInSatoshiPerByte: Sum up the > bytes of space used so far. Check if summed up bytes of space used so far is > smaller or equal than the formula result. > If this is valid for each transaction then the blocksize is valid. > > ==Backward compatibility== > Soft fork: If applied AND old hardcoded block size limit is kept. > Hard fork: If applied AND old hardcoded block size limit is removed. > > Regards, simondev1 > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] new BIP: Self balancing between excessively low/high fees and block size
Related ideas previously submitted by me; https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-March/013885.html Title: Block size adjustment idea - expedience fees + difficulty scaling proportional to block size (+ fee pool) Den sön 7 apr. 2019 17:45simondev1 via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> skrev: > Dear bitcoin developers, > > New BIP: https://github.com/bitcoin/bips/pull/774 > > ==Abstract== > Logarithm of transaction fee limits block size. > > ==Motivation== > Keep block space small. > Waste less with spam transactions. > Auto balance Fees: Increase very low fees, Descrease very high fees. > Allow larger size when sender pays a lot. > Allow wallets to calculate/display how much average free block space there > is for each fee price. > Allow senders to have more control about how the fee/priority of their > transaction will behave, especially in the case of increased adoption in > the future. > > ==Specification== > Every transaction has to fit into the following block space: > Input variable 'FeeInSatoshiPerByte': Must be positive or 0 > type: double > unit: Satishi per byte > Output: > type: uint > unit: bytes > Formula: > floor( log10( 1.1 + FeeInSatoshiPerByte ) * 1024 * 1024 ) > > ==Implementation== > Sort transactions by FeeInSatoshiPerByte (lowest first) > For each transaction starting from lowest FeeInSatoshiPerByte: Sum up the > bytes of space used so far. Check if summed up bytes of space used so far > is smaller or equal than the formula result. > If this is valid for each transaction then the blocksize is valid. > > ==Backward compatibility== > Soft fork: If applied AND old hardcoded block size limit is kept. > Hard fork: If applied AND old hardcoded block size limit is removed. > > Regards, simondev1 > > ___ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] new BIP: Self balancing between excessively low/high fees and block size
Dear bitcoin developers, New BIP: https://github.com/bitcoin/bips/pull/774 ==Abstract== Logarithm of transaction fee limits block size. ==Motivation== Keep block space small. Waste less with spam transactions. Auto balance Fees: Increase very low fees, Descrease very high fees. Allow larger size when sender pays a lot. Allow wallets to calculate/display how much average free block space there is for each fee price. Allow senders to have more control about how the fee/priority of their transaction will behave, especially in the case of increased adoption in the future. ==Specification== Every transaction has to fit into the following block space: Input variable 'FeeInSatoshiPerByte': Must be positive or 0 type: double unit: Satishi per byte Output: type: uint unit: bytes Formula: floor( log10( 1.1 + FeeInSatoshiPerByte ) * 1024 * 1024 ) ==Implementation== Sort transactions by FeeInSatoshiPerByte (lowest first) For each transaction starting from lowest FeeInSatoshiPerByte: Sum up the bytes of space used so far. Check if summed up bytes of space used so far is smaller or equal than the formula result. If this is valid for each transaction then the blocksize is valid. ==Backward compatibility== Soft fork: If applied AND old hardcoded block size limit is kept. Hard fork: If applied AND old hardcoded block size limit is removed. Regards, simondev1 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Smart Contracts Unchained
Hi, Apparently you are not a fan of ethereum, as far as I can tell ethereum sidechains look like a mess with stupid tokens/transactions flooding the network while they are completely centralized, but some bitcoin sidechains can easily compete with this too, like Tether, don't even understand how anyone can give some credit to that stuff the way it is implemented, and if bitcoin fails that would be the same as for ethereum Most likely everyone would agree if the escrow disappears, but not sure at all, let's imagine 1 to N put 10K on the table for a game, they update the states and at the end N wins everything, N is rich and don't care finally if the others cheaters have their coins locked (and to lose 10K), same with setting up a new escrow to resolve the conflict I think that you should highlight this (and what private key corresponds to E + h(E | s) * G, not sure it's trivial for everybody), probably a way to get this more decentralized is to reward the escrows (what is the interest here for people to run a smart contract platform?) For lightning, maybe it's a question of wording, I consider it as a sidechain AND methods that can be used by other sidechains, as well as the others you quoted, even if only two people in the world use lightning, it is still decentralized, because it sustains itself alone Regards Aymeric Le 05/04/2019 à 01:52, ZmnSCPxj a écrit : Good morning Aymeric, What if the smart contract platform(s) disappear? It is still possible to recover the funds, *if* you can convince all participants of some "fair" distribution of the funds. You do this by all participants simply signing with their participant keys and taking the first branch of the script. This branch does not require the participation of the smart contract platform, at all. If all participants can agree to the result of the smart contract without dispute, then they can exit the platform even after the platform disappears. Now of course there will be participants who will not cooperate in such a case, for example if they were doing some betting game and "lost". But at least it gives the possibility of doing so, and it will not be as massive a loss. Indeed, if the smart contract platform code is open source, it may be possible to set up another implementation of the smart contract platform. And it would be possible to at least try to convince all participants to switch to that new platform (again, via the "as long as everybody agrees" escape hatch). Again, this is not possible with current federated sidechains, or Ethereum (if Ethereum fails, all ETH becomes valueless). The proposal induces a very centralized system, to my knowledge all of existing sidechains whether on bitcoin or ethereum are centralized, except lightning (if we forget that someone must watch what others are doing when you are on a trek in Nepal) I would not lump together Lightning with sidechains. Indeed, this design moves things closer to true offchain techniques (as in Lightning) than to sidechain techniques. So while centralized, it is less centralized than a federated sidechains. Now I don't get why a sidechain should be a blockchain on top on another one (given also that we can't consider bitcoin or ethereum as decentralized today, so the path might be long for the sidechains...), the latest is used to store the final state, the former does not have to store forever the intermediate states, then it could just use a decentralized system (not necessarilly blockchain-like) to store the intermediate states and maybe be a distributed escrow I know, easy to say, please do it (why not), now the fact that sidechains claim to be decentralized or that they will be is just misleading people (that's not the case of your proposal but it does not say what happens if the platforms go down) Perhaps it can be a next step. Regards, ZmnSCPxj ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
