Re: [bitcoin-dev] Encouraging mining of the first few big blocks with OP_CSV and BIP68
That guy is going to easily make back his 150 BTC with interest, if he is short BTC. Should be a clear signal for the market to trend lower, probably below $180 by the time of the test. On 23 August 2015 at 19:08, jl2012 via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: Someone is going to burn 150BTC to create a backlog of 30-day in September. https://www.reddit.com/r/Bitcoin/comments/3hgke4/coinwallet_says_bitcoin_stress_test_in_september/ However, the money could be spent more wisely by encouraging mining of the first few big blocks Assumptions: 1. OP_CSV and BIP68 are enabled 2. Max tx size remains 1MB The donor will create a transaction, with an input of 150BTC, and 10 outputs: 1. 0 BTC to OP_RETURN garbage 2. 42 BTC to OP_1 OP_CSV 3. 21 BTC to OP_2 OP_CSV 4. 10.5 BTC to OP_3 OP_CSV 5. 5.25 BTC to OP_4 OP_CSV 6. 2.625 BTC to OP_5 OP_CSV 7. 1.3125 BTC to OP_6 OP_CSV 8. 0.65625 BTC to OP_7 OP_CSV 9. 0.328125 BTC to OP_8 OP_CSV 10. 0.328125 BTC to OP_9 OP_CSV The first output will fill up the size to 1MB. This tx could not be confirmed by a pre-hardfork miner because the coinbase tx will consume some block space. The first big block miner will be able to collect 66BTC of fee. The block confirming the first big block will collect 42BTC of fee, etc. This will create a long enough chain to bootstrap the hardfork. The amount is chosen to make sure the difference is 25BTC, so miners would have less incentive to create a fork instead of confirming other's block. However, a miner cartel may launch a 51% attack to collect all money. Such incentive may be reduced by adjusting the distribution of donation. (Actually, such cartel may be formed anytime, just for collecting more block reward) ___ 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] Encouraging mining of the first few big blocks with OP_CSV and BIP68
Someone is going to burn 150BTC to create a backlog of 30-day in September. https://www.reddit.com/r/Bitcoin/comments/3hgke4/coinwallet_says_bitcoin_stress_test_in_september/ However, the money could be spent more wisely by encouraging mining of the first few big blocks Assumptions: 1. OP_CSV and BIP68 are enabled 2. Max tx size remains 1MB The donor will create a transaction, with an input of 150BTC, and 10 outputs: 1. 0 BTC to OP_RETURN garbage 2. 42 BTC to OP_1 OP_CSV 3. 21 BTC to OP_2 OP_CSV 4. 10.5 BTC to OP_3 OP_CSV 5. 5.25 BTC to OP_4 OP_CSV 6. 2.625 BTC to OP_5 OP_CSV 7. 1.3125 BTC to OP_6 OP_CSV 8. 0.65625 BTC to OP_7 OP_CSV 9. 0.328125 BTC to OP_8 OP_CSV 10. 0.328125 BTC to OP_9 OP_CSV The first output will fill up the size to 1MB. This tx could not be confirmed by a pre-hardfork miner because the coinbase tx will consume some block space. The first big block miner will be able to collect 66BTC of fee. The block confirming the first big block will collect 42BTC of fee, etc. This will create a long enough chain to bootstrap the hardfork. The amount is chosen to make sure the difference is 25BTC, so miners would have less incentive to create a fork instead of confirming other's block. However, a miner cartel may launch a 51% attack to collect all money. Such incentive may be reduced by adjusting the distribution of donation. (Actually, such cartel may be formed anytime, just for collecting more block reward) ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] RE : Visualizations of Votes
While I like the idea of voting on the block size debate... Why is this vote limited to miners only? I would prefer to see a vote by owners/holders of bitcoin, not miners of bitcoin. If miners with 10%+ hashrate are the only ones who get to vote... bitcoin development is an oligarchy My 2cents On Fri, Aug 21, 2015 at 11:14 PM, odinn via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 This is great!! Thank you. On 08/21/2015 06:24 AM, Christian Decker wrote: I hacked together a simple tracking page for the 'block votes', it currently includes the 8MB vote and XT, as well as the /BV\d+/ vote for generic size: http://bitcoinstats.com/network/votes/ On Fri, Aug 21, 2015 at 7:25 AM odinn via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org mailto:bitcoin-dev@lists.linuxfoundation.org wrote: Hello Nicolas, On 08/20/2015 08:49 PM, Nicolas Dorier via bitcoin-dev wrote: A visualization I would like to see would include: pie graph(s) of what % are voting for (BIP 100, BIP 101, 8MB, BIP sipa etc) based on what's published in blocks. If such a vote existed, I would gladly show the pie on BIPxDevs. However there is no standard way for miners to vote informally BIP they support. What about formal votes? Is there a way to visually have them appear in a pie chart as the votes become apparent in blocks? I appreciate good visualizations and am trying to get a (visual) comparison of the votes on these competing proposals. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org mailto:bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org mailto:bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev - -- 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 iQEcBAEBAgAGBQJV1+kXAAoJEGxwq/inSG8Ctg4H/0zOfXEO/b+yxgGjnrIiiAi5 04Un/C9ZuPCn/dMQ5rZ0e8jIOclNER3NGtKbPBmLweyeN84HlrUUQ0ctRQocY1md XwGJIMpjpwQCSf52XrH3IC0J8X45DQj3295sDNnmgAkOxIyPABKdDR7RJ8LfQU/B BmJu0JAIBJmpAkz1ZJ2wYe2T0sUFk8WmvH40BzoIKqu0A9vMcR8IqfKMBI9Qczbw ZJyWFTsgovS/p/8tSxeI458DsY1WjivdQe7nJNXit6eA5Yle3Cs3nvsA2+6xy5L9 uedX38+8s3XNXrXY1CCR7ptowjzCI+U6yiFluK+xx1oPPhtdRJYwo4vyTmaCaK8= =uh68 -END PGP SIGNATURE- ___ 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
Re: [bitcoin-dev] BIP 10X: Replace Transaction Fees with Data, Discussion Draft 0.2.9
Some comments: (i) remove any possibility of free transactions unless associated with basic transaction data; I believe it is not possible to prevent free transactions for the reason that people can pay out of band (via existing banking transfers to miners) or make payments to addresses belonging to miners (that are contingent on the requested user transaction being processed via input dependency) . I am not sure I fully understand the way you see monetisation working, and you do indicate this is quite far future what-if stage idea, and you do identify a conflict with fungibility - but I think this is probably quite badly in conflict with fungibility to the point of conflicting with many planned Bitcoin improvements? And mid term technical directions. I would say the long term idealised requirements are that the transaction itself would have cryptographic fungibility, and policy relating to identity for authorisation, approval in regulated transactions would take place at the payment protocol layer. The payment protocol is already seeing some use. Lightning protocol sees more of the data going point to point and so not broadcast nor visible for big data analytic monetisation. Adam On 22 August 2015 at 23:51, Jorge Timón bitcoin-dev@lists.linuxfoundation.org wrote: Again, did you got a bip number asigned or did you self-assigned it yourself? On Sat, Aug 22, 2015 at 1:01 PM, Ahmed Zsales via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: Hello, In response to public and private comments and feedback, we have updated this working draft. https://drive.google.com/file/d/0BwEbhrQ4ELzBOUVtOHJQdlhvUmc/view?usp=sharing Update highlights: 1. Specific clarifications on replacing the Coinbase subsidy and supplementing and not replacing transaction fees. 2. Clarification on block chain overhead. The value of data mining is on a bell curve, so year six data will be removed every year. 3. Added references to an ability to create global, national and regional Bitcoin Price Indices for popular baskets of goods transacted with Bitcoin. 4. Added references for an ability to use structured block chain data for Bitcoin capacity and fork planning. 5. Removed references to price speculation. 6. Added preferences for deployment dates of January 2017 or January 2018. 7. Moving towards BIP format after discussion and evaluation period. Technical content will increase in due course and discussion content will be removed. Further views and feedback welcome. Regards, Ahmed On Mon, Aug 17, 2015 at 5:23 PM, Ahmed Zsales ahmedzsale...@gmail.com wrote: Hello, Here we propose a long-term solution to replace mining rewards and transactions fees. BIP 104 is currently a discussion draft only. https://drive.google.com/file/d/0BwEbhrQ4ELzBSXpoUjRkc01QUGc/view?usp=sharing Views and feedback welcome. Regards, Ahmed ___ 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 mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Block size possible solution - to set minimum size
A minimum block size does nothing to prevent the problems that come from schism hardforks. But also a minimum block size can be trivially cheated as recently explained on this list: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010317.html [...] miners can just pay to themselves to follow the minimum size block rule without risking anything. As long as they have a single matured satoshi they can just pay to themselves with it as many times as they need in the same block. It is good to search previous post before proposing or asking something (it could have been proposed/asked earlier): http://www.catb.org/esr/faqs/smart-questions.html On Sun, Aug 23, 2015 at 1:30 AM, Bdimych Bdimych via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: Hi, As I understand the main problem of the fork Core-XT is possibility of double spending: -I run XT and spend my coins -it is written in 8mb block -Core does not accept this block -I run Core and spend my coins again -it is written in 1mb block -but XT accepts this block too so -in the XT blockchain both blocks [8] and [1] contain my coins I thought that possible solution can be to set minimum block size i.e. 2016: 1mb = blockSize 2mb 2017: 2mb = blockSize 3mb 2018: 3mb = blockSize 4mb etc Free space could be filled with zeroes and compressed. That's all, just an idea. With Best Regards Dmitry Bolshakov bdim...@gmail.com ___ 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
Re: [bitcoin-dev] Censorship
This is off-topic here. Consensus critical changes (those aren't changes that Bitcoin Core developers can make unilaterally against the will of alternative implementations or users) and Bitcoin Core development are independent from bitcointalk.org and /r/bitcoin. And as you say, people can create competing without moderation or censorship (ie /r/bitcoin_uncensored or bitcontalkuncensred.org /r/bitcoin_moderated_by_someone_else ). On Sat, Aug 22, 2015 at 3:39 PM, David Vorick via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: I am not sure that this is on-topic for the bitcoin-dev mailing list, but it seems politically relevant enough that I'm going to respond. /r/bitcoin and bitcointalk.org are both discussion websites that pertain to a specific topic. All (or nearly all) discussion websites pertaining to a specific topic have a set of rules that get enforced to facilitate relevant and interesting discussion. These rules help to block spam, and help to make sure that discussions happen in their appropriate places. The rules in place on the two primary bitcoin discussion sites have helped facilitate a large userbase frequented by many relevant experts. I do believe that we can thank the strict moderation policies for much of the activity that happens which is technically interesting. /r/bitcoin and bitcointalk.org are both centralized forums. As such, the rules are going to be set by a centralized authority. The rules set have been set to keep the discussion as interesting and relevant as possible. When a certain theme becomes a massive echo chamber or little more than beating a dead horse, it makes sense to implement moderation. Calling it 'censorship' is misleading, because a government authority is not threatening punishment for the discussion of a certain topic. People are not banned from visiting forums or websites where off-topic (or against-the-rules) discussion is happening. People's /r/bitcoin rights are not being revoked because they are subscribed to a controvertial subreddit. That would be censorship. Many people are clearly unhappy with the moderation happening on /r/bitcoin and bitcointalk.org. Luckily, the switching cost for online discussion forums is very low. I'm now going to invite people to post links to bitcoin discussion forums where the moderation authority is different. I know that a recently popular subreddit is /r/bitcoin_uncensored I am interested to see what other forums people think are worth mentioning. ___ 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
Re: [bitcoin-dev] Block size possible solution - to set minimum size
I apologize, I'm not familiar with technical details, may be stupid, only general thoughts: -overlapped block sizes - two blockchains, uncertainty, unpredictable results, trust gets down -non-overlapped - single blockchain, determined growing, everybody knows the schedule what and when will happen --- You wrote cheated, but why? If it will be possible to fill with zeroes [transactions]+[zeroes] or [transactions]+[miner's dummy transactions] why the second variant will be better for miner? and why it will be not good for other users? With Best Regards Dmitry Bolshakov bdim...@gmail.com On Sun, Aug 23, 2015 at 1:40 AM, Jorge Timón jti...@jtimon.cc wrote: A minimum block size does nothing to prevent the problems that come from schism hardforks. But also a minimum block size can be trivially cheated as recently explained on this list: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010317.html [...] miners can just pay to themselves to follow the minimum size block rule without risking anything. As long as they have a single matured satoshi they can just pay to themselves with it as many times as they need in the same block. It is good to search previous post before proposing or asking something (it could have been proposed/asked earlier): http://www.catb.org/esr/faqs/smart-questions.html On Sun, Aug 23, 2015 at 1:30 AM, Bdimych Bdimych via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: Hi, As I understand the main problem of the fork Core-XT is possibility of double spending: -I run XT and spend my coins -it is written in 8mb block -Core does not accept this block -I run Core and spend my coins again -it is written in 1mb block -but XT accepts this block too so -in the XT blockchain both blocks [8] and [1] contain my coins I thought that possible solution can be to set minimum block size i.e. 2016: 1mb = blockSize 2mb 2017: 2mb = blockSize 3mb 2018: 3mb = blockSize 4mb etc Free space could be filled with zeroes and compressed. That's all, just an idea. With Best Regards Dmitry Bolshakov bdim...@gmail.com ___ 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
Re: [bitcoin-dev] Libconsensus separated repository (was Bitcoin Core and hard forks)
I see the huge amount of sweat and love that went into core and it actually hurts to see that most is expended in friction and lack of a vision for the software architecture. To be concrete, this was my plan if dealing with the Core code base: 1) I'd consider the separation of networking and storage as suggested for a future extended libconsensus low priority, as their design should be (are) dominated by the need of the consensus logic only. 2) create an API to the consensus+networking+storage service that is not at the C++ language level but some scaleable cross-platform remoting, like eg. ZeroMQ. This API should be minimal and simple, assuming that one fully trusts the node answering it. This API would unlock user land development by distinct teams with diverse technologies. 3) move the wallet, QT and RPC and other backward compatibility stuff (if e.g. there is some mining support) in-top of the new API and into distinct source code repositories. Tamas Blummer On Aug 23, 2015, at 03:23, Eric Lombrozo elombr...@gmail.com wrote: I've been pushing for greater modularization since I first got into bitcoin. I got quickly frustrated when I was only able to get through very few things (i.e. moving core structure serialization classes to a separate unit not called main). Working on Bitcoin has an added layer of frustration that goes beyond most open source projects: even though we're clearly in userland working at the application layer, a good layered protocol design is still lacking. We have no standards process separate from what basically amount to updates to one specific reference implementation. And we all need to agree on any major change, since a blockchain that is easily forked in contentious ways pretty much defeats its own purpose. I went off to develop my own stack, where I could more easily avoid politics and focus on engineering. But I now understand the politics are inevitable. Bitcoin is inherently a cooperative project. Several people have poured themselves passionately into the reference codebase, most of whom did it (at least initially) purely as unpaid volunteers. There's a lot of love that's gone into this. But it's become pretty clear that the modularization is no longer merely a matter of good engineering - it is essential to resolving serious political challenges. Perhaps the most frustrating thing of all is watching people pushing for relatively superficial yet highly controversial changes while we still lack the proper infrastructure to handle these kinds of divergences of opinion without either stagnating or becoming polarized. I could continue working to reimplement an entire stack from scratch, as several others have also done - but besides the serious effort duplication this entails, it doesn't really seem like it will ultimately be a convergent process. It's too easy to let ego and habit dictate one's preferences rather than rational engineering considerations. I know that some might feel I'm just preaching to the choir, but we should probably take a step back from implementation hackery and try to specify some core protocol layers, focusing on interfaces. Specifically, we need a consensus layer that doesn't try to specify networking, storage, wallets, UI, etc. Let different people improve upon these things independently in their own implementations. What matters is that we all converge on a common history and state. At the same time, let's open up more competition on all these other things that are separate from the consensus layer. If only we were to dedicate a fraction of the effort we've put into this whole block size circus into what's actually important...and I blame myself as well... On Sat, Aug 22, 2015, 4:05 AM Tamas Blummer via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org mailto:bitcoin-dev@lists.linuxfoundation.org wrote: On Aug 21, 2015, at 21:46, Jorge Timón jti...@jtimon.cc mailto:jti...@jtimon.cc wrote: On Thu, Aug 20, 2015 at 10:35 AM, Tamas Blummer ta...@bitsofproof.com mailto:ta...@bitsofproof.com wrote: Every re-implementation, re-factoring even copy-paste introduces a risk of disagreement, but also open the chance of doing the work better, in the sense of software engineering. But you don't want something better, you want something functionally identical. You may want to watch sipa's explanation on why the implementation is the specification and the reasons to separate libconsensus: https://youtu.be/l3O4nh79CUU?t=764 https://youtu.be/l3O4nh79CUU?t=764 I do want something better, but not for the focus you have. Not because what you produce was not high quality, but because quality is achieved at a very high cost and is hard to uphold over generations of developer. You focus on a single use case while there are many out there for distributed ledgers. I think in an infrastructure for enterprise applications, building
Re: [bitcoin-dev] [BIP-draft] CHECKSEQUENCEVERIFY - An opcode for relative locktime
ack no inversion. This can actually allow more direct preservation of existing semantics. http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009350.html On 8/19/2015 9:21 AM, Mark Friedenbach via bitcoin-dev wrote: I am indifferent on this issue (the bit inversion), but so far only Jorge has spoken up. I opted for this detail during implementation in order to preserve existing semantics, even if those semantics are not commonly used. This was the conservative choice, driven in part because I didn't want the proposal to be held up by the other side saying this is confusing because it changes how sequence numbers work! it used to count up but now it counts down! I can see both sides and as I said I'm indifferent, so I went with the conservative choice of not messing with existing semantics. However if there is strong preferences from _multiple_ people on this matter it is not too late to change. If anyone feels strongly about this, please speak up. On Wed, Aug 19, 2015 at 3:37 AM, Jorge Timón bitcoin-dev@lists.linuxfoundation.org mailto:bitcoin-dev@lists.linuxfoundation.org wrote: I repeated my nit on https://github.com/bitcoin/bips/pull/179 On Mon, Aug 17, 2015 at 9:58 PM, Btc Drak via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org mailto:bitcoin-dev@lists.linuxfoundation.org wrote: Please note there is now a PR for this BIP[1] and also a pull request for the opcode CHECKSEQUENCEVERIFY in Bitcoin Core[2]. [1] https://github.com/bitcoin/bips/pull/179 [2] https://github.com/bitcoin/bitcoin/pull/6564 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] [BIP-draft] CHECKSEQUENCEVERIFY - An opcode for relative locktime
On Mon, Aug 24, 2015 at 12:25 AM, Tom Harding via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: ack no inversion. This can actually allow more direct preservation of existing semantics. http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009350.html I can't follow this logic. Can you help? The existing semantics, to the extent that they exist at all is that the earliest version starts with the lowest sequence number then counts up (and if it makes its way to the highest number, the result is final-- because it could go no higher). Thats the semantics 'the inversion' accomplishes for CSV: the that the first version of a transaction begins with a smaller number which successful versions increase, and the highest possible number is final (no delay, because no delay is the shortest delay). Seperately, to Mark and Btcdrank: Adding an extra wrinkel to the discussion has any thought been given to represent one block with more than one increment? This would leave additional space for future signaling, or allow, for example, higher resolution numbers for a sharechain commitement. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Dynamically Controlled Bitcoin Block Size Max Cap
On 8/21/2015 5:01 PM, Peter Todd wrote: I checked the scenario where only the radio is on, and found the car does not crash. Incidentally, what's your acceptable revenue difference between a small (1% hashing power) and large (%30 hashing power) miner, all else being equal? (remember that we shouldn't preclude variance reduction techniques such as p2pool and pooled-solo mode) Equally, what kind of attacks on miners do you think we need to be able to resist? E.g. DoS attacks, hacking, etc. None of this is in the scope of Pieter's simulation. If you think that casts doubt on my conclusions, then it casts doubt on his original conclusions as well. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] [BIP-draft] CHECKSEQUENCEVERIFY - An opcode for relative locktime
A power of 2 would be far more efficient here. The key question is how long of a relative block time do you need? Figure out what the maximum should be ( I don't know what that would be, any ideas?) and then see how many bits you have left over. On Aug 23, 2015 7:23 PM, Jorge Timón bitcoin-dev@lists.linuxfoundation.org wrote: On Mon, Aug 24, 2015 at 3:01 AM, Gregory Maxwell via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: Seperately, to Mark and Btcdrank: Adding an extra wrinkel to the discussion has any thought been given to represent one block with more than one increment? This would leave additional space for future signaling, or allow, for example, higher resolution numbers for a sharechain commitement. No, I don't think anybody thought about this. I just explained this to Pieter using for example, 10 instead of 1. He suggested 600 increments so that it is more similar to timestamps. ___ 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
Re: [bitcoin-dev] [BIP-draft] CHECKSEQUENCEVERIFY - An opcode for relative locktime
Gregory Maxwell via bitcoin-dev 於 2015-08-23 21:01 寫到: Seperately, to Mark and Btcdrank: Adding an extra wrinkel to the discussion has any thought been given to represent one block with more than one increment? This would leave additional space for future signaling, or allow, for example, higher resolution numbers for a sharechain commitement. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev I think this comment is more related to BIP68 instead of OP_CSV? Without further complicating the BIP68, I believe the best way to leave room for improvement is to spend a bit in tx nVersion to indicate the activation of BIP68. I have raised this issue before with http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010043.html However, it seems Mark isn't in favor of my proposal The idea is not to permanently change the meaning of nSequence. Actually, BIP68 is only enforced if the most significant bit of the sequence number field is set. So BIP68 is optional, anyway. All I suggest is to move the flag from nSequence to nVersion. However, this will leave much bigger room for using nSequence for other purpose in the future. AFAIK, nSequence is the only user definable and signed element in TxIn. There could be more interesting use of this field and we should not change its meaning permanently. (e.g. if nSequence had 8 bytes instead of 4 bytes, it could be used to indicate the value of the input to fix this problem: https://bitcointalk.org/index.php?topic=181734.0 ) ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] [BIP-draft] CHECKSEQUENCEVERIFY - An opcode for relative locktime
On Mon, Aug 24, 2015 at 3:01 AM, Gregory Maxwell via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: Seperately, to Mark and Btcdrank: Adding an extra wrinkel to the discussion has any thought been given to represent one block with more than one increment? This would leave additional space for future signaling, or allow, for example, higher resolution numbers for a sharechain commitement. No, I don't think anybody thought about this. I just explained this to Pieter using for example, 10 instead of 1. He suggested 600 increments so that it is more similar to timestamps. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Dynamically Controlled Bitcoin Block Size Max Cap
On Mon, Aug 24, 2015 at 1:41 AM, Tom Harding via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: On 8/21/2015 5:01 PM, Peter Todd wrote: I checked the scenario where only the radio is on, and found the car does not crash. Incidentally, what's your acceptable revenue difference between a small (1% hashing power) and large (%30 hashing power) miner, all else being equal? (remember that we shouldn't preclude variance reduction techniques such as p2pool and pooled-solo mode) Equally, what kind of attacks on miners do you think we need to be able to resist? E.g. DoS attacks, hacking, etc. None of this is in the scope of Pieter's simulation. If you think that casts doubt on my conclusions, then it casts doubt on his original conclusions as well. As far as I know, his conclusions were that there was an effect, while suspending judgement on whether that effect was high enough to be important for a given size or not. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
