[Bitcoin-development] The timechain: an idea to solve TX malleability in smart contract protocols without requiring a fork.
I've been tossing around an idea in my head that involves time-locked encryption [0] and I wondered what the devs here think about it. In a nutshell: the timechain is a serial chain of time-lock encrypted GPG keys at N minute intervals (meaning that it requires N minutes to decrypt a single link / key in the chain and each link must be fully decrypted before decryption can start on the next link.) For those not aware of how time-lock encryption works it goes something like this: 1. Choose some random, unique text - this is the initialisation vector or IV. 2. Hash that text -> output. 3. Hash the output -> output. 4. Hash the output -> output. 5. ... 6. Process is repeated for N minutes. 7. Result is then used to generate encryption keys and the public key can be used to time-lock encrypt an arbitrary number of plaintexts. 8. All intermediary results are discarded -- only the pub key is kept and giving out the IV forces an individual to have to repeat the same amount of work used to generate the encryption key. What's interesting about this is that the keys can be generated in parallel and then "stitched" together to form a single serial chain of keys. So potentially, if a person had access to a GPU cluster then they could generate a years worth of work in only 5 minutes. Now imagine if one were to stitch these keys together into a chain of keys at five minute intervals (a structure I refer to as the "timechain"): you could use this structure to encrypt ECDSA keys which could then be used in multi-signature contract schemes as a 100% decentralized, trustless way to execute refunds in contract protocols. Unexpected benefit: time-lock encryption can be used to build unbreakable DACs. Peter Todd has already done work on using Bitcoin to incentivize the decryption process of time-lock encryption [1] but what he may not be aware of is how important this process is for the construction of DACs. Imagine a true peer-to-peer cryptocurrency exchange [2] that time-lock encrypts a chain of ECDSA keys using the timechain and then sets up contracts to pay a small portion of their fees "into" the ECDSA keys. Essentially the exchange has created a DAC that pays its participants to decrypt itself. This is the incentive for the decryption. The reason for the incentive is that another chain of keys can be generate at 5 minute intervals which can be used in contract protocols in place of nTimeLocked refund transactions (which are vulnerable to transaction malleability.) Sample contract using the timechain: 3 of 4 multi-sig: Owner, Owner, Recipient, Timelock Pay N coins to recipient sequentially (micropayment channel) before [time / date], otherwise fall back on timelock decrypted refund key to give full leverage back to owner. This is how smart contracts would work using the timechain for refunds (instead of nTimeLock TXs.) Using the DAC, it might also be possible to force participants to reveal their solutions to the decryption of the timechain (otherwise the first person who starts on the chain would receive all the fees which isn't very fair.) One way to do this would be to use the public key for the fee ECDSA key as the IV used to generate the next key on the chain. To spend the fees would therefore require revealing the public key if the fees were paid to a pay-to-pub-key-hash transaction. A further precaution would be to generate the pay to fee transaction in such a way that the amount needs to be redeemed otherwise another transaction would burn the coins. (I haven't worked out the full details for this but similar schemes have been used successfully, for example in BitHalo [3]. The Lightning Network [4] offers another potential solution.) Perhaps a custom blockchain or sidechain could also be used to award coins for successful (and timely solutions) but this is a subject for future work. In conclusion: I have described a simple way to solve the TX malleability problem in smart contract protocols without requiring a fork or relying on a third-party escrow scheme to manage coins. My solution doesn't require any trust beyond the initial need for the timechain to be generated in a secure cluster and the solution remains secure so long as participants stick to using future keys in the chain regardless of how far along decryption is. What do you think of the idea so far? Obviously the biggest flaw here is that the integrity of a timechain can't be known before-hand but if a timechain were to be generated securely by a reputable party, the biggest benefit of using it is that it basically runs itself: it does not require any third-party to manage its functionality and the entity which originally generated it can completely disappear without interrupting service. This could, for instance - allow companies to create entirely secure and reliable systems that couldn't be hacked as the behaviour of a timechain is deterministic. I think this is a huge improvement over existing systems which require third-parties
Re: [Bitcoin-development] Proposed alternatives to the 20MB step
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/02/2015 04:03 AM, Mike Hearn wrote: (...) > > If you really believe that decentralisation is, itself, the end, > then why not go use an "ASIC resistant" alt coin with no SPV or web > wallets which resembles Bitcoin at the end of 2009? That'd be a > whole lot more decentralised than what you have now. > > The *percentage* of the community that mines is totally > irrelevant, it's the absolute number of (independent) people that > matters. > > > So usage does matter, then? You'd rather have a coin that has > power concentrated in a far smaller elite, proportionally, but has > overall more usage? If there are say, 5000 full nodes today, and in > ten years there are 6000, and they all run in vast datacenters and > are owned by large companies, you'll feel like Bitcoin is more > decentralised than ever? (n.b. I do not think this situation will > ever happen, it's just an example). > Something you said about "power concentrated," made me think I should post this here: https://twitter.com/adam3us/status/608920099609817088 - -- http://abis.io ~ "a protocol concept to enable decentralization and expansion of a giving economy, and a new social good" https://keybase.io/odinn -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJVe8gvAAoJEGxwq/inSG8CcykH/0d+WuPnzFWooCRJR+FwaI4w Ad0z5GSLfYKGnmMMbbqkLsIA2GsfRAvivrsfZYd4slF5C7HEDGa3J/NC72U46dk6 qVm07UNBO3V+loLJtStIQQkg3tVGWjXeiySf4E4b8wlaZiBMS9WW0sAOWUJiGMDQ jKNRpjXobkQGd8C+VJXDpgtmiY60bS4l6j7bbYv+mU6LxhLwCVCqjRJSEN08BH4E AOwJg1qlORHPnrepfeJrB6TVxeHuLjCjWodXQ0jHbNchVQw7zc81gKrD40BJTzyO TTtGPu3JUkcHtx7MVLbIdYNVElqxMS5Li+j9j3h+m9eGSaNgOOl3+8VGJexKPKI= =j5Fh -END PGP SIGNATURE- -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Address Expiration to Prevent Reuse
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I'm way late to this one, I guess, but adding some thoughts here... it seems that anything which mitigates the problem of reuse should be to the maximum extent possible, the user's option... if a person wants to have an address that lasts forever they should be able to have it... if they want to have an address that expires they should be able to have it. The reuse problem is, I think, better solved by the presentation of stealth address proposals, and would be handled by a stealth BIP (BIP 63) which has been recently re-discussed here: https://bitcointalk.org/index.php?topic=1083961.0 On 03/26/2015 02:44 PM, Gregory Maxwell wrote: > On Thu, Mar 26, 2015 at 9:26 PM, Tom Harding > wrote: >> I should have been clearer that the motivation for address >> expiration is to reduce the rate of increase of the massive pile >> of bitcoin addresses out there which have to be monitored >> forever for future payments. It could make a significant dent >> if something like this worked, and were used by default someday. > > Great, that can be accomplished by simply encoding an expiration > into the address people are using and specifying that clients > enforce it. > > -- - > > > Dive into the World of Parallel Programming The Go Parallel Website, sponsored > by Intel and developed in partnership with Slashdot Media, is your > hub for all things parallel software development, from weekly > thought leadership blogs to news, videos, case studies, tutorials > and more. Take a look and join the conversation now. > http://goparallel.sourceforge.net/ > ___ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > - -- http://abis.io ~ "a protocol concept to enable decentralization and expansion of a giving economy, and a new social good" https://keybase.io/odinn -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJVe7cJAAoJEGxwq/inSG8C2uwH/2UfTX+6CEssv5ZhiwwqVNWk bmlODZulsJK0FIIcz2oVtMvnMR7L8DX/XtFOdiVTk/wOn7vc7X/DZ9UVKSixKCLJ IJLzBKEzFzMmNhxXv9fPsefuMsMlTkhifykl2BOp0T2gMEr5GweKSqn9XpQuo9mb LhS5vqNCRw0X3eQ5sIalSfmK3ghP5yaU+orhFjvb3QJ/JN3mxgXyl3xLx9diPVdu 2I1QoxzCyE/tlEnxZGPrCtGe3d93mPhEFGGeiP+7eW8TkJa5AGCg3QWbzniC3Nsv gjg6rCbLKtj300hH0glbPT96YO+r9l5itox+aArkCtNnR+/HlUb6zubgqebzPuc= =KZQe -END PGP SIGNATURE- -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Various block size proposals
Thanks Bryan for collating these links in one great list. This is very helpful and thanks for sharing it. Feel free to fork https://github.com/EthanHeilman/BlockSizeDebate edit to add the list of proposals and create a pull request to Ethan. There's also a miningconsensus.slack.com group to have discussion w.r.t. fact/source checking, completeness (e.g. from IRC) etc. Tks. p. On Sat, Jun 13, 2015 at 3:13 AM, Bryan Bishop wrote: > Here are some proposals regarding the minimum block size questions, as > well as other related scalability issues. > > Dynamic block size limit controller (maaku) > > https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg07599.html > > https://www.reddit.com/r/Bitcoin/comments/35c47x/a_proposal_to_expand_the_block_size/ > > Re: dynamic block size limit controller (gmaxwell) > > https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg07620.html > > Various other gmaxwell-relayed ideas > > http://www.reddit.com/r/Bitcoin/comments/37pv74/gavin_andresen_moves_ahead_with_push_for_bigger/crp2735 > > Increasing the max block size using a soft-fork (Tier Nolan) > > https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg07927.html > > Elastic block cap with rollover penalties (Meni Rosenfield) > https://bitcointalk.org/index.php?topic=1078521 > worked example > https://bitcointalk.org/index.php?topic=1078521.msg11557115#msg11557115 > section 6.2.3 of https://cryptonote.org/whitepaper.pdf > rollover transaction fees https://bitcointalk.org/index.php?topic=80387.0 > > Variable mining effort (gmaxwell) > http://sourceforge.net/p/bitcoin/mailman/message/34100485/ > > BIP100 Soft-fork limit of 2 MB (jgarzik) > http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf > > Transaction fee targeting > https://bitcointalk.org/index.php?topic=176684.msg9416723#msg9416723 > > Difficulty target scaling > > https://www.reddit.com/r/Bitcoin/comments/38937n/idea_make_the_difficulty_target_scale_with_block/ > > Annual 50% max block size increase > > https://www.reddit.com/r/Bitcoin/comments/351dft/what_about_gavins_2014_proposal_of_having_block/ > > Various algorithmic adjustment proposals > https://bitcointalk.org/index.php?topic=1865.0 > > https://www.reddit.com/r/Bitcoin/comments/1owbpn/is_there_a_consensus_on_the_blocksize_limit_issue/ccwd7xh > > https://www.reddit.com/r/Bitcoin/comments/35azxk/screw_the_hard_limit_lets_change_the_block_size/ > > https://www.reddit.com/r/Bitcoin/comments/359y0i/quick_question_about_the_block_size_limit_issue/ > > http://www.reddit.com/r/Bitcoin/comments/385xqj/what_if_block_size_limits_were_set_to_increase/ > http://www.age-of-bitcoin.com/dynamic-block-size-cap-scaling/ > (against) > http://garzikrants.blogspot.com/2013/02/bitcoin-block-size-thoughts.html > > Average over last 144 blocks > > http://www.reddit.com/r/Bitcoin/comments/38fmra/max_block_size_2_average_size_of_last_144_blocks/ > > Extension blocks (Adam Back) (why would he burn this idea for something so > trivial?) > > https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg07937.html > > https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg08005.html > > http://www.reddit.com/r/Bitcoin/comments/39kqzs/how_about_a_softfork_optin_blocksize_increase/ > > http://www.reddit.com/r/Bitcoin/comments/39hgzc/blockstream_cofounder_president_adam_back_phd_on/cs3tgss > > Voting by paying to an address (note: vote censorship makes this > impractical, among other reasons) > > http://www.reddit.com/r/Bitcoin/comments/3863vw/a_brandnew_idea_for_resolving_the_blocksize_debate/ > > http://www.reddit.com/r/Bitcoin/comments/1g0ywj/proposal_we_should_vote_on_the_blocksize_limit/ > > https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg02325.html > > Vote by paying fees > > https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg08164.html > > https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg02323.html > > Double the max block size at each block reward halving > > https://www.reddit.com/r/Bitcoin/comments/359jdc/just_double_the_max_blocksize_on_every_block/ > > Reducing the block rate instead of increasing the maximum block size > (Sergio Lerner) > > https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg07663.html > > https://www.reddit.com/r/Bitcoin/comments/35kpgk/sergio_lerner_on_bitcoindevelopment_reducing_the/ > > Decrease block interval > > https://www.reddit.com/r/Bitcoin/comments/2vefmp/please_eli5_besides_increasing_the_block_size_why/ > > https://www.reddit.com/r/Bitcoin/comments/35hpkt/please_remind_me_once_again_why_we_cant_decrease/ > > Increase default soft block size limit in Bitcoin Core > > http://www.reddit.com/r/Bitcoin/comments/38i6qr/why_not_increase_the_default_block_size_limit/ > https://github.com/bitcoin/bitcoin/pull/6231 > > Consider the size of the utxo set when determining max block size (note > that utxo de
Re: [Bitcoin-development] User vote in blocksize through fees
On Fri, Jun 12, 2015 at 1:04 PM, Eric Lombrozo wrote: > Miners currently only collect an almost negligible portion of their > revenue from fees. Then they shouldn't care about the block size limit, since an increase in block size (and thus in the number of txs they get fees from) will only increase their revenue "negligibly". -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] User vote in blocksize through fees
On Friday, June 12, 2015 11:01:02 PM Vincent Truong wrote: > RE: miner economics > Miners who have an agenda can forego fees to achieve it and create their > own txns if it is completely txn/user driven. It is better to just count > miners votes and let the user votes be their backing. Just simplify this? Allow a miner to have their block counted as votes for X provided not a single transaction they include votes against it. Then miners can explicitly forego the fees of opposing transactions without having to bloat blocks. Luke -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] User vote in blocksize through fees
(Sorry for spam, forgot to cc the mailing list) RE: miner economics Miners who have an agenda can forego fees to achieve it and create their own txns if it is completely txn/user driven. It is better to just count miners votes and let the user votes be their backing. Although miners need to include txns that have the same vote as them, or you expect them be able to vote themselves with their own txns, with backing eventually there will be a large pool of unconfirmed txns that vote against them. Which means a juicy choice of fees for an honest or small miner to vote the other way (if there are any). If the votes are required to be near unanimous (almost 100%) rather than majority rule, there will be a small miner out there who will vote honestly and reset the vote on behalf of those users, because there is a fee incentive to do so (a pure honest miner doesn't care about fees. But they're a dying breed). If it is a majority rule type of vote, bigger miners will set the vote direction and small miners have no say no matter how they vote. From a decentralisation perspective, it is better to want the big guns to have a small voice, otherwise it will tend towards centralisation. Troll users (voting against when the direction is very clear) can still be ignored by excluding their txns unless they're paying attractive fees. (So it isn't exactly 100%, but it'll be close). Miners have some power but ultimately they will represent the users if the users votes are clearly divided. If you think 100% is hard, 95-90% could be a compromise but that requires an assumption that at least 5-10% will have their voices unheard. And that might be OK. Personally, 100% is consensus, anything less is just a democracy. RE: vote bits I think letting a vote go up and down in the same vote is a strange one. Personally I think binary votes simplify the process. Would it be better to 'announce' a vote that will contain a certain change. For example, hash of a config file that said change MAX_BLOCK_SIZE -> 8mb. More things can use the same mechanism by including changes in a config (or whatever script/markup) file as needed in the future, for whichever constants you want to expose to votes. Votes can just be 0 and 1 for no/yes and omitted for neutral. My preference is 1 for yes, 0 for no neutral/ignored and omitted for no, so that it is backwards compatible and doesn't skew votes to the agreeing direction, and forces node owners and wallet developers to upgrade and participate. On Jun 13, 2015 6:04 AM, "Eric Lombrozo" wrote: > Miners currently only collect an almost negligible portion of their > revenue from fees. While I certainly welcome any proposals that move us in > the direction of defining a smooth metaconsensus process, I think with the > curent economics, miners (and especially those with significant hashing > power) have more of an incentive to block txs/spam their votes than to > adapt to tx sender preferences...unless people increase their tx fees > significantly. But without wallets that can make decent suggestions in this > regard, this feature will be almost inaccessible to most regular users. And > the economics still aren't entirely clear. > > - Eric Lombrozo > On Jun 12, 2015 12:30 PM, "Jannes Faber" wrote: > > I'm imagining in Peter's proposal it's not the transaction votes that are > counted but only the votes in the blocks? So miners get to vote but they > risk losing money by having to exclude counter voting transactions. But > garbage transactions are no problem at all. > > Note that users that want to cast a vote "pay" for that by increased > confirmation time (on average, hopefully slightly depending on the trend). > > On Fri, Jun 12, 2015, 20:27 Matt Whitlock wrote: > >> On Friday, 12 June 2015, at 11:20 am, Mark Friedenbach wrote: >> > Peter it's not clear to me that your described protocol is free of miner >> > influence over the vote, by artificially generating transactions which >> they >> > claim in their own blocks >> >> Miners could fill their blocks with garbage transactions that agree with >> their vote, but this wouldn't bring them any real income, as they'd be >> paying their own money as fees to themselves. To get real income, miners >> would have to vote in accordance with real users. >> >> >> -- >> ___ >> Bitcoin-development mailing list >> Bitcoin-development@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development >> > > > -- > > ___ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > > > -- > > ___ > Bi
Re: [Bitcoin-development] Lexicographical Indexing of Transaction Inputs and Outputs
Since everyone's busy, I went ahead and made a pull request to add this as an informational BIP 79 to the bips directory. https://github.com/bitcoin/bips/pull/157 Regards, Kristov On Tue, Jun 9, 2015 at 4:14 PM, Peter Todd wrote: > On Mon, Jun 08, 2015 at 06:53:54PM -0400, Kristov Atlas wrote: > > Two other things: > > > > > On Sat, Jun 6, 2015 at 10:35 PM, Peter Todd wrote: > > > > > Why mention SIGHASH_SINGLE at all? Its use-case is highly specialized > > > protocols; you haven't taken into account the needs of those protocols. > > > For BIP's it's better to stick to the use-cases where the need is clear > > > and there exists running code that to speculate too much on future > uses. > > > With signature hashing in particular it's not yet clear at all what > > > future OP_CHECKSIG's will look like, let alone the various ways people > > > will use sighash for smart contract type stuff. > > > > > > You'd be better off presenting the BIP in terms of a generic statement > > > that "except when otherwise prevented by advanced signature hashing > > > requirements, wallet software must emit transactions sorted according > to > > > the following" You can then specify the two common cases in detail: > > > > > > 1) SIGHASH_ALL: input and output order signed, so sort appropriately > > > > > > 2) SIGHASH_ANYONECANPAY: input order not signed, so software should > emit > > >transactions sorted, recognising that the actual mined order may be > > >changed. > > > > > > > That makes sense. I updated the language as follows -- your thoughts? > Keep > > in mind this BIP is informational, and so people are free to ignore it. > > > > "Applicability: This BIP applies to all transactions of signature hash > type > > SIGHASH_ALL. Additionally, software compliant with this BIP that allows > > later parties to update the transaction (e.g. using signature hash types > > SIGHASH_NONE or a variant of SIGHASH_ANYONECANPAY) should emit > > lexicographically sorted inputs and outputs, although they may later be > > modified. Transactions that have index dependencies between transactions > or > > within the same transaction are covered under the section of this BIP > > entitled “Handling Input/Output Dependencies.”" > > I'd keep it even simpler than that, and just say for now that such > use-cases are out of the scope of this BIP, however those standards > should come up with some kind of deterministic standard that meets the > needs of the protocol. Again, there's a bunch of possible use-cases here > and we just can't predict them; focus on the fact that the *spirit* of > what this BIP is about is applicable and future standards should be > developed. > > So I'd change the "Applicability" section to: > > This BIP applies to all transactions where the order of inputs and > outputs does not matter. This is true for the vast majority of > transactions as they simply move funds from one place to another. > > Currently this generally refers to transactions where SIGHASH_ALL is > used, in which case the signatures commit to the exact order of input > and outputs. In the case where SIGHASH_ANYONECANPAY and/or SIGHASH_NONE > has been used (e.g. crowdfunds) the order of inputs and/or outputs may > not be signed, however compliant software should still emit transactions > with sorted inputs and outputs, even though they may later be modified > by others. > > In the event that future protocol upgrades introduce new signature hash > types, compliant software should apply the lexographic ordering > principle analogously. > > While out of scope of this BIP, protocols that do require a specified > order of inputs/outputs (e.g. due to use of SIGHASH_SINGLE) should > consider the goals of this BIP and how best to adapt them to the > specifics needs of those protocols. > > > Then remove the "handling input/output deps" section. > > > > Do you have a patch implementing deterministic tx ordering for Bitcoin > > > Core yet? > > > > > > > I'm not a frequent C programmer, so I'd prefer to let someone else take > > care of it, as a frequent committer of code would do a faster and more > > stylistically consistent job of it. If no one else will, however, I will. > > > > re: the actual ordering algorithm, having txids be sorted by with the > hex-based algorithm is odd. I'd simply say they're sorted as > little-endian byte arrays, or in other words, with the bytearr_cmp() > function, but with the order of bytes reversed. You also should say that > we're doing that to make the user see them in visually sorted order to > match expectations because txids are displayed as little-endian. > > For outputs, don't say "locking script", say "scriptPubKey". Secondly, > scriptPubKeys are not in little-endian representation - they have no > endianness to them. With output amount, there's no need to say that > they're unsigned or little-endian satoshies, just say they're sorted > largest/smallest amount first. > > "For the sake of efficiency, amounts will be con
Re: [Bitcoin-development] User vote in blocksize through fees
Miners currently only collect an almost negligible portion of their revenue from fees. While I certainly welcome any proposals that move us in the direction of defining a smooth metaconsensus process, I think with the curent economics, miners (and especially those with significant hashing power) have more of an incentive to block txs/spam their votes than to adapt to tx sender preferences...unless people increase their tx fees significantly. But without wallets that can make decent suggestions in this regard, this feature will be almost inaccessible to most regular users. And the economics still aren't entirely clear. - Eric Lombrozo On Jun 12, 2015 12:30 PM, "Jannes Faber" wrote: I'm imagining in Peter's proposal it's not the transaction votes that are counted but only the votes in the blocks? So miners get to vote but they risk losing money by having to exclude counter voting transactions. But garbage transactions are no problem at all. Note that users that want to cast a vote "pay" for that by increased confirmation time (on average, hopefully slightly depending on the trend). On Fri, Jun 12, 2015, 20:27 Matt Whitlock wrote: > On Friday, 12 June 2015, at 11:20 am, Mark Friedenbach wrote: > > Peter it's not clear to me that your described protocol is free of miner > > influence over the vote, by artificially generating transactions which > they > > claim in their own blocks > > Miners could fill their blocks with garbage transactions that agree with > their vote, but this wouldn't bring them any real income, as they'd be > paying their own money as fees to themselves. To get real income, miners > would have to vote in accordance with real users. > > > -- > ___ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Bip 32 Question
The `n` is the curve order, as shown here: https://en.bitcoin.it/wiki/Secp256k1 This step is necessary to keep you on the curve. The secp256k1_ec_privkey_tweak_add function from libsecp256k1 handles this automatically, but if you use OpenSSL or some non-EC math library, you probably have to do it yourself. -William On Fri, Jun 12, 2015 at 11:22 AM, James Poole wrote: > Looking at the BIP32 definition, I hit a line that I would appreciate > clarification on. > > https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki > > Under the section "Private parent key → private child key" there is a step: > > "The returned child key ki is parse256(IL) + kpar (mod n)." > > Can someone help me understand what "n" is in the context of this algorithm? > I very well could be looking right at it, but wanted to double check if I am > missing something. > > Thanks, > James -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] User vote in blocksize through fees
I'm imagining in Peter's proposal it's not the transaction votes that are counted but only the votes in the blocks? So miners get to vote but they risk losing money by having to exclude counter voting transactions. But garbage transactions are no problem at all. Note that users that want to cast a vote "pay" for that by increased confirmation time (on average, hopefully slightly depending on the trend). On Fri, Jun 12, 2015, 20:27 Matt Whitlock wrote: > On Friday, 12 June 2015, at 11:20 am, Mark Friedenbach wrote: > > Peter it's not clear to me that your described protocol is free of miner > > influence over the vote, by artificially generating transactions which > they > > claim in their own blocks > > Miners could fill their blocks with garbage transactions that agree with > their vote, but this wouldn't bring them any real income, as they'd be > paying their own money as fees to themselves. To get real income, miners > would have to vote in accordance with real users. > > > -- > ___ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Various block size proposals
Here are some proposals regarding the minimum block size questions, as well as other related scalability issues. Dynamic block size limit controller (maaku) https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg07599.html https://www.reddit.com/r/Bitcoin/comments/35c47x/a_proposal_to_expand_the_block_size/ Re: dynamic block size limit controller (gmaxwell) https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg07620.html Various other gmaxwell-relayed ideas http://www.reddit.com/r/Bitcoin/comments/37pv74/gavin_andresen_moves_ahead_with_push_for_bigger/crp2735 Increasing the max block size using a soft-fork (Tier Nolan) https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg07927.html Elastic block cap with rollover penalties (Meni Rosenfield) https://bitcointalk.org/index.php?topic=1078521 worked example https://bitcointalk.org/index.php?topic=1078521.msg11557115#msg11557115 section 6.2.3 of https://cryptonote.org/whitepaper.pdf rollover transaction fees https://bitcointalk.org/index.php?topic=80387.0 Variable mining effort (gmaxwell) http://sourceforge.net/p/bitcoin/mailman/message/34100485/ BIP100 Soft-fork limit of 2 MB (jgarzik) http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf Transaction fee targeting https://bitcointalk.org/index.php?topic=176684.msg9416723#msg9416723 Difficulty target scaling https://www.reddit.com/r/Bitcoin/comments/38937n/idea_make_the_difficulty_target_scale_with_block/ Annual 50% max block size increase https://www.reddit.com/r/Bitcoin/comments/351dft/what_about_gavins_2014_proposal_of_having_block/ Various algorithmic adjustment proposals https://bitcointalk.org/index.php?topic=1865.0 https://www.reddit.com/r/Bitcoin/comments/1owbpn/is_there_a_consensus_on_the_blocksize_limit_issue/ccwd7xh https://www.reddit.com/r/Bitcoin/comments/35azxk/screw_the_hard_limit_lets_change_the_block_size/ https://www.reddit.com/r/Bitcoin/comments/359y0i/quick_question_about_the_block_size_limit_issue/ http://www.reddit.com/r/Bitcoin/comments/385xqj/what_if_block_size_limits_were_set_to_increase/ http://www.age-of-bitcoin.com/dynamic-block-size-cap-scaling/ (against) http://garzikrants.blogspot.com/2013/02/bitcoin-block-size-thoughts.html Average over last 144 blocks http://www.reddit.com/r/Bitcoin/comments/38fmra/max_block_size_2_average_size_of_last_144_blocks/ Extension blocks (Adam Back) (why would he burn this idea for something so trivial?) https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg07937.html https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg08005.html http://www.reddit.com/r/Bitcoin/comments/39kqzs/how_about_a_softfork_optin_blocksize_increase/ http://www.reddit.com/r/Bitcoin/comments/39hgzc/blockstream_cofounder_president_adam_back_phd_on/cs3tgss Voting by paying to an address (note: vote censorship makes this impractical, among other reasons) http://www.reddit.com/r/Bitcoin/comments/3863vw/a_brandnew_idea_for_resolving_the_blocksize_debate/ http://www.reddit.com/r/Bitcoin/comments/1g0ywj/proposal_we_should_vote_on_the_blocksize_limit/ https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg02325.html Vote by paying fees https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg08164.html https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg02323.html Double the max block size at each block reward halving https://www.reddit.com/r/Bitcoin/comments/359jdc/just_double_the_max_blocksize_on_every_block/ Reducing the block rate instead of increasing the maximum block size (Sergio Lerner) https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg07663.html https://www.reddit.com/r/Bitcoin/comments/35kpgk/sergio_lerner_on_bitcoindevelopment_reducing_the/ Decrease block interval https://www.reddit.com/r/Bitcoin/comments/2vefmp/please_eli5_besides_increasing_the_block_size_why/ https://www.reddit.com/r/Bitcoin/comments/35hpkt/please_remind_me_once_again_why_we_cant_decrease/ Increase default soft block size limit in Bitcoin Core http://www.reddit.com/r/Bitcoin/comments/38i6qr/why_not_increase_the_default_block_size_limit/ https://github.com/bitcoin/bitcoin/pull/6231 Consider the size of the utxo set when determining max block size (note that utxo depth cannot have consensus) https://bitcointalk.org/index.php?topic=153401.20 Reduce and decrease the max block size https://www.reddit.com/r/Bitcoin/comments/381ygv/who_is_in_favour_of_reducing_the_blocksize_limit/ https://www.reddit.com/r/Bitcoin/comments/2vedt4/better_we_make_block_size_50kb_and_test/ Change the value of MAX_BLOCK_SIZE in Bitcoin Core https://bitcointalk.org/index.php?topic=140233.0 Problems with floating block size limits (petertodd) https://bitcointalk.org/index.php?topic=144895.0 Develop other ways to support high transaction volumes (gavinandresen) https://bitcointalk.org/index.php?topic=96097.msg1059475#msg10594
Re: [Bitcoin-development] User vote in blocksize through fees
For the purposes of finding the median, halve < same < double. It will only
change if a majority of non-apathetic votes are for halve or a majority of
non-apathetic votes are for double.
On Fri, Jun 12, 2015 at 11:54 AM, Matt Whitlock
wrote:
> On Friday, 12 June 2015, at 7:44 pm, Peter Todd wrote:
> > On Fri, Jun 12, 2015 at 02:36:31PM -0400, Matt Whitlock wrote:
> > > On Friday, 12 June 2015, at 7:34 pm, Peter Todd wrote:
> > > > On Fri, Jun 12, 2015 at 02:22:36PM -0400, Matt Whitlock wrote:
> > > > > Why should miners only be able to vote for "double the limit" or
> "halve" the limit? If you're going to use bits, I think you need to use two
> bits:
> > > > >
> > > > > 0 0 = no preference ("wildcard" vote)
> > > > > 0 1 = vote for the limit to remain the same
> > > > > 1 0 = vote for the limit to be halved
> > > > > 1 1 = vote for the limit to be doubled
> > > > >
> > > > > User transactions would follow the same usage. In particular, a
> user vote of "0 0" (no preference) could be included in a block casting any
> vote, but a block voting "0 0" (no preference) could only contain
> transactions voting "0 0" as well.
> > > >
> > > > Sounds like a good encoding to me. Taking the median of the three
> > > > options, and throwing away "don't care" votes entirely, makes sense.
> > >
> > > I hope you mean the *plurality* of the three options after throwing
> away the "don't cares," not the *median*.
> >
> > Median ensures that voting "no change" is meaningful. If "double" + "no
> > change" = 66%-1, you'd expect the result to be "no change", not "halve""
> > With a plurality vote you'd end up with a halving that was supported by
> > a minority.
>
> Never mind. I think I've figured out what you're getting at, and you're
> right. We wouldn't want "halve" to win on a plurality just because the
> remaining majority of the vote was split between double and
> remain-the-same. Good catch. :)
>
>
> --
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--
J. Aaron Gustafson
Cornell University '16 | Computer Science, Engineering | Mathematics, Arts
& Sciences
Vice President, Kappa Delta Rho
jag...@cornell.edu | Ithaca, New York
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] User vote in blocksize through fees
On Friday, 12 June 2015, at 7:44 pm, Peter Todd wrote:
> On Fri, Jun 12, 2015 at 02:36:31PM -0400, Matt Whitlock wrote:
> > On Friday, 12 June 2015, at 7:34 pm, Peter Todd wrote:
> > > On Fri, Jun 12, 2015 at 02:22:36PM -0400, Matt Whitlock wrote:
> > > > Why should miners only be able to vote for "double the limit" or
> > > > "halve" the limit? If you're going to use bits, I think you need to use
> > > > two bits:
> > > >
> > > > 0 0 = no preference ("wildcard" vote)
> > > > 0 1 = vote for the limit to remain the same
> > > > 1 0 = vote for the limit to be halved
> > > > 1 1 = vote for the limit to be doubled
> > > >
> > > > User transactions would follow the same usage. In particular, a user
> > > > vote of "0 0" (no preference) could be included in a block casting any
> > > > vote, but a block voting "0 0" (no preference) could only contain
> > > > transactions voting "0 0" as well.
> > >
> > > Sounds like a good encoding to me. Taking the median of the three
> > > options, and throwing away "don't care" votes entirely, makes sense.
> >
> > I hope you mean the *plurality* of the three options after throwing away
> > the "don't cares," not the *median*.
>
> Median ensures that voting "no change" is meaningful. If "double" + "no
> change" = 66%-1, you'd expect the result to be "no change", not "halve""
> With a plurality vote you'd end up with a halving that was supported by
> a minority.
Never mind. I think I've figured out what you're getting at, and you're right.
We wouldn't want "halve" to win on a plurality just because the remaining
majority of the vote was split between double and remain-the-same. Good catch.
:)
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] User vote in blocksize through fees
On Friday, 12 June 2015, at 7:44 pm, Peter Todd wrote:
> On Fri, Jun 12, 2015 at 02:36:31PM -0400, Matt Whitlock wrote:
> > On Friday, 12 June 2015, at 7:34 pm, Peter Todd wrote:
> > > On Fri, Jun 12, 2015 at 02:22:36PM -0400, Matt Whitlock wrote:
> > > > Why should miners only be able to vote for "double the limit" or
> > > > "halve" the limit? If you're going to use bits, I think you need to use
> > > > two bits:
> > > >
> > > > 0 0 = no preference ("wildcard" vote)
> > > > 0 1 = vote for the limit to remain the same
> > > > 1 0 = vote for the limit to be halved
> > > > 1 1 = vote for the limit to be doubled
> > > >
> > > > User transactions would follow the same usage. In particular, a user
> > > > vote of "0 0" (no preference) could be included in a block casting any
> > > > vote, but a block voting "0 0" (no preference) could only contain
> > > > transactions voting "0 0" as well.
> > >
> > > Sounds like a good encoding to me. Taking the median of the three
> > > options, and throwing away "don't care" votes entirely, makes sense.
> >
> > I hope you mean the *plurality* of the three options after throwing away
> > the "don't cares," not the *median*.
>
> Median ensures that voting "no change" is meaningful. If "double" + "no
> change" = 66%-1, you'd expect the result to be "no change", not "halve""
> With a plurality vote you'd end up with a halving that was supported by
> a minority.
I'm very confused.
Let's say, out of the 12,000 blocks in a voting period:
• 1000 blocks express no preference,
• 2000 blocks vote to halve the limit,
• 3500 blocks vote to double the limit, and
• 5500 blocks vote to keep the limit the same.
The plurality vote is to keep the limit the same. The median vote is… well,
I'm not sure, since there are four choices, and an average of the two "middle"
choices doesn't seem to make sense.
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Bip 32 Question
Looking at the BIP32 definition, I hit a line that I would appreciate clarification on. https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki Under the section "Private parent key → private child key" there is a step: "The returned child key ki is parse256(IL) + kpar (mod n)." Can someone help me understand what "n" is in the context of this algorithm? I very well could be looking right at it, but wanted to double check if I am missing something. Thanks, James -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] User vote in blocksize through fees
On Fri, Jun 12, 2015 at 08:39:21PM +0200, Benjamin wrote: > This is a misguided idea, to say the least. If such a mechanism of of > user input would be possible, one would use it for transaction > verification in the first place. In proof-of-stake outcomes are > determined by vote by stake (that vote has very different > characteristics than vote by compute power). There is no such thing as > making it possible to determine what "users want". That's what the > proof-of-work mechanism does in the first place, only that it is now > unfortunately skewed/corrupted/(whatever you want to call it). Before > centralization the concept of "miners" didn't exist in Bitcoin and > miners were roughly identical to users. Peer-to-Peer implies only one > class of users. > > A big problem with such a vote (in PoW and PoS): miners get paid for > their work and have incentives to raise fees. Those who pay fees would > have no say in whether those fees are fair or not. Transaction > verification has to be roughly profitable, but there is no fixed > formula for determining profitability. Read John Dillon's proposal then, which via proof-of-stake explicitly approportions control of increases via % of Bitcoin owned. Anyway, representing everyone is never going to be easy, but at least this nVersion thing is very easy to implement. -- 'peter'[:-1]@petertodd.org 127ab1d576dc851f374424f1269c4700ccaba2c42d97e778 signature.asc Description: Digital signature -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] User vote in blocksize through fees
On Fri, Jun 12, 2015 at 02:36:31PM -0400, Matt Whitlock wrote:
> On Friday, 12 June 2015, at 7:34 pm, Peter Todd wrote:
> > On Fri, Jun 12, 2015 at 02:22:36PM -0400, Matt Whitlock wrote:
> > > Why should miners only be able to vote for "double the limit" or "halve"
> > > the limit? If you're going to use bits, I think you need to use two bits:
> > >
> > > 0 0 = no preference ("wildcard" vote)
> > > 0 1 = vote for the limit to remain the same
> > > 1 0 = vote for the limit to be halved
> > > 1 1 = vote for the limit to be doubled
> > >
> > > User transactions would follow the same usage. In particular, a user vote
> > > of "0 0" (no preference) could be included in a block casting any vote,
> > > but a block voting "0 0" (no preference) could only contain transactions
> > > voting "0 0" as well.
> >
> > Sounds like a good encoding to me. Taking the median of the three
> > options, and throwing away "don't care" votes entirely, makes sense.
>
> I hope you mean the *plurality* of the three options after throwing away the
> "don't cares," not the *median*.
Median ensures that voting "no change" is meaningful. If "double" + "no
change" = 66%-1, you'd expect the result to be "no change", not "halve""
With a plurality vote you'd end up with a halving that was supported by
a minority.
--
'peter'[:-1]@petertodd.org
127ab1d576dc851f374424f1269c4700ccaba2c42d97e778
signature.asc
Description: Digital signature
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] User vote in blocksize through fees
This is a misguided idea, to say the least. If such a mechanism of of
user input would be possible, one would use it for transaction
verification in the first place. In proof-of-stake outcomes are
determined by vote by stake (that vote has very different
characteristics than vote by compute power). There is no such thing as
making it possible to determine what "users want". That's what the
proof-of-work mechanism does in the first place, only that it is now
unfortunately skewed/corrupted/(whatever you want to call it). Before
centralization the concept of "miners" didn't exist in Bitcoin and
miners were roughly identical to users. Peer-to-Peer implies only one
class of users.
A big problem with such a vote (in PoW and PoS): miners get paid for
their work and have incentives to raise fees. Those who pay fees would
have no say in whether those fees are fair or not. Transaction
verification has to be roughly profitable, but there is no fixed
formula for determining profitability.
On Fri, Jun 12, 2015 at 8:26 PM, Matt Whitlock wrote:
> On Friday, 12 June 2015, at 11:20 am, Mark Friedenbach wrote:
>> Peter it's not clear to me that your described protocol is free of miner
>> influence over the vote, by artificially generating transactions which they
>> claim in their own blocks
>
> Miners could fill their blocks with garbage transactions that agree with
> their vote, but this wouldn't bring them any real income, as they'd be paying
> their own money as fees to themselves. To get real income, miners would have
> to vote in accordance with real users.
>
> --
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
On Fri, Jun 12, 2015 at 8:34 PM, Peter Todd wrote:
> On Fri, Jun 12, 2015 at 02:22:36PM -0400, Matt Whitlock wrote:
>> Why should miners only be able to vote for "double the limit" or "halve" the
>> limit? If you're going to use bits, I think you need to use two bits:
>>
>> 0 0 = no preference ("wildcard" vote)
>> 0 1 = vote for the limit to remain the same
>> 1 0 = vote for the limit to be halved
>> 1 1 = vote for the limit to be doubled
>>
>> User transactions would follow the same usage. In particular, a user vote of
>> "0 0" (no preference) could be included in a block casting any vote, but a
>> block voting "0 0" (no preference) could only contain transactions voting "0
>> 0" as well.
>
> Sounds like a good encoding to me. Taking the median of the three
> options, and throwing away "don't care" votes entirely, makes sense.
>
>> Incidentally, I love this idea, as it addresses a concern I immediately had
>> with Jeff's proposal, which is that it hands control exclusively to the
>> miners. And your proposal here fixes that shortcoming in a economically
>> powerful way: miners lose out on fees if they don't represent the wishes of
>> the users.
>
> Thanks! I personally expect disaster to ensue with this kind of
> proposal, but I'm less concerned if the disaster is something users
> explicitly allowed to happen in a consensual way.
>
> --
> 'peter'[:-1]@petertodd.org
> 127ab1d576dc851f374424f1269c4700ccaba2c42d97e778
>
> --
>
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
On Fri, Jun 12, 2015 at 8:36 PM, Peter Todd wrote:
> On Fri, Jun 12, 2015 at 02:26:20PM -0400, Matt Whitlock wrote:
>> On Friday, 12 June 2015, at 11:20 am, Mark Friedenbach wrote:
>> > Peter it's not clear to me that your described protocol is free of miner
>> > influence over the vote, by artificially generating transactions which they
>> > claim in their own blocks
>>
>> Miners could fill their blocks with garbage transactions that agree with
>> their vote, but this wouldn't bring them any real income, as they'd be
>> paying their own money as fees to themselves. To get real income, miners
>> would have to vote in accordance with real users.
>
> Exactly. I very explicitly am proposing that we consider giving users a
> mechanism to pay for votes to give them a way to directly influence the
> outcome.
>
> --
> 'peter'[:-1]@petertodd.org
> 127ab1d576dc851f374424f1269c4700ccaba2c42d97e778
>
> --
>
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
On Fri, Jun 12, 2015 at 8:36 PM, Matt Whitlock wrote:
> On Friday, 12 June 2015, at 7:34 pm, Peter Todd wrote:
>> On Fri, Jun 12, 2015 at 02:22:36PM -0400, Matt W
Re: [Bitcoin-development] Mining centralization pressure from non-uniform propagation speed
If there is a benefit in producing larger more-fee blocks if they propagate slowly, then there is also a benefit in including high-fee transactions that are unlikely to propagate quickly through optimized relay protocols (for example: very recent transactions, or out-of-band receoved ones). This effect is likely an order of magnitude less important still, but the effect is likely the same. On Jun 12, 2015 8:31 PM, "Peter Todd" wrote: > On Fri, Jun 12, 2015 at 01:21:46PM -0400, Gavin Andresen wrote: > > Nice work, Pieter. You're right that my simulation assumed bandwidth for > > 'block' messages isn't the bottleneck. > > > > But doesn't Matt's fast relay network (and the work I believe we're both > > planning on doing in the near future to further optimize block > propagation) > > make both of our simulations irrelevant in the long-run? > > Then simulate first the relay network assuming 100% of txs use it, and > secondly, assuming 100%-x use it. > > For instance, is it in miners' advantage in some cases to sabotage the > relay network? The analyse say yes, so lets simulate that. Equally even > the relay network isn't instant. > > -- > 'peter'[:-1]@petertodd.org > 127ab1d576dc851f374424f1269c4700ccaba2c42d97e778 > -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] User vote in blocksize through fees
On Fri, Jun 12, 2015 at 02:26:20PM -0400, Matt Whitlock wrote: > On Friday, 12 June 2015, at 11:20 am, Mark Friedenbach wrote: > > Peter it's not clear to me that your described protocol is free of miner > > influence over the vote, by artificially generating transactions which they > > claim in their own blocks > > Miners could fill their blocks with garbage transactions that agree with > their vote, but this wouldn't bring them any real income, as they'd be paying > their own money as fees to themselves. To get real income, miners would have > to vote in accordance with real users. Exactly. I very explicitly am proposing that we consider giving users a mechanism to pay for votes to give them a way to directly influence the outcome. -- 'peter'[:-1]@petertodd.org 127ab1d576dc851f374424f1269c4700ccaba2c42d97e778 signature.asc Description: Digital signature -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] User vote in blocksize through fees
On Friday, 12 June 2015, at 7:34 pm, Peter Todd wrote:
> On Fri, Jun 12, 2015 at 02:22:36PM -0400, Matt Whitlock wrote:
> > Why should miners only be able to vote for "double the limit" or "halve"
> > the limit? If you're going to use bits, I think you need to use two bits:
> >
> > 0 0 = no preference ("wildcard" vote)
> > 0 1 = vote for the limit to remain the same
> > 1 0 = vote for the limit to be halved
> > 1 1 = vote for the limit to be doubled
> >
> > User transactions would follow the same usage. In particular, a user vote
> > of "0 0" (no preference) could be included in a block casting any vote, but
> > a block voting "0 0" (no preference) could only contain transactions voting
> > "0 0" as well.
>
> Sounds like a good encoding to me. Taking the median of the three
> options, and throwing away "don't care" votes entirely, makes sense.
I hope you mean the *plurality* of the three options after throwing away the
"don't cares," not the *median*.
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] User vote in blocksize through fees
On Fri, Jun 12, 2015 at 02:22:36PM -0400, Matt Whitlock wrote:
> Why should miners only be able to vote for "double the limit" or "halve" the
> limit? If you're going to use bits, I think you need to use two bits:
>
> 0 0 = no preference ("wildcard" vote)
> 0 1 = vote for the limit to remain the same
> 1 0 = vote for the limit to be halved
> 1 1 = vote for the limit to be doubled
>
> User transactions would follow the same usage. In particular, a user vote of
> "0 0" (no preference) could be included in a block casting any vote, but a
> block voting "0 0" (no preference) could only contain transactions voting "0
> 0" as well.
Sounds like a good encoding to me. Taking the median of the three
options, and throwing away "don't care" votes entirely, makes sense.
> Incidentally, I love this idea, as it addresses a concern I immediately had
> with Jeff's proposal, which is that it hands control exclusively to the
> miners. And your proposal here fixes that shortcoming in a economically
> powerful way: miners lose out on fees if they don't represent the wishes of
> the users.
Thanks! I personally expect disaster to ensue with this kind of
proposal, but I'm less concerned if the disaster is something users
explicitly allowed to happen in a consensual way.
--
'peter'[:-1]@petertodd.org
127ab1d576dc851f374424f1269c4700ccaba2c42d97e778
signature.asc
Description: Digital signature
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Mining centralization pressure from non-uniform propagation speed
On Fri, Jun 12, 2015 at 01:21:46PM -0400, Gavin Andresen wrote: > Nice work, Pieter. You're right that my simulation assumed bandwidth for > 'block' messages isn't the bottleneck. > > But doesn't Matt's fast relay network (and the work I believe we're both > planning on doing in the near future to further optimize block propagation) > make both of our simulations irrelevant in the long-run? Then simulate first the relay network assuming 100% of txs use it, and secondly, assuming 100%-x use it. For instance, is it in miners' advantage in some cases to sabotage the relay network? The analyse say yes, so lets simulate that. Equally even the relay network isn't instant. -- 'peter'[:-1]@petertodd.org 127ab1d576dc851f374424f1269c4700ccaba2c42d97e778 signature.asc Description: Digital signature -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Mining centralization pressure from non-uniform propagation speed
Sure, and you did indeed say that. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] User vote in blocksize through fees
On Friday, 12 June 2015, at 11:20 am, Mark Friedenbach wrote: > Peter it's not clear to me that your described protocol is free of miner > influence over the vote, by artificially generating transactions which they > claim in their own blocks Miners could fill their blocks with garbage transactions that agree with their vote, but this wouldn't bring them any real income, as they'd be paying their own money as fees to themselves. To get real income, miners would have to vote in accordance with real users. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Mining centralization pressure from non-uniform propagation speed
I'm merely proving the existence of the effect. On Jun 12, 2015 8:24 PM, "Mike Hearn" wrote: > are only connected to each other through a slow 2 Mbit/s link. >> > > That's very slow indeed. For comparison, plain old 3G connections > routinely cruise around 7-8 Mbit/sec. > > So this simulation is assuming a speed dramatically worse than a mobile > phone can get! > -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Mining centralization pressure from non-uniform propagation speed
> > are only connected to each other through a slow 2 Mbit/s link. > That's very slow indeed. For comparison, plain old 3G connections routinely cruise around 7-8 Mbit/sec. So this simulation is assuming a speed dramatically worse than a mobile phone can get! -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] User vote in blocksize through fees
Why should miners only be able to vote for "double the limit" or "halve" the
limit? If you're going to use bits, I think you need to use two bits:
0 0 = no preference ("wildcard" vote)
0 1 = vote for the limit to remain the same
1 0 = vote for the limit to be halved
1 1 = vote for the limit to be doubled
User transactions would follow the same usage. In particular, a user vote of "0
0" (no preference) could be included in a block casting any vote, but a block
voting "0 0" (no preference) could only contain transactions voting "0 0" as
well.
Incidentally, I love this idea, as it addresses a concern I immediately had
with Jeff's proposal, which is that it hands control exclusively to the miners.
And your proposal here fixes that shortcoming in a economically powerful way:
miners lose out on fees if they don't represent the wishes of the users.
On Friday, 12 June 2015, at 2:11 pm, Peter Todd wrote:
> Jeff Garzik recently proposed that the upper blocksize limit be removed
> entirely, with a "soft" limit being enforced via miner vote, recorded by
> hashing power.
>
> This mechanism within the protocol for users to have any influence over
> the miner vote. We can add that back by providing a way for transactions
> themselves to set a flag determining whether or not they can be included
> in a block casting a specific vote.
>
> We can simplify Garzik's vote to say that one of the nVersion bits
> either votes for the blocksize to be increased, or decreased, by some
> fixed ratio (e.g 2x or 1/2x) the next interval. Then we can use a
> nVersion bit in transactions themselves, also voting for an increase or
> decrease. Transactions may only be included in blocks with an
> indentical vote, thus providing miners with a monetary incentive via
> fees to vote according to user wishes.
>
> Of course, to cast a "don't care" vote we can either define an
> additional bit, or sign the transaction with both versions. Equally we
> can even have different versions with different fees, broadcast via a
> mechanism such as replace-by-fee.
>
>
> See also John Dillon's proposal for proof-of-stake blocksize voting:
>
> https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg02323.html
>
> --
> 'peter'[:-1]@petertodd.org
> 127ab1d576dc851f374424f1269c4700ccaba2c42d97e778
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] User vote in blocksize through fees
Peter it's not clear to me that your described protocol is free of miner influence over the vote, by artificially generating transactions which they claim in their own blocks, or conforming incentives among voters by opting to be with the (slight) majority in order to minimize fees. Wouldn't it in fact be simpler to use the dynamic block size adjustment algorithm presented to the list a few weeks back, where the miner opts for a larger block by sacrificing fees? In that way the users "vote" for larger blocks by including sufficient fees to offset subsidy, but as it is an economic incentives miners gain nothing by inflating the fees in their own blocks. On Fri, Jun 12, 2015 at 11:11 AM, Peter Todd wrote: > Jeff Garzik recently proposed that the upper blocksize limit be removed > entirely, with a "soft" limit being enforced via miner vote, recorded by > hashing power. > > This mechanism within the protocol for users to have any influence over > the miner vote. We can add that back by providing a way for transactions > themselves to set a flag determining whether or not they can be included > in a block casting a specific vote. > > We can simplify Garzik's vote to say that one of the nVersion bits > either votes for the blocksize to be increased, or decreased, by some > fixed ratio (e.g 2x or 1/2x) the next interval. Then we can use a > nVersion bit in transactions themselves, also voting for an increase or > decrease. Transactions may only be included in blocks with an > indentical vote, thus providing miners with a monetary incentive via > fees to vote according to user wishes. > > Of course, to cast a "don't care" vote we can either define an > additional bit, or sign the transaction with both versions. Equally we > can even have different versions with different fees, broadcast via a > mechanism such as replace-by-fee. > > > See also John Dillon's proposal for proof-of-stake blocksize voting: > > > https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg02323.html > > -- > 'peter'[:-1]@petertodd.org > 127ab1d576dc851f374424f1269c4700ccaba2c42d97e778 > > > -- > > ___ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] User vote in blocksize through fees
Jeff Garzik recently proposed that the upper blocksize limit be removed entirely, with a "soft" limit being enforced via miner vote, recorded by hashing power. This mechanism within the protocol for users to have any influence over the miner vote. We can add that back by providing a way for transactions themselves to set a flag determining whether or not they can be included in a block casting a specific vote. We can simplify Garzik's vote to say that one of the nVersion bits either votes for the blocksize to be increased, or decreased, by some fixed ratio (e.g 2x or 1/2x) the next interval. Then we can use a nVersion bit in transactions themselves, also voting for an increase or decrease. Transactions may only be included in blocks with an indentical vote, thus providing miners with a monetary incentive via fees to vote according to user wishes. Of course, to cast a "don't care" vote we can either define an additional bit, or sign the transaction with both versions. Equally we can even have different versions with different fees, broadcast via a mechanism such as replace-by-fee. See also John Dillon's proposal for proof-of-stake blocksize voting: https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg02323.html -- 'peter'[:-1]@petertodd.org 127ab1d576dc851f374424f1269c4700ccaba2c42d97e778 signature.asc Description: Digital signature -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Mining centralization pressure from non-uniform propagation speed
On Fri, Jun 12, 2015 at 06:51:02PM +0200, Pieter Wuille wrote: > The configuration used in the code right now simulates two groups of miners > (one 80%=25%+25%+30%, one 20%=5%+5%+5%+5%), which are well-connected > internally, but are only connected to each other through a slow 2 Mbit/s > link. > > Here are some results. > > This shows how the group of smaller miners loses around 8% of their > relative income (if they create larger blocks, their loss percentage goes > up slightly further): To be clear, when you say 8% of their income, you mean revenue, not profit? Actual profit margins of something like 5%-10% are likely, so that's an enormous hit that could make their mining operation completely non-viable. -- 'peter'[:-1]@petertodd.org 127ab1d576dc851f374424f1269c4700ccaba2c42d97e778 signature.asc Description: Digital signature -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Mining centralization pressure from non-uniform propagation speed
Nice work, Pieter. You're right that my simulation assumed bandwidth for 'block' messages isn't the bottleneck. But doesn't Matt's fast relay network (and the work I believe we're both planning on doing in the near future to further optimize block propagation) make both of our simulations irrelevant in the long-run? Or, even simpler, why couldn't the little miners just run their block-assembling-and-announcing code on the other high-bandwidth-side of the bandwidth bottleneck? -- -- Gavin Andresen -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Mining centralization pressure from non-uniform propagation speed
Hello all, I've created a simulator for Bitcoin mining which goes a bit further than the one Gavin used for his blog post a while ago. The main difference is support for links with different latency and bandwidth, because of the clustered configuration described below. In addition, it supports different block sizes, takes fees into account, does difficulty adjustments, and takes processing and mining delays into account. It also simulates longer periods of time, and averages the result of many simulations running in parallel until the variance on the result is low enough. The code is here: https://github.com/sipa/bitcoin-net-simul The configuration used in the code right now simulates two groups of miners (one 80%=25%+25%+30%, one 20%=5%+5%+5%+5%), which are well-connected internally, but are only connected to each other through a slow 2 Mbit/s link. Here are some results. This shows how the group of smaller miners loses around 8% of their relative income (if they create larger blocks, their loss percentage goes up slightly further): Configuration: * Miner group 0: 80.00% hashrate, blocksize 2000.00 * Miner group 1: 20.00% hashrate, blocksize 100.00 * Expected average block size: 1620.00 * Average fee per block: 0.25 * Fee per byte: 0.000154 Result: * Miner group 0: 81.648985% income (factor 1.020612 with hashrate) * Miner group 1: 18.351015% income (factor 0.917551 with hashrate) When fees become more important however, and half of a block's income is due to fees, the effect becomes even stronger (a 15% loss), and the optimal way to compete for small miners is to create larger blocks as well (smaller blocks for them result in even less income): Configuration: * Miner group 0: 80.00% hashrate, blocksize 2000.00 * Miner group 1: 20.00% hashrate, blocksize 2000.00 * Expected average block size: 2000.00 * Average fee per block: 25.00 * Fee per byte: 0.012500 Result: * Miner group 0: 83.063545% income (factor 1.038294 with hashrate) * Miner group 1: 16.936455% income (factor 0.846823 with hashrate) The simulator is not perfect. It doesn't take into account that multiple blocks/relays can compete for the same bandwidth, or that nodes cannot process multiple blocks at once. The numbers used may be unrealistic, and I don't mean this as a prediction for real-world events. However, it does very clearly show the effects of larger blocks on centralization pressure of the system. Note that this also does not make any assumption of destructive behavior on the network - just simple profit maximalization. Lastly, the code may be buggy; I only did some small sanity tests with simple networks. -- Pieter -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Miners: You'll (very likely) need to upgrade your Bitcoin Core node soon to support BIP66
Once the 75% threshold is reached, miners who haven't updated are at risk of mining on invalid blocks. If someone produces a version 3 block that violates the new rules, then miners who haven't upgraded will end up wasting mining power building on that block. This could be used as an expensive way to attack miners who haven't upgraded. It is low risk of happening, since creating an invalid version 3 block costs 25BTC in hashing power and the miner who does it ends up creating an invalid block. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
