Re: [Bitcoin-development] Proposed alternatives to the 20MB step
On 06/01/2015 08:55 AM, Mike Hearn wrote: Decentralization is the core of Bitcoin's security model and thus that's what gives Bitcoin its value. No. Usage is what gives Bitcoin value. Nonsense. Visa, Dollar, Euro, Yuan, Peso have usage. The value in Bitcoin is *despite* it's far lesser usage. Yes, the price is a function of demand, but demand is a function of utility. Despite orders of magnitude less usage than state currencies, Bitcoin has utility. This premium *only* exists due to its lack of centralized control. I would not work full time, or at all, on Bitcoin if it was not for decentralization; nor would I hold any of it. I doubt anyone would show an interest in Bitcoin if it was not decentralized. If it centralized even you would be forced to find something else to do, because Bitcoin usage would drop to zero. It's kind of maddening that I have to point this out. Decentralisation is a means to an end. No, it was/is the primary objective. Paypal had already been done. If anything is maddening it's that you of all people can't see this. When people talk about the core innovation of Bitcoin, it's a conversation about Byzantine Generals, not wicked growth hacking. in April 2009 and it was perfectly decentralised [...] every wallet was a full node and every computer was capable of mining. So if you believe what you just wrote [...] Bitcoin's value has gone down every day since An obvious non sequitur. By way of example, if 10 of 10 participants are capable of mining it is not more decentralized than if 1,000 in 100,000 are doing so. 1,000 *people* in control vs. 10 is two orders of magnitude more decentralized. The *percentage* of the community that mines is totally irrelevant, it's the absolute number of (independent) people that matters. I'm not making a statement on block size, just trying to help ensure that ill-considered ideas, like this inversion of the core value proposition, stay on the margins. e signature.asc Description: OpenPGP digital signature -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Max Block Size: Simple Voting Procedure
Why do it as an OP_RETURN output? It could be a simple token in the coinbase input script, similar to how support for P2SH was signaled among miners. And why should there be an explicit token for voting for the status quo? Simply omitting any indication should be an implicit vote for the status quo. A miner would only need to insert an indicator into their block if they wished for a larger block. I don't really care the exact location it's put in. I just thought there wasn't an explicit need to put it in the header (via a bit of nVersion), and the scriptSig is already used for many things (block height, merged mining hash, \P2SH\, miner identifier). And voting to keep the block size the same by not voting is fine by me. That said, proposals of this type have been discussed before, and the objection is always that miners would want larger blocks than the rest of the network could bear. Unless you want Bitcoin to become centralized in the hands of a few large mining pools, you shouldn't hand control over the block size limits to the miners. Yeah, that was the conclusion we came to chatting on #bitcoin-wizards the other day. I now think that this could be useful to dynamically increase a lower limit, but that there should still be a hard upper limit like 20 MB. I think that just changing the upper limit might be simpler and better, though. - Stephen -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Max Block Size: Simple Voting Procedure
Why do it as an OP_RETURN output? It could be a simple token in the coinbase
input script, similar to how support for P2SH was signaled among miners. And
why should there be an explicit token for voting for the status quo? Simply
omitting any indication should be an implicit vote for the status quo. A miner
would only need to insert an indicator into their block if they wished for a
larger block.
That said, proposals of this type have been discussed before, and the objection
is always that miners would want larger blocks than the rest of the network
could bear. Unless you want Bitcoin to become centralized in the hands of a few
large mining pools, you shouldn't hand control over the block size limits to
the miners.
On Sunday, 31 May 2015, at 3:04 pm, Stephen Morse wrote:
This is likely very similar to other proposals, but I want to bring voting
procedures back into the discussion. The goal here is to create a voting
procedure that is as simple as possible to increase the block size limit.
Votes are aggregated over each 2016 block period. Each coinbase transaction
may have an output at tx.vout[0] with OP_RETURN data in it of the format:
OP_RETURN {OP_1 or OP_2}
OP_2 means the miner votes to increase the block size limit. OP_1 means the
miner votes to not increase the block size limit. *Not including such a
vote is equivalent to voting to NOT increase the block size. *I first
thought that not voting should mean that you vote with your block size, but
then decided that it would be too gameable by others broadcasting
transactions to affect your block size.
If in a 2016 block round there were more than 1008 blocks that voted to
increase the block size limit, then the max block size increases by 500 kb.
The votes can start when there is a supermajority of miners signaling
support for the voting procedure.
A few important properties of this simple voting:
- It's not gameable via broadcasting transactions (assuming miners don't
set their votes to be automatic, based on the size of recent blocks).
- Miners don't have to bloat their blocks artificially just to place a
vote for larger block sizes, and, similarly, don't need to exclude
transactions even when they think the block size does not need to be
raised.
- The chain up until the point that this goes into effect may be
interpreted as just lacking votes to increase the block size.
We can't trust all miners, but we have to trust that 50% of them are
honest for the system to work. This system makes it so that altering the
maximum block size requires 50% of miners (hash power) to vote to increase
the consensus-limit.
Thanks for your time. I think this is an important time in Bitcoin's
history. I'm not married to this proposal, but I think it would work. I
think a lot of the proposals mentioned on this mailing list would work. I
think it's time we just pick one and run with it.
Please let me know your thoughts. I will start working on a pull request if
this receives any support from miners/core devs/community members, unless
someone with more experience volunteers.
Best,
Stephen
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Max Block Size: Simple Voting Procedure
On Wed, Jun 3, 2015 at 10:33 AM, Stephen Morse stephencalebmo...@gmail.com wrote: Pindar, yes and it's a good idea to separate the hard/soft fork upgrades. The point being here is that we're also establishing a process for the community to self-determine the way forward in a transparent and verifiable manner. What's not to like? :) I'll probably have some time on Sunday to help hack something up but I don't think this is that heavy a coding lift? What am I missing? As Matt mentioned, many members of the bitcoin community would be hesitant about giving miners this much power. I understand this concern and it's a valid one, including other dimensions such as better decentralization. Some might argue that the mining pools in China currently have such power and that's a bad thing:- https://blockchain.info/pools I happen to think that it's unhealthy for the network but the irony is that they are huge bitcoin fanbase that perhaps should be involved in this, and other, decisions. The question is how. Thus far our friends from f2pool have chimed in with some data from their perspective. It would be interesting to hear from the others and I'm finding ways to do exactly that. So let's find a way to involve, and not alienate them or others. Let's find a way to get more data and test assumptions and boundaries. It essentially lets them vote to change the rules of the system. It's data and yes, it gives then a very visible, verifiable 'vote' ... though I prefer to think of this as 'voice' as in a ' hu. ' But miners are not the only part of this ecosystem, and they are not the only ones affected by the choice of block size limit, so they probably shouldn't be the only ones with a vote. I fully agree and it doesn't have to be the only voice ... think 'choir' ... after all this is an ecosystem with each party playing their respective roles. But sustainable ecosystems have 'keystone' species, and I believe these to be the 'honest' miners that help secure the network. Instead, we vote with the software we run, and all upgrade. or not as the case may be. I think we're trying to find a level of rough consensus where members of the community feel comfortable enough to do this upgrade in their respective codebase. So, while I think an idea like this has its merits, I would bet that it's fairly unlikely to get enough support to be merged into bitcoin core. Bitcoin was 'unlikely' ... yet it happened. Nevertheless you raise the possibility of a different possible path forward and that's positive. So thank you for doing that! Bitcoin's humming in China, behind an GFW ... who could have guessed? 'Connect and Liberate' :) p. Best, Stephen -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Max Block Size: Simple Voting Procedure
Some changes: Votes need to be 100%, not 50.01%. That way small miners have a fair chance. A 50.01% vote means large miners call the shots. Users (people who make transactions) need to vote. A vote by a miner shouldn't count without user votes. Fee incentives should attract legitimate votes from miners. A cheating miner will be defeated by another miner who includes those votes, and take the fees. This lets wallet providers and exchanges cast votes (few wallets will implement prompts and will just auto vote, so if you don't agree, switch wallets. Vote with your wallet). ~Vince On Jun 3, 2015 12:34 PM, Stephen Morse stephencalebmo...@gmail.com wrote: Pindar, yes and it's a good idea to separate the hard/soft fork upgrades. The point being here is that we're also establishing a process for the community to self-determine the way forward in a transparent and verifiable manner. What's not to like? :) I'll probably have some time on Sunday to help hack something up but I don't think this is that heavy a coding lift? What am I missing? As Matt mentioned, many members of the bitcoin community would be hesitant about giving miners this much power. It essentially lets them vote to change the rules of the system. But miners are not the only part of this ecosystem, and they are not the only ones affected by the choice of block size limit, so they probably shouldn't be the only ones with a vote. Instead, we vote with the software we run, and all upgrade. So, while I think an idea like this has its merits, I would bet that it's fairly unlikely to get enough support to be merged into bitcoin core. Best, Stephen -- ___ 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] Max Block Size: Simple Voting Procedure
Pindar, yes and it's a good idea to separate the hard/soft fork upgrades. The point being here is that we're also establishing a process for the community to self-determine the way forward in a transparent and verifiable manner. What's not to like? :) I'll probably have some time on Sunday to help hack something up but I don't think this is that heavy a coding lift? What am I missing? As Matt mentioned, many members of the bitcoin community would be hesitant about giving miners this much power. It essentially lets them vote to change the rules of the system. But miners are not the only part of this ecosystem, and they are not the only ones affected by the choice of block size limit, so they probably shouldn't be the only ones with a vote. Instead, we vote with the software we run, and all upgrade. So, while I think an idea like this has its merits, I would bet that it's fairly unlikely to get enough support to be merged into bitcoin core. Best, Stephen -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Max Block Size: Simple Voting Procedure
Vincent, Some changes: Votes need to be 100%, not 50.01%. That way small miners have a fair chance. A 50.01% vote means large miners call the shots. While I like the idea of possibly requiring more than 50%, you wouldn't want to have a situation where a minority of uncooperative (or just lazy) miners don't add their votes and hold up progress. Maybe 2/3 instead of 1/2, though. Users (people who make transactions) need to vote. A vote by a miner shouldn't count without user votes. Fee incentives should attract legitimate votes from miners. A cheating miner will be defeated by another miner who includes those votes, and take the fees. This lets wallet providers and exchanges cast votes (few wallets will implement prompts and will just auto vote, so if you don't agree, switch wallets. Vote with your wallet). The idea of voting with your wallet, while appealing, is technically infeasible. Miners can fill their blocks with any type of transactions, including their own specially designed transactions. And any fees from these transactions can be collected right back into their coinbase transaction. - Stephen -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposed alternatives to the 20MB step
1,000 *people* in control vs. 10 is two orders of magnitude more decentralized. Yet Bitcoin has got worse by all these metrics: there was a time before mining pools when there were ~thousands of people mining with their local CPUs and GPUs. Now the number of full nodes that matter for block selection number in the dozens, and all the other miners just follow their blocks blindly. 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). That's not the vibe I'm getting from most people on this list. What I'm seeing is complaints about how in the good old days back when Core was the only wallet and ASICs hadn't been made, there were lots of nodes and lots of people mining solo and since then it's all been downhill and woe is us ... and let's throw on the brakes in case it gets worse. Not for the first time, these discussions remind me very strongly of the old desktop Linux/free software debates. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Fwd: Block Size Increase Requirements
On 2 June 2015 at 14:26, Mike Hearn m...@plan99.net wrote: But the majority of the hashrate can now perform double spends on your chain! They can send bitcoins to exchanges, sell it, extract the money and build a new longer chain to get their bitcoins back. Obviously if the majority of the mining hash rate is doing double spending attacks on exchanges then the Bitcoin experiment is resolved as a failure and it will become abandoned. This has been known since day one: it's in the white paper. The basic assumption behind Bitcoin is that only a minority of actors are dishonest - if the majority are then Satoshi's scheme does not work. So you are not stating anything new here. It's both consistent and credible for an agent to commit to honesty on a chain that it openly supports and dishonesty on a chain that it openly opposes. (Moral? Legal? Perhaps not.) That said, majority hashpower doesn't need to be dishonest to stop a change to large blocks. It just needs to refuse to build on blocks that it doesn't like. The minority isn't going to mine blocks larger than 1MB if it knows they'll be orphaned. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] [BIP draft] Consensus-enforced transaction replacement signalled via sequence numbers
That would also introduce the anomaly of a script that was once valid
becoming later invalid, when nothing varies other than time. That is
not super compatible with the current model of reprocessing
transactions in later blocks if the block they were first in gets
reorged.
Very good point.
(Not a huge flexibility loss as you can implement not after by
making it the previous holders responsibility to spend a not before
back to themselves.)
Do you mean something like the below?
scriptPubKey:
IF
{A's pub} CHECKSIGVERIFY
ELSE
{curr_height + 100} CLTV {B's pub} CHECKSIGVERIFY
This ensures that Alice has to spend the output in the next 100 blocks or
risk it being taken from her (she just has to put an OP_TRUE on the end of
her scriptSig). So, it seems we can forget about an inverted CLTV/CSV,
great!
Best,
Stephen
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] DevCore London
Hi there, I got some requests to re-record the tutorial talk I gave at DevCore 2015, How to build a timestamping smart contracts app in 30 minutes. It's now available here: https://bitcoinj.github.io/document-timestamp-app It covers: - How to customise the wallet-template app for this use case - How to construct a complex multi-stage SPV proof of block chain inclusion - How to save and then verify proof files - How to bind transaction confidence state to the user interface - How to create a Mac DMG bundle with a custom icon I hope someone finds it enjoyable! On Thu, Apr 9, 2015 at 10:23 PM, Mike Hearn m...@plan99.net wrote: Next week on April 15th Gavin, Wladimir, Corey and myself will be at DevCore London: https://everyeventgives.com/event/devcore-london If you're in town why not come along? It's often the case that conferences can be just talking shops, without much meat for real developers. So in the afternoon I'll be doing two things: 1. Running a hackathon/workshop type event. The theme is contracts, but we can hack on whatever you all feel like. 2. My talk will actually be a live coding event. Writing contracts apps has become a lot easier in the past few years, and to prove it to you I will write a decentralised cross-platform Tor supporting document timestamping app that uses OP_RETURN outputs and has a nice GUI . in 30 minutes, on stage. Don't think it can be done? Turn up and see for yourself. See you there! -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Fwd: Block Size Increase Requirements
But the majority of the hashrate can now perform double spends on your chain! They can send bitcoins to exchanges, sell it, extract the money and build a new longer chain to get their bitcoins back. Obviously if the majority of the mining hash rate is doing double spending attacks on exchanges then the Bitcoin experiment is resolved as a failure and it will become abandoned. This has been known since day one: it's in the white paper. The basic assumption behind Bitcoin is that only a minority of actors are dishonest - if the majority are then Satoshi's scheme does not work. So you are not stating anything new here. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] [BIP draft] Consensus-enforced transaction replacement signalled via sequence numbers
That would also introduce the anomaly of a script that was once valid becoming later invalid, when nothing varies other than time. That is not super compatible with the current model of reprocessing transactions in later blocks if the block they were first in gets reorged. (Not a huge flexibility loss as you can implement not after by making it the previous holders responsibility to spend a not before back to themselves.) Adam On 2 June 2015 at 13:52, Stephen stephencalebmo...@gmail.com wrote: Do you think it would be useful to have an inverted version of both CSV and CLTV? To verify if an output is spent before a specific time. CLTV and CSV could be implemented by taking two stack arguments, an integer for the comparison and TRUE/FALSE. Now that I think about this more, the problem is that, for example, just having a lock time of less than some value doesn't actually mean it has to be spent before that script value, so this might not work. Likely any implementations of such a feature would have to provide the script execution environment with access to information that it doesn't have now, which is what we are trying to avoid. Best, Stephen On Jun 2, 2015, at 12:16 AM, Mark Friedenbach m...@friedenbach.org wrote: You are correct! I am maintaining a 'checksequenceverify' branch in my git repository as well, an OP_RCLTV using sequence numbers: https://github.com/maaku/bitcoin/tree/checksequenceverify Most of the interesting use cases for relative lock-time require an RCLTV opcode. What is interesting about this architecture is that it possible to cleanly separate the relative lock-time (sequence numbers) from the RCLTV opcode (OP_CHECKSEQUENCEVERIFY) both in concept and in implementation. Like CLTV, the CSV opcode only checks transaction data and requires no contextual knowledge about block headers, a weakness of the other RCLTV proposals that violate the clean separation between libscript and libconsensus. In a similar way, this BIP proposal only touches the transaction validation logic without any impact to script. I would like to propose an additional BIP covering the CHECKSEQUENCEVERIFY opcode and its enabling applications. But, well, one thing at a time. On Mon, Jun 1, 2015 at 8:45 PM, Stephen Morse stephencalebmo...@gmail.com wrote: Hi Mark, Overall, I like this idea in every way except for one: unless I am missing something, we may still need an OP_RCLTV even with this being implemented. In use cases such as micropayment channels where the funds are locked up by multiple parties, the enforcement of the relative locktime can be done by the first-signing party. So, while your solution would probably work in cases like this, where multiple signing parties are involved, there may be other, seen or unforeseen, use cases that require putting the relative locktime right into the spending contract (the scriptPubKey itself). When there is only one signer, there's nothing that enforces using an nSequence and nVersion=2 that would prevent spending the output until a certain time. I hope this is received as constructive criticism, I do think this is an innovative idea. In my view, though, it seems to be less fully-featured than just repurposing an OP_NOP to create OP_RCLTV. The benefits are obviously that it saves transaction space by repurposing unused space, and would likely work for most cases where an OP_RCLTV would be needed. Best, Stephen On Mon, Jun 1, 2015 at 9:49 PM, Mark Friedenbach m...@friedenbach.org wrote: I have written a reference implementation and BIP draft for a soft-fork change to the consensus-enforced behaviour of sequence numbers for the purpose of supporting transaction replacement via per-input relative lock-times. This proposal was previously discussed on the mailing list in the following thread: http://sourceforge.net/p/bitcoin/mailman/message/34146752/ In short summary, this proposal seeks to enable safe transaction replacement by re-purposing the nSequence field of a transaction input to be a consensus-enforced relative lock-time. The advantages of this approach is that it makes use of the full range of the 32-bit sequence number which until now has rarely been used for anything other than a boolean control over absolute nLockTime, and it does so in a way that is semantically compatible with the originally envisioned use of sequence numbers for fast mempool transaction replacement. The disadvantages are that external constraints often prevent the full range of sequence numbers from being used when interpreted as a relative lock-time, and re-purposing nSequence as a relative lock-time precludes its use in other contexts. The latter point has been partially addressed by having the relative lock-time semantics be enforced only if the most-significant bit of nSequence is set. This preserves 31 bits for alternative use when relative lock-times are not required. The BIP draft can be found at
Re: [Bitcoin-development] [BIP draft] Consensus-enforced transaction replacement signalled via sequence numbers
Do you think it would be useful to have an inverted version of both CSV and CLTV? To verify if an output is spent before a specific time. CLTV and CSV could be implemented by taking two stack arguments, an integer for the comparison and TRUE/FALSE. Now that I think about this more, the problem is that, for example, just having a lock time of less than some value doesn't actually mean it has to be spent before that script value, so this might not work. Likely any implementations of such a feature would have to provide the script execution environment with access to information that it doesn't have now, which is what we are trying to avoid. Best, Stephen On Jun 2, 2015, at 12:16 AM, Mark Friedenbach m...@friedenbach.org wrote: You are correct! I am maintaining a 'checksequenceverify' branch in my git repository as well, an OP_RCLTV using sequence numbers: https://github.com/maaku/bitcoin/tree/checksequenceverify Most of the interesting use cases for relative lock-time require an RCLTV opcode. What is interesting about this architecture is that it possible to cleanly separate the relative lock-time (sequence numbers) from the RCLTV opcode (OP_CHECKSEQUENCEVERIFY) both in concept and in implementation. Like CLTV, the CSV opcode only checks transaction data and requires no contextual knowledge about block headers, a weakness of the other RCLTV proposals that violate the clean separation between libscript and libconsensus. In a similar way, this BIP proposal only touches the transaction validation logic without any impact to script. I would like to propose an additional BIP covering the CHECKSEQUENCEVERIFY opcode and its enabling applications. But, well, one thing at a time. On Mon, Jun 1, 2015 at 8:45 PM, Stephen Morse stephencalebmo...@gmail.com wrote: Hi Mark, Overall, I like this idea in every way except for one: unless I am missing something, we may still need an OP_RCLTV even with this being implemented. In use cases such as micropayment channels where the funds are locked up by multiple parties, the enforcement of the relative locktime can be done by the first-signing party. So, while your solution would probably work in cases like this, where multiple signing parties are involved, there may be other, seen or unforeseen, use cases that require putting the relative locktime right into the spending contract (the scriptPubKey itself). When there is only one signer, there's nothing that enforces using an nSequence and nVersion=2 that would prevent spending the output until a certain time. I hope this is received as constructive criticism, I do think this is an innovative idea. In my view, though, it seems to be less fully-featured than just repurposing an OP_NOP to create OP_RCLTV. The benefits are obviously that it saves transaction space by repurposing unused space, and would likely work for most cases where an OP_RCLTV would be needed. Best, Stephen On Mon, Jun 1, 2015 at 9:49 PM, Mark Friedenbach m...@friedenbach.org wrote: I have written a reference implementation and BIP draft for a soft-fork change to the consensus-enforced behaviour of sequence numbers for the purpose of supporting transaction replacement via per-input relative lock-times. This proposal was previously discussed on the mailing list in the following thread: http://sourceforge.net/p/bitcoin/mailman/message/34146752/ In short summary, this proposal seeks to enable safe transaction replacement by re-purposing the nSequence field of a transaction input to be a consensus-enforced relative lock-time. The advantages of this approach is that it makes use of the full range of the 32-bit sequence number which until now has rarely been used for anything other than a boolean control over absolute nLockTime, and it does so in a way that is semantically compatible with the originally envisioned use of sequence numbers for fast mempool transaction replacement. The disadvantages are that external constraints often prevent the full range of sequence numbers from being used when interpreted as a relative lock-time, and re-purposing nSequence as a relative lock-time precludes its use in other contexts. The latter point has been partially addressed by having the relative lock-time semantics be enforced only if the most-significant bit of nSequence is set. This preserves 31 bits for alternative use when relative lock-times are not required. The BIP draft can be found at the following gist: https://gist.github.com/maaku/be15629fe64618b14f5a The reference implementation is available at the following git repository: https://github.com/maaku/bitcoin/tree/sequencenumbers I request that the BIP editor please assign a BIP number for this work. Sincerely, Mark Friedenbach -- ___
Re: [Bitcoin-development] [BIP draft] Consensus-enforced transaction replacement signalled via sequence numbers
Oh it is far worse than that. There is nothing preventing those coins from being spent somewhere else, so actually an expiry would enable coin theft in a reorg -- you make your spends expire right after they hit the chain the first time, and then if there is a reorg the spend and subsequent transactions are invalidated. This is an exploitable means of theft. For this reason it is very important to male sure that once a transaction makes it on the chain, it cannot be invalidated by means of a reorg. On Jun 2, 2015 6:11 AM, Adam Back a...@cypherspace.org wrote: That would also introduce the anomaly of a script that was once valid becoming later invalid, when nothing varies other than time. That is not super compatible with the current model of reprocessing transactions in later blocks if the block they were first in gets reorged. (Not a huge flexibility loss as you can implement not after by making it the previous holders responsibility to spend a not before back to themselves.) Adam On 2 June 2015 at 13:52, Stephen stephencalebmo...@gmail.com wrote: Do you think it would be useful to have an inverted version of both CSV and CLTV? To verify if an output is spent before a specific time. CLTV and CSV could be implemented by taking two stack arguments, an integer for the comparison and TRUE/FALSE. Now that I think about this more, the problem is that, for example, just having a lock time of less than some value doesn't actually mean it has to be spent before that script value, so this might not work. Likely any implementations of such a feature would have to provide the script execution environment with access to information that it doesn't have now, which is what we are trying to avoid. Best, Stephen On Jun 2, 2015, at 12:16 AM, Mark Friedenbach m...@friedenbach.org wrote: You are correct! I am maintaining a 'checksequenceverify' branch in my git repository as well, an OP_RCLTV using sequence numbers: https://github.com/maaku/bitcoin/tree/checksequenceverify Most of the interesting use cases for relative lock-time require an RCLTV opcode. What is interesting about this architecture is that it possible to cleanly separate the relative lock-time (sequence numbers) from the RCLTV opcode (OP_CHECKSEQUENCEVERIFY) both in concept and in implementation. Like CLTV, the CSV opcode only checks transaction data and requires no contextual knowledge about block headers, a weakness of the other RCLTV proposals that violate the clean separation between libscript and libconsensus. In a similar way, this BIP proposal only touches the transaction validation logic without any impact to script. I would like to propose an additional BIP covering the CHECKSEQUENCEVERIFY opcode and its enabling applications. But, well, one thing at a time. On Mon, Jun 1, 2015 at 8:45 PM, Stephen Morse stephencalebmo...@gmail.com wrote: Hi Mark, Overall, I like this idea in every way except for one: unless I am missing something, we may still need an OP_RCLTV even with this being implemented. In use cases such as micropayment channels where the funds are locked up by multiple parties, the enforcement of the relative locktime can be done by the first-signing party. So, while your solution would probably work in cases like this, where multiple signing parties are involved, there may be other, seen or unforeseen, use cases that require putting the relative locktime right into the spending contract (the scriptPubKey itself). When there is only one signer, there's nothing that enforces using an nSequence and nVersion=2 that would prevent spending the output until a certain time. I hope this is received as constructive criticism, I do think this is an innovative idea. In my view, though, it seems to be less fully-featured than just repurposing an OP_NOP to create OP_RCLTV. The benefits are obviously that it saves transaction space by repurposing unused space, and would likely work for most cases where an OP_RCLTV would be needed. Best, Stephen On Mon, Jun 1, 2015 at 9:49 PM, Mark Friedenbach m...@friedenbach.org wrote: I have written a reference implementation and BIP draft for a soft-fork change to the consensus-enforced behaviour of sequence numbers for the purpose of supporting transaction replacement via per-input relative lock-times. This proposal was previously discussed on the mailing list in the following thread: http://sourceforge.net/p/bitcoin/mailman/message/34146752/ In short summary, this proposal seeks to enable safe transaction replacement by re-purposing the nSequence field of a transaction input to be a consensus-enforced relative lock-time. The advantages of this approach is that it makes use of the full range of the 32-bit sequence number which until now has rarely been used for anything other than a boolean control over absolute
Re: [Bitcoin-development] [BIP draft] Consensus-enforced transaction replacement signalled via sequence numbers
I am glad to see the transaction version number increase. The commit doesn't update the default transaction version though. The node would still produce version 1 transactions. Does the reference client already produce transactions with final sequence numbers? If so, then they will be valid version 2 transactions. If it sets the sequence to all zeros, then it won't trigger the new code either. I think simply bumping the default version number to 2 would be safe. For the timestamp locktime, median block time would be better than raw block time. Median time is the median timestamp of the previous 11 blocks. This reduces the incentive to mess with the timestamp. Median time is earlier than block time, but since things are relative, it should balance out. Miners have around 2 hours worth of flexibility when setting the timestamps, so it may not be that big a deal. On Tue, Jun 2, 2015 at 5:34 AM, Stephen Morse stephencalebmo...@gmail.com wrote: I see, so OP_SEQUENCEVERIFY will have a value pushed on the stack right before, and then check that the input spending the prevout has nSequence corresponds to at least the sequence specified by the stack value. Good idea! Keeps the script code from depending on external chain specific data, which is nice. Hopefully we can repurpose one of the OP_NOPs for CHECKLOCKTIMEVERIFY and one for OP_CHECKSEQUENCEVERIFY. Very complementary. Best, Stephen On Tue, Jun 2, 2015 at 12:16 AM, Mark Friedenbach m...@friedenbach.org wrote: You are correct! I am maintaining a 'checksequenceverify' branch in my git repository as well, an OP_RCLTV using sequence numbers: https://github.com/maaku/bitcoin/tree/checksequenceverify Most of the interesting use cases for relative lock-time require an RCLTV opcode. What is interesting about this architecture is that it possible to cleanly separate the relative lock-time (sequence numbers) from the RCLTV opcode (OP_CHECKSEQUENCEVERIFY) both in concept and in implementation. Like CLTV, the CSV opcode only checks transaction data and requires no contextual knowledge about block headers, a weakness of the other RCLTV proposals that violate the clean separation between libscript and libconsensus. In a similar way, this BIP proposal only touches the transaction validation logic without any impact to script. I would like to propose an additional BIP covering the CHECKSEQUENCEVERIFY opcode and its enabling applications. But, well, one thing at a time. On Mon, Jun 1, 2015 at 8:45 PM, Stephen Morse stephencalebmo...@gmail.com wrote: Hi Mark, Overall, I like this idea in every way except for one: unless I am missing something, we may still need an OP_RCLTV even with this being implemented. In use cases such as micropayment channels where the funds are locked up by multiple parties, the enforcement of the relative locktime can be done by the first-signing party. So, while your solution would probably work in cases like this, where multiple signing parties are involved, there may be other, seen or unforeseen, use cases that require putting the relative locktime right into the spending contract (the scriptPubKey itself). When there is only one signer, there's nothing that enforces using an nSequence and nVersion=2 that would prevent spending the output until a certain time. I hope this is received as constructive criticism, I do think this is an innovative idea. In my view, though, it seems to be less fully-featured than just repurposing an OP_NOP to create OP_RCLTV. The benefits are obviously that it saves transaction space by repurposing unused space, and would likely work for most cases where an OP_RCLTV would be needed. Best, Stephen On Mon, Jun 1, 2015 at 9:49 PM, Mark Friedenbach m...@friedenbach.org wrote: I have written a reference implementation and BIP draft for a soft-fork change to the consensus-enforced behaviour of sequence numbers for the purpose of supporting transaction replacement via per-input relative lock-times. This proposal was previously discussed on the mailing list in the following thread: http://sourceforge.net/p/bitcoin/mailman/message/34146752/ In short summary, this proposal seeks to enable safe transaction replacement by re-purposing the nSequence field of a transaction input to be a consensus-enforced relative lock-time. The advantages of this approach is that it makes use of the full range of the 32-bit sequence number which until now has rarely been used for anything other than a boolean control over absolute nLockTime, and it does so in a way that is semantically compatible with the originally envisioned use of sequence numbers for fast mempool transaction replacement. The disadvantages are that external constraints often prevent the full range of sequence numbers from being used when interpreted as a relative lock-time, and re-purposing nSequence as a relative lock-time precludes its use in other contexts. The latter point has
Re: [Bitcoin-development] Proposed alternatives to the 20MB step
On 06/02/2015 04:03 AM, Mike Hearn wrote: 1,000 *people* in control vs. 10 is two orders of magnitude more decentralized. Yet Bitcoin has got worse by all these metrics: there was a time before mining pools when there were ~thousands of people mining with their local CPUs and GPUs. Now the number of full nodes that matter for block selection number in the dozens, and all the other miners just follow their blocks blindly. A mining pool is not a person, a full node is not a miner, and cooperation is not control. http://bravenewcoin.com/news/number-of-bitcoin-miners-far-higher-than-popular-estimates/ The entire Bitcoin ecosystem cooperates, that is what consensus means. Establishing proof of that cooperation is the purpose of Bitcoin. Decentralization is about keeping control out of the hands of the state (any entity that would substitute violence for consensus). Nobody has the power to compel the cooperation of individual miners in a pool. When state power is applied to a pool operator the miners (people) retain their vote. e signature.asc Description: OpenPGP digital signature -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
