Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee
It is disappointing that F2Pool would enable full RBF when the safe alternative, first-seen-safe RBF, is also available, especially since the fees they would gain by supporting full RBF over FSS RBF would likely be negligible. Did they consider using FSS RBF instead? Best, Stephen On Fri, Jun 19, 2015 at 6:39 AM, Peter Todd p...@petertodd.org wrote: Yesterday F2Pool, currently the largest pool with 21% of the hashing power, enabled full replace-by-fee (RBF) support after discussions with me. This means that transactions that F2Pool has will be replaced if a conflicting transaction pays a higher fee. There are no requirements for the replacement transaction to pay addresses that were paid by the previous transaction. I'm a user. What does this mean for me? --- In the short term, very little. Wallet software aimed at average users has no ability to reliably detect conditions where an unconfirmed transaction may be double-spent by the sender. For example, Schildbach's Bitcoin Wallet for Android doesn't even detect double-spends of unconfirmed transactions when connected to a RBF or Bitcoin XT nodes that propagate them. The least sophisticated double-spend attack possibly - simply broadcasting two conflicting transactions at the same time - has about 50% probability of success against these wallets. Additionally, SPV wallets based on bitcoinj can't even detect invalid transactions reliably, instead trusting the full node(s) it is connected too over the unauthenticated, unencrypted, P2P protocol to do validation for them. For instance due to a unfixed bug¹ Bitcoin XT nodes will relay double-spends that spend the output of the conflicting transaction. I've personally tested this with Schildbach's Bitcoin Wallet for Android, which shows such invalid transactions as standard, unconfirmed, transactions. Users should continue to assume that unconfirmed transactions could be trivially reversed by the sender until the first confirmation. In general, only the sender can reverse a transaction, so if you do trust the sender feel free to assume an unconfirmed transaction will eventually confirm. However, if you do not trust the sender and/or have no other recourse if they double-spend you, wait until at least the first confirmation before assuming the transaction will go through. In the long term, miner support of full RBF has a number of advantages to users, allowing you to more efficiently make transactions, paying lower fees. However you'll need a wallet supporting these features; none exist yet. I'm a business. What does this mean for me? --- If you use your own node to verify transactions, you probably are in a similar situation as average users, so again, this means very little to you. If you use a payment processor/transaction API such as BitPay, Coinbase, BlockCypher, etc. you may or may not be accepting unconfirmed transactions, and they may or may not be guaranteed by your payment processor even if double-spent. If like most merchants you're using the API such that confirmations are required prior to accepting orders (e.g. taking a meaningful loss such as shipping a product if the tx is reversed) nothing changes for you. If not I recommend you contact your payment processor. I'm a miner. Why should I support replace-by-fee? - Whether full or first-seen-safe⁵ RBF support (along with child-pays-for-parent) is an important step towards a fully functioning transaction fee market that doesn't lead to users' transactions getting mysteriously stuck, particularly during network flooding events/attacks. A better functioning fee market will help reduce pressure to increase the blocksize, particularly from the users creating the most valuable transactions. Full RBF also helps make use of the limited blockchain space more efficiently, with up to 90%+ transaction size savings possible in some transaction patterns. (e.g. long payment chains⁶) More users in less blockchain space will lead to higher overall fees per block. Finally as we'll discuss below full RBF prevents a number of serious threats to the existing level playing field that miners operate in. Why can't we make accepting unconfirmed txs from untrusted people safe? --- For a decentralized wallet, the situation is pretty bleak. These wallets only have a handful of connections to the network, with no way of knowing if those connections give an accurate view of what transactions miners actually know about. The only serious attempt to fix this problem for decentralized wallets that has been actually deployed is Andresen/Harding's double-spend relaying, implemented in Bitcoin XT. It relays up to one double-spend transaction per double-spent txout, with the intended effect to warn
Re: [Bitcoin-development] Ninki Wallet view on blocksize debate
Ben, How does your wallet calculate the fee that should be paid to miners? Do they automatically adjust when transactions take a long time to be confirmed? And how does it respond when transactions are not mined successfully, such as when blocks are full? I strongly urge Gavin to withdraw from this standoff and work with the bitcoin core devs via the existing and successful bip process. The BIP process has not resulted in any hard forks, so this is a little different. While I don't like MG's proposed solution of convincing miners and services to switch to Bitcoin-XT, I recognize that it is done out of a sense of urgency. These types of changes take a long time to roll out, and we should start them before it is too late. This whole debate comes down to: what is more risky, a consensus hard fork or letting bitcoin exceed its imposed capacity limits? The former could result in many services not being compatible and even loss of funds. The latter could result in software failures, instability, and inability to transact: essentially, what bitcoin is supposed to be good at. Both are dangerous and could result in a significant loss of public confidence. Something needs to be done, that's for sure. In the short term, I think we need to do one of two things: 1. All miners and wallet developers need to upgrade to support first-safe RBF, to allow for double spending one's own transactions when they lack sufficient fees to merit confirmations. Wallets also need to randomly request transactions from blocks to see what kind of fees are being paid to get confirmations, so that fees can be paid dynamically instead of with hard-coded values. 2. We can implement either Gavin's or Jeff Garzik's proposal to change the consensus parameters around the block size limit. So Ben, if really don't think that going with #2 is the right way to go (even though everyone agrees that we will need to increase the block size limit eventually anyway, why not now?), then I hope you start to work hard on implementing #1 so that your wallet software can handle hitting capacity limits gracefully. 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
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
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] [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] [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
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 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 -- ___ 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
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 -- ___ 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] Normalized Transaction IDs
An option would be that the height is included in the scriptSig for all
transactions, but for non-coinbase transctions, the height used is zero.
No need to add an extra field to the transaction just to include the
height. We can just add a rule that the height specified in the scriptSig
in coinbase transactions (and only coinbase transactions) is copied into
the locktime of the transaction before computing the normalized transaction
ID and leave the locktime untouched for all normal transactions
No need to replace lock times (or any other part of the transaction) at
all. If you have to, just serialize the height right before serializing the
transaction (into the same buffer). And you could pre-serialize 0 instead
of the height for all non-coinbase transactions. I don't really see what
that gets you, though, because the 0 is not really doing anything.
But, I don't see any reason you have to mess with the serialization this
much at all. Just do:
uint256 normalized_txid(CTransaction tx)
{
// Coinbase transactions are already normalized
if (!tx.IsCoinbase())
{
foreach(CTxIn in : tx.vin)
{
if (!ReplacePrevoutHashWithNormalizedHash(in.prevout))
throw NormalizationError(Could not lookup prevout);
in.scriptSig.clear();
}
}
// Serialize
CHashWriter ss(SER_GETHASH, 0);
ss tx;
return ss.GetHash();
}
An alternative could be (although I like the above option better):
uint256 normalized_txid(CTransaction tx, int nHeight)
{
foreach(CTxIn in : tx.vin)
{
if (!in.prevout.IsNull()
!ReplacePrevoutHashWithNormalizedHash(in.prevout))
throw NormalizationError(Could not lookup prevout);
in.scriptSig.clear();
}
// Serialize
CHashWriter ss(SER_GETHASH, 0);
if (tx.IsCoinbase())
ss nHeight;
// or:
// ss (tx.IsCoinbase() ? nHeight : 0);
ss tx;
return ss.GetHash();
}
--
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Block Size Increase Requirements
Comments in line: On May 8, 2015, at 11:08 PM, Peter Todd p...@petertodd.org wrote: Makes it trivial to find miners and DoS attack them - a huge risk to the network as a whole, as well as the miners. Right now pools already get DoSed all the time through their work submission systems; getting DoS attacked via their nodes as well would be a disaster. It seems that using a -miner flag to follow rules about smaller blocks would only reveal miner nodes if one sent the node a solved block that that was valid in every way except the block size. While not impossible, I wouldn't call this trivial, as it still requires wasting an entire block's worth of energy. When in miner mode, the client would reject 4MB blocks and wouldn't build on them. The reference client might even track the miner and the non-miner chain tip. Miners would refuse to build on 5MB blocks, but merchants and general users would accept them. That'd be an excellent way to double-spend merchants, significantly increasing the chance that the double-spend would succeed as you only have to get sufficient hashing power to get the lucky blocks; you don't need enough hashing power to *also* ensure those blocks don't become the longest chain, removing the need to sybil attack your target. I think this could be mitigated by counting confirmations differently. We should think of confirmations as only coming from blocks following the miners' more strict rule set. So if a merchant were to see payment for the first time in a block that met their own size restrictions but not the miners', then they would simply count it as unconfirmed. If they get deep enough in the chain, though, the client should probably count them as being confirmed anyway, even if they don't meet the client nodes' expectation of the miners' block size limit. This happening probably just means that the client has not updated their software (or -minermaxblocksize configuration, depending on how it is implemented) in a long time. I actually like Tier's suggestion quite a bit. I think we could have the default client limit set to some higher number, and have miners agree out of band on the latest block size limit. Or maybe even build in a way to vote into the blockchain. Best, Stephen -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] [BIP] Normalized Transaction IDs
We should make sure to consider how BIP34 affects normalized transaction ids, since the height of the block is included in the scriptSig ensuring that the txid will be different. We wouldn't want to enable replay attacks in the form of spending coinbase outputs in the same way they were spent from a previous block. So maybe normalized txids should strip the scriptSigs of all transactions except for coinbase transactions? This seems to make sense, since coinbase transactions are inherently not malleable anyway. Also, s7r linked to my 'Build your own nHashType' proposal (although V2 is here: https://github.com/scmorse/bitcoin-misc/blob/master/sighash_proposal_v2.md). I just wanted to add that I think even with normalized ids, it could still be useful to be able to apply these flags to choose which parts of the transaction become signed. I've also seen vague references to some kind of a merklized abstract syntax tree, but am not fully sure how that would work. Maybe someone on here could explain it? Best, Stephen On May 15, 2015, at 5:54 AM, s7r s...@sky-ip.org wrote: Hello, How will this exactly be safe against: a) the malleability of the parent tx (2nd level malleability) b) replays If you strip just the scriptSig of the input(s), the txid(s) can still be mutated (with higher probability before it gets confirmed). If you strip both the scriptSig of the parent and the txid, nothing can any longer be mutated but this is not safe against replays. This could work if we were using only one scriptPubKey per tx. But this is not enforced, and I don't think it's the proper way to do it. Something similar can be achieved if you would use a combination of flags from here: https://github.com/scmorse/bitcoin-misc/blob/master/sighash_proposal.md But this has some issues too. I've read your draft but didn't understand how exactly will this prevent normal malleability as we know it, second level malleability and replays as well as how will we do the transition into mapping the txes in the blockchain to normalized txids. Looking forward to read more on this topic. Thanks for the brainstorming ;) On 5/13/2015 3:48 PM, Christian Decker wrote: Hi All, I'd like to propose a BIP to normalize transaction IDs in order to address transaction malleability and facilitate higher level protocols. The normalized transaction ID is an alias used in parallel to the current (legacy) transaction IDs to address outputs in transactions. It is calculated by removing (zeroing) the scriptSig before computing the hash, which ensures that only data whose integrity is also guaranteed by the signatures influences the hash. Thus if anything causes the normalized ID to change it automatically invalidates the signature. When validating a client supporting this BIP would use both the normalized tx ID as well as the legacy tx ID when validating transactions. The detailed writeup can be found here: https://github.com/cdecker/bips/blob/normalized-txid/bip-00nn.mediawiki. @gmaxwell: I'd like to request a BIP number, unless there is something really wrong with the proposal. In addition to being a simple alternative that solves transaction malleability it also hugely simplifies higher level protocols. We can now use template transactions upon which sequences of transactions can be built before signing them. I hesitated quite a while to propose it since it does require a hardfork (old clients would not find the prevTx identified by the normalized transaction ID and deem the spending transaction invalid), but it seems that hardforks are no longer the dreaded boogeyman nobody talks about. I left out the details of how the hardfork is to be done, as it does not really matter and we may have a good mechanism to apply a bunch of hardforks concurrently in the future. I'm sure it'll take time to implement and upgrade, but I think it would be a nice addition to the functionality and would solve a long standing problem :-) Please let me know what you think, the proposal is definitely not set in stone at this point and I'm sure we can improve it further. Regards, Christian -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box
Re: [Bitcoin-development] A way to create a fee market even without a block size limit (2013)
Why do so many tie the block size debate to creating a fee market, as if one didn't already exist? Yes, today we frequently see many low priority transactions included into the next block, but that does not mean there is not a marketplace for block space. It just means miners are not being sufficiently tough to create a *competitive* marketplace. But who are we to say that the marketplace should be more competitive, and to go further and try to force it by altering consensus rules like the block size limit? If miners want to see more competitive fees, then they need only to alter their block creation protocol. There are many arguments for and against changing the consensus limit on block size. I'm simply saying that to force a marketplace for fees/block space should not be one of them. Let the market develop on it's own. - Stephen On May 10, 2015, at 4:45 PM, Sergio Lerner sergioler...@certimix.com wrote: Two years ago I presented a new way to create a fee market that does not depend on the block chain limit. This proposal has not been formally analyzed in any paper since then, but I think it holds a good promise to untangle the current problem regarding increasing the tps and creating the fee market. BTW, think the maximum tps should be increased, but not by increasing the block size, but by increasing the block rate (I'll expose why in my next e-mail). The original post is here (I was overly optimistic back then): https://bitcointalk.org/index.php?topic=147124.msg1561612#msg1561612 I'll summarize it here again, with a little editing and a few more questions at the end: The idea is simple, but requires a hardfork, but is has minimum impact in the code and in the economics. Solution: Require that the set of fees collected in a block has a dispersion below a threshold. Use, for example, the Coefficient of Variation (http://en.wikipedia.org/wiki/Coefficient_of_variation). If the CoVar is higher than a fixed threshold, the block is considered invalid. The Coefficient of variation is computed as the standard deviation over the mean value, so it's very easy to compute. (if the mean is zero, we assume CoVar=0). Note that the CoVar function does not depend on the scale, so is just what a coin with a floating price requires. This means that if there are many transactions containing high fees in a block, then free transactions cannot be included. The core devs should tweak the transaction selection algorithm to take into account this maximum bound. Example If the transaction fee set is: 0,0,0,0,5,5,6,7,8,7 The CoVar is 0.85 Suppose we limit the CoVar to a maximum of 1. Suppose the transaction fee set is: 0,0,0,0,0,0,0,0,0,10 Then the CoVar is 3.0 In this case the miner should have to either drop the 10 from the fee set or drop the zeros. Obviously the miner will drop some zeros, and choose the set: 0,10, that has a CoVar of 1. Why it reduces the Tx spamming Problem? Using this little modification, spamming users would require to use higher fees, only if the remaining users in the community rises their fees. And miners won't be able to include an enormous amounts of spamming txs. Why it helps solving the tragedy-of-the-commons fee problem? As miners are forced to keep the CoVar below the threshold, if people rises the fees to confirm faster than spamming txs, automatically smamming txs become less likely to appear in blocks, and fee-estimators will automatically increase future fees, creating a the desired feedback loop. Why it helps solving the block size problem? Because if we increase the block size, miners that do not care about the fee market won't be able to fill the block with spamming txs and destroy the market that is being created. This is not a solution against an attacker-miner, which can always fill the block with transactions. Can the system by gamed? Can it be attacked? I don't think so. An attacker would need to spend a high amount in fees to prevent transactions with low fees to be included in a block. However, a formal analysis would be required. Miller, Gun Sirer, Eyal.. Want to give it a try? Can create a positive feedback to a rise the fees to the top or push fess to the bottom? Again, I don't think so. This depends on the dynamics between the each node's fee estimator and the transaction backlog. MIT guys? Doesn't it force miners to run more complex algorithms (such as linear programming) to find the optimum tx subset ? Yes, but I don't see it as a drawback, but as a positive stimulus for researchers to develop better tx selection algorithms. Anyway, the greedy algorithm of picking the transactions with highest fees fees would be good enough. PLEASE don't confuse the acronym CoVar I used here with co-variance. Best regard, Sergio
Re: [Bitcoin-development] 75%/95% threshold for transaction versions
Hi William, I personally prefer this solution, since it nails the problem completely with one simple and obvious change. The BIP 62 approach is more like a game of wac-a-mole. The two are complementary, not competing. BIP62 prevents *non-signers* from mutating the transactions, which is very important. The 'Build your own nHashType' proposal enables chained transactions even in the face of *signers* mutating the transaction. I believe that integrating both will lead to the best defense against transaction malleability, and will enable more complicated uses of chained transactions (such as micropayment channels). Best, Stephen -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] 75%/95% threshold for transaction versions
Hi Gregory, In particular not covering the ID allows for transaction replay which can result in monetary losses far more severe than any possible mishandling of malleability could result in. Byzantine attackers can costlessly replay your old transactions any time anyone reuses an address, even accidentally (which cannot be easily prevented since they can race). With the SIGHASH_WITHOUT_PREV_VALUE flag, signatures have to explicitly specify that they are to be signed without the previous UTXO's value/amount. This means that, at worst, replay attacks can send the money to the same place it was sent before (which in many cases is likely not be a loss of funds), and only if the amount sent to the reused address is the exact same as it was before. I don't think this is worse than an attacker being able to mutate their transaction and extort a merchant who accepts zero-conf transactions. Anyway, not signing the input ID wouldn't exactly be the norm, there would be a defined set of flags for standard use cases. Not signing the input TXID would only be used in specialized cases, such as setting up micropayment channels. There are no free lunches; the proposal linked to there is itself a game of wack-a-mole with assorted masking flags; I agree that it is also a bit of wac-a-mole, but the defined space of issues is possibly more limited here. There are only X number of things that can be signed/not signed in a transaction, and the 'Build your own nHashType' proposal enables you to fully specify which of those are being signed. If you don't want to get burned by not fully signing your transactions, then don't use the non-standard sighash flags. many of which we have no notion of if they're useful for any particular application(s); A few of the flags, indeed, may not ever be useful. But we can't predict the future, and I think it's better to build in a more flexible solution now than to wish we had more flexible nHashTypes later. To the original point of this thread, hopefully the suggested proposal won't be necessary as wallets will upgrade to use version 3 transactions and the rules associated with them over time. Best, Stephen -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Build your own nHashType
Hi Mike, Hi Stephen, It's an interesting idea. I'm not sure that all the combinations make sense. Excluding the connected output script or value but still signing the prev tx hash appears pointless: the script cannot change anyway, and you still need to know what it is to actually calculate the inputs to it, so what is the point of this? That's a good point, maybe SIGHASH_WITHOUT_PREV_SCRIPTPUBKEY and SIGHASH_WITHOUT_PREV_VALUE should be assumed false, since you need the data anyway. That gets the total number of flags down to 17. If we eliminate SIGHASH_WITHOUT_TX_VERSION (I can't think of any good reason for this one), then we're down to a 2-byte nHashType. SIGHASH_SIGN_STACK_ELEMENT could also be removed, I'm not convinced of the usefulness of that one either. I also worry that quite a few of these combinations could be unexpectedly dangerous. If you don't sign the prevout hash or value and combine it with a regular pay-to-address output then you've effectively written a blank cheque that can be used by anyone, to claim any money ever sent to that address ... no? And then any p2p node or miner could do so, making the transaction pretty useless. That isn't inherently a problem as long as people understand which combinations have what effects or cannot be used for various reasons. But it would need good documentation and careful thought to explore each possibility people might use. I don't think it's quite a blank check, but it would enable replay attacks in the form of sending the money to the same place it was sent before if an address ever receives coins again. Almost like auto-forwarding addresses. If, in addition, you signed with just that input and no outputs as well, then you're basically forfeiting your rights to any coins sent to that address. It allows for some dangerous combinations, but we already have some dangerous nHashTypes. e.g. SIGHASH_NONE | SIGHASH_ANYONECANPAY. Good documentation and careful developers shouldn't have any issues if they use a standard set of sighash flag combinations for their standard use cases. But developers that need special combinations can now use them, so long as they are careful and think things through. I'll leave the soft fork business to one side for now. I think any change in CHECKSIG or new version of it would likely be ready around the same time as the hard fork we need for changing the block size limit anyway, and it's much cleaner to do it that way. The most important change that we need in sighash calculation, IMO, is ensuring that you don't have to hash data over and over again without a good reason. The current sighash definition is unfortunate because it's possible to make small transactions that involve hashing huge amounts of data. It's not clear to me that your proposal fixes that: ideally there would be one exactly one sighash for one transaction no matter how many checksigs are involved in verifying it. It's hard, though, because there is different data needs to be signed for each input. Although, I suppose if you signed your input with SIGHASH_WITHOUT_PREV_SCRIPTPUBKEY, SIGHASH_WITHOUT_PREV_VALUE, and the equivalent of SIGHASH_ALL, then the hash that needs to be signed would be the same for all of your inputs. Strangely enough, I think we might have just found use cases for the flags that we had nearly dismissed. Another possibility would be to put the previous scriptPubKey and previous output value at the END of the serialized transaction, so that you could make use of some sort of a signature hash midstate. But that feels a little messy. It sort of makes sense to have a base serialization for a transaction and then append it with whatever input/output specific information you have, but still, messy. Is hashing transaction data once for each input really a huge bottleneck, though? Do mobile devices have an issue with this? Best, Stephen -- BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15utm_medium=emailutm_campaign=VA_SF___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Build your own nHashType
Seeking feedback on a proposal that will allow a transaction signer to explicitly specify what is to be serialized for the signature hash. The basic idea is to make the nHashType general enough that we won't need a new sighash flag every time a new use case comes up. If implemented into bitcoin (via a soft fork), this would make malleability almost a non-issue (the TXID referenced by inputs just need to be updated previous TX changes) and would enable hardware wallets to securely sign without needing to download/process each transaction it spends from. Please let me know your thoughts. https://github.com/scmorse/bitcoin-misc/blob/master/sighash_proposal.md -- BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15utm_medium=emailutm_campaign=VA_SF___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] New paper: Research Perspectives and Challenges for Bitcoin and Cryptocurrencies
You might consider the dimension taken by the cooperative mining approach of AI Coin, an altcoin that will launch April 27. The coin is an embodiment of principles described in my whitepaper last May, Bitcoin Cooperative Proof of Stake. http://arxiv.org/abs/1405.5741 Currently we do not use staking, as network-wide algorithmic trustworthiness provides the security directly. Network operations, although highly automated with intelligent software agents, has a human-in-the-loop for oversight. Our innovation enables immediate settlement of transactions. Peers in our network cooperate, taking turns creating new blocks. There is single version of the blockchain which is appended to by a single peer, and is replicated by the other peers. Our peers wrap Bitcoind instances, controlling transaction and new block routing to form a scalable super peer topology. Peers have self-signed X.509 certificates which encrypt messages and prevent impersonation. The tamper-evident technology that secures Bitcoin's blockchain and transactions is extended to secure the entire network. Inspired by an idea published by Nick Szabo, our peers maintain tamper-evident logs which are replayed, verified and signed by other peers. Aside from the whitepaper, more current technical information can be found on our forum - where I would be glad to answer questions and debate skeptics - instead of responding in this list off topic. http://ai-cointalk.org I would like thank those here and on IRC who last year encouraged me think outside the box. -Steve CTO AI Coin, Inc. 512.791.7960 http://ai-coin.org -- 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
Re: [Bitcoin-development] BIP: Voluntary deposit bonds
I agree with Gregory Maxwell, I don't think it would be as easy as just changing IsCoinBase(), since there are places where the code assumes that the coinbase's vin doesn't spend any prevouts and/or has size 1. For example, here https://github.com/bitcoin/bitcoin/blob/v0.9.3/src/main.cpp#L617-620 and here https://github.com/bitcoin/bitcoin/blob/v0.9.3/src/main.cpp#L785-L808 . I think the motivation behind the original suggestion is to have a way to pay specific miners upon solving a block without risking possibly paying other miners through pay-to-fee. What I'm not sure about, though, is why not just send them a transaction once you see that the miner has solved a block? Not a pay-to-fee transaction, a pay to pubkeyhash or whatever type of transaction you need to make to send the miner some coins. Although I don't completely understand the motivation for making such transactions, maybe this would this work. Have outputs in the coinbase transaction which have nValue == 0, then only apply the COINBASE_MATURITY rule to spending coinbase outputs which have non-zero value. That way you could make a transactions which is only valid after the miner specified solves a block with the coinbase having the same TxID referenced by the new transaction's input. It's still a hard fork, but might be easier than allowing the coinbase to spend prevouts. I guess, at that point though, why not just hard fork to allow the coinbase to spend prevouts... Best, Stephen On Tue, Dec 30, 2014 at 1:28 PM, Gregory Maxwell gmaxw...@gmail.com wrote: On Tue, Dec 30, 2014 at 4:25 PM, Sergio Lerner sergioler...@certimix.com wrote: Slight off-topic: That looks like an abuse of the VM. Even P2SH is an abuse of the VM. Gavin's OP_EVAL (hard-fork) should had been chosen. I'm taking about a simple change that goes along the lines of Satoshi's original design. Bitcoin was a beautiful design, and extra complexity is making it ugly. We need Bitcoin to be simple to understand for new programmers so they can keep the project going. It doesn't help the project that one needs to be a guru to code for Bitcoin. Sergio there is no abuse there, OP_NOP3 in that case would be redefined to OP_COINBASE_FOO_CONSISTENCY. (I say FOO because it's not clear what rule you actually hope to apply there.) What you suggested has no purpose by itself: it would need an additional change which overlays functionality in order to actually do something. Such a change would likely be ugly-- it's easy to be elegant when you do nothing. -- 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 -- 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
[Bitcoin-development] Bitcoin Cooperative Proof-of-Stake whitpaper
I completed a whitepaper for Bitcoin a proof-of-stake version which uses a single nomadic verifiable mint agent and distributed replication of a single blockchain by compensated full nodes to achieve 6-hop, sub-second transaction acknowledgement times. Plus it pays dividends to holders instead of wasting it on miners. Subsidized transaction fees are thus lower. https://docs.google.com/document/d/1C4m-MFnxw0JjDorzrKs_IRQRqD9ila79o0IDt6KsbcE Because the code is not yet written, this idea is half-baked so to speak. Comments appreciated on my project thread, which will be a development diary. I plan a hard fork of the Bitcoin blockchain in early 2016, after a year of public system testing, and conditioned on wide approval. https://bitcointalk.org/index.php?topic=584719.msg6397403#msg6397403 -Steve Stephen L. Reed Austin, Texas, USA 512.791.7860-- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proof-of-Stake branch?
My understanding is that sidechains require merged mining support and that sidechains create no coinbase transactions themselves. When Bitcoin Core supports the two-way peg then I would update my source code branch to incorporate that or any other change that is released. Ideally, when sidechains can work with PoW Bitcoin, then those same sidechains should work without any changes with PoS Bitcoin running in my testnet. I will be examining PPC, NXT and whitepapers for ideas that I can implement in such a way as the result can be called Bitcoin. The only difference would be the absence of wasteful Proof-of-Work, and the presence of mining rewards distributed to full nodes in proportion to the amount of bitcoin each is willing to expose to the network. Coin age is a good starting point. A reference peer-to-peer pool developed by me would be responsible for fairly distributing the mining rewards as daily dividend payments to PoS full node pool members. In a few days, I plan to establish a Proof-of-Stake Bitcoin project thread in the Project Development sub-forum of Bitcointalk. We can continue the technical discussion there, starting with a list of principles. Stephen L. Reed Austin, Texas, USA 512.791.7860 On Friday, April 25, 2014 4:42 AM, Jeffrey Paul sn...@acidhou.se wrote: Are proof of stake blockchains compatible with the sidechain/two-way peg system invented by Greg (and maybe others - reports unclear)? http://letstalkbitcoin.com/blockchain-2-0-let-a-thousand-chains-blossom/ It's my limited understanding that any sidechains in such a model are somewhat cryptographically tied to the PoW system that bitcoin's chain uses. I am seriously curious if alternate decentralized consensus algorithms (proof of execution, proof of stake, et c) are compatible with the sidechain universe as envisioned. Perhaps someone with a deeper technical understanding could explain how, if so, or if my incomplete hunch (that alternate consensus algorithms cannot retain compatibility with Bitcoin in a two way peg model) is correct. These sorts of alternate universe altcoin experiments with different proof models take on a different cost/benefit ratio if they can't ever interoperate as sidechains, which is why I'm curious. Best, -jp -- Jeffrey Paul +1 (312) 361-0355 5539 AD00 DE4C 42F3 AFE1 1575 0524 43F4 DF2A 55C2 On 25.04.2014, at 00:33, Troy Benjegerdes ho...@hozed.org wrote: This also might be an interesting application of the side chains concept Peter Todd has discussed. -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Proof-of-Stake branch?
Hello all. I understand that Proof-of-Stake as a replacement for Proof-of-Work is a prohibited yet disputed change to Bitcoin Core. I would like to create a Bitcoin branch that provides a sandboxed testbed for researching the best PoS implementations. In the years to come, perhaps circumstances might arise, such as shifting of user opinion as to whether PoS should be moved from the prohibited list to the hard-fork list. - A poll I conducted today on bitcointalk, https://bitcointalk.org/index.php?topic=581635.0 with an attention-grabbing title suggests some minority support for Bitcoin Proof-of-Stake. I invite any of you to critically comment on that thread. Annual 10% bitcoin dividends can be ours if Proof-of-Stake full nodes outnumber existing Proof-of-Work full nodes by three-to-one. What is your choice? I do not care or do not know enough. - 5 (16.1%) I would download and run the existing Proof-of-Work program to fight the change. - 14 (45.2%) I would download and run the new Proof-of-Stake program to favor the change. - 12 (38.7%) Total Voters: 31 - Before I branch the source code and learn the proper way of doing things in this community, I ask you simply if creating the branch is harmful? My goal is to develop, test and document PoS, while exploring its vulnerabilities and fixing them in a transparent fashion. Thanks for taking a bit of your time to read this message. -Steve Stephen L. Reed Austin, Texas, USA 512.791.7860 -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Blocksize and off-chain transactions
On Wed, Mar 13, 2013 at 2:28 PM, Pieter Wuille pieter.wui...@gmail.comwrote: But we cannot just drop support for old nodes. It is completely unreasonable to put the _majority_ of the network on a fork, without even as much as a discussion about it. Oh, you didn't get the memo? The rules implemented in your client are outdated. - that is not how Bitcoin works: the network defines the rules. ... Finally, we'll have to schedule a hard fork to drop the 0.8.1 limit. This is something that requires widespread community consensus - far more than just miners and developers The way I've started thinking about it is that there is a market for securing a payment network. In that market you have consumers (users of bitcoin) and providers (miners). It's not clear to me that if the overwhelming majority of miners stayed on 0.8 that the 0.7 fork wouldn't have still won out in the long run because effectively what you would have had is a situation where the providers abandon a large portion of their customers (0.7 users) and start providing a service that is in much less demand. Would everyone have upgraded to 0.8? Maybe, but maybe not. Maybe many people would have made the rational decision to stay on earlier versions and the small minority of miners that choose to service the 0.7 fork could have earned more Bitcoin on that fork...and maybe in the long run, the majority of miners on 0.8 would realize this situation and start to trickle back over to the 0.7 fork. The flip side of the equation is that the users have a pretty compelling reasons to use the services of the most secure network (less risk of double spends). So, the users very well could have made the rational decision to consume the services of the most powerful network and made the switch to 0.8. What happened in reality is that the majority of the mining community made the rational decision to service the largest pool of customers (0.8 as well as 0.7 and earlier users). It was rational because the risk of servicing only the 0.8 users would have been much greater. Because of this dynamic, I doubt there would ever be multiple forks of any consequence in permanent coexistence. I would even go so far as to say that at this point, a successful competitor to Bitcoin would have to arise as a fork of the UTXOs in the block chain (even if the competitor didn't even use a block chain). That competitor might even have to begin life in lock step co-existence with Bitcoin, recognizing all Bitcoin transactions for some period of time while it attempts to gain market share. -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Blocking uneconomical UTXO creation
Instead of thinking in terms of blocking uneconomical transactions (how would a node even determine what's economical?), what about thinking in terms of paying for a feed of economical (i.e. profitable) transactions? There is a market for fee bearing, profitable transactions...if there is no one willing to pay to receive a transaction, then no one will bother propagating it. Such a system would make it possible to determine the probability of confirmation in a given timeframe for a given fee. On Tue, Mar 12, 2013 at 3:49 AM, Peter Todd p...@petertodd.org wrote: On Sat, Mar 09, 2013 at 11:31:55PM -0500, Peter Todd wrote: As discussed endlessly data in the UTXO set is more costly, especially in the long run, than transaction data itself. The fee system is per KB in a block, and thus doesn't properly capture the long-term costs of UTXO creation. There's been a lot of discussion about this issue, and many people have asked that Bitcoin not arbitrarily block interesting potential uses of provably unspendable txouts for data applications, and similarly spendable txouts representing assets. I've changed my hardline position and now think we should support all that stuff. However, there is one remaining class of txout not yet talked about, unspendable but not provably so txouts. For instance we could make the following a standard transaction type: scriptPubKey: OP_HASH160 20 byte digest OP_EQUALVERIFY data scriptSig: data Of course, usually the 20 byte digest would be picked randomly, but it might not be, and thus all validating nodes will always have a copy of the data. With the 10KB limit on script sizes you can fit 9974 bytes of data per transaction output with very little waste. A good application is timestamping, with the advantage over coinbase/merkle tree systems in that you don't have to wait until your timestamp confirms, or even store the timestamp at all. Another application, quite possible with large block sizes and hence cheap or free transactions, is secure data backups. In particular such a service, perhaps called Google Chain Storage, can offer the unique guarantee that you can know you're data is secure by simply performing a successful Bitcoin transaction. -- 'peter'[:-1]@petertodd.org -- Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and remains a good choice in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Stephen Pair, Co-Founder, CTO Does *your* website accept cash? bitpay.com [image: bitpay-small] ABC6 C11B BF75 9E2B FC6A B3E0 7B96 40B2 CAC0 C158 image001.png-- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Incorporating block validation rule modifications into the block chain
On Wed, Feb 13, 2013 at 7:28 PM, Gregory Maxwell gmaxw...@gmail.com wrote: bunch of stuff I understand your arguments, but don't agree with many of your conclusions. The requirement for everyone to hear the history doesn't get talked about much One of the beauties of bitcoin is that the miners have a very strong incentive to distribute as widely and as quickly as possible the blocks they find...they also have a very strong incentive to hear about the blocks that others find. There will not be an issue with blocks being jealously guarded...what miners will want is a good feed of transactions that they want to mine. They will be willing to pay for those feeds (either by sharing the proceeds with highly connected relay nodes or by operating highly connected nodes themselves). Because miners will only want to pay to get a feed of profitable transactions, they will not pay to receive transactions whose miner fee does not cover the relay fee (by which I mean the fee or cost associated with the bandwidth and validation that a transaction requires) with some amount of profit. This means that the relay node will not fetch and propagate those transactions whose fee is too small (unless there was some other fee structure outside the miners fee). These are relatively easy businesses to operate...which means there will be a lot of them and they'll compete on fees (with wallets automatically discovering the cheapest of the services). If the businesses of relaying and mining ever became too centralized, other businesses with a vested interest in the success of bitcoin would take the necessary steps to ensure there remained adequate decentralization. It's important to remember that the centralization that currently exists in the fiat currency world benefits one set of businesses to the detriment of many others. Having a functioning and trustworthy payment system benefits far more people and businesses than a centralized system would. It is good to be wary of these potential issues, but I don't see how the economics are likely to yield the outcome you fear. And, really, there's not a lot that can be done to prevent economics from dictating the ultimate outcome. In fact, what I write above is not so much about what I think *should* be built, it's more about what I *predict* will be built. -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Incorporating block validation rule modifications into the block chain
On Wed, Feb 13, 2013 at 10:38 PM, Gregory Maxwell gmaxw...@gmail.comwrote: On Wed, Feb 13, 2013 at 6:44 PM, Stephen Pair step...@bitpay.com wrote: (by which I mean the fee or cost associated with the bandwidth and validation that a transaction requires) with some amount of profit. This means that the relay node will not fetch and propagate those transactions whose fee is too small (unless there was some other fee structure outside the miners fee). The only fee-or-cost they're worrying about is their own marginal costs. This says nothing about the externalized cost of the hundreds of thousands of other nodes which also must validate the block they produce, many of which are not miners— if we are well distributed— and thus don't have any way to monetize fees. But this is exactly the point I'm making...the thousands of other nodes do have a way to monetize the work they do in relaying and validating transactions. Miners will pay them for the prompt delivery of profitable transactions. So, in effect, the block reward and transactions fees will be paying not only for the mining work, but also the validation and relaying work. Such nodes would get paid in micro transactions from the miners for that service. This would be one way that full nodes could operate profitably (there may be many other indirect ways). I think decentralization is pretty much guaranteed because anyone with profitable transactions would only deliver them to miners or other peers that are willing to pay for them. This is in effect a rebate of a portion of the transaction fee to the network for delivering the transaction to the miner. Wallet software might cut out the middle men and submit directly to miners...other nodes with access to a large amounts of transactions and good infrastructure might be able to reduce the infrastructure a miner has to maintain and deliver a larger volume of fee bearing transactions. And everyone would have a very good sense of the market price for transaction fees for a given level of service (speed of block inclusion). The other side of it is that wallets will need to receive valid, wallet relevant transactions. They may also need to connect with multiple nodes for independent verification of the validity of their transactions. But I think that cost would be more than covered with fees they include in any transactions they originate (but if they rarely originate fee bearing transactions, they might need to pay something to keep receiving an incoming transaction feed...it could be as simple as an artificial transaction they pay to themselves, but that includes a fee). A while back everyone was worried that a tragedy of the commons situation would develop whereby all transactions that carried any fee at all would get included by miners, thus destroying the mining business as the block reward diminished...but I think the cost involved in relaying and validating transactions ensures that situation won't develop...mining nodes will have to only connect to relaying and validating nodes such that they can filter down the volume to something that's profitable for them...and relaying and validating nodes will ignore transactions with fees that are too low to be profitable. It will be a few years before we see the kinds of volumes that will force this infrastructure to evolve...I don't think there is an issue with lifting or even eliminating the block size limit...there may be a point at which the volume is sufficient enough that full nodes start dropping offline...and the nodes that do remain will have to increasingly find ways to cover their costs...which will be a forcing function for solutions similar to these. There is no doubt that Bitcoin will be a lot more valuable if it can handle very large volumes of transactions. Also, Mike Hearn has done some analysis that suggests that even at Visa scales, the hardware requirements to do full validation and relay may not all that substantial (enabling lots of small, but profitable, node operators and low transactions fees...the key to profitability would be access to a sufficient number of original transactions bearing fees). -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts
Here are my (mostly half baked) thoughts on the payments protocol proposal. My first observation is that the proposal is too heavily oriented around a merchant/customer interaction. I think it's equally important to consider the person to person scenarios. It would be very cool if people could send/receive payments by copying and pasting stuff on facebook or email (you can kind of do it now, but it's not safe unless you go to extraordinary lengths using PGP signatures and the like). Protobufs vs JSON: Protobufs are fine, although I will mention that the serialization/JOSE arguments are irrelevant...you only need that if you need a reliable way of signing an in memory object structure...in this case you would be signing a serialized form of the object...the recipient doesn't have to be able to reproduce the serialized form, they only need to verify the signature on the already serialized bytes...I see protobufs as a good serialization format for storage, while JSON being more practical for communications in a web oriented environment...with protobufs a web wallet, you may find yourself in a situation needing to parse a protobuf message in a web browser...the protobuf parsing and serializing code is just going to add bloat to the web page...personally, I probably would have gone with JSON, but hey, I'm not writing the code. X.509 - nasty, but maybe ok ...as long as you can add root CAs to your Bitcoin client or explicitly trust a certificate, I don't see that it poses any privacy issues...but there are some other things to think about here ...like what about the casual user that wants to create a payment request to send to their friend over email (wrapped in a clear text block similar to PGP...it could also be sent as a file attachment)? Are you now requiring them to go and setup a certificate? Btw, I really like the use of a payment request in this manner because you have a signed payment request that can be verified against an address book of known identities. This could be much safer than simply emailing an unsigned bitcoin address around. Refund addresses...this is not going to be as useful as people might think...most refunds that bitpay needs to process happen days or even months after the initial purchase...in that span of time, people can change wallets, rendering such a refund address useless...so, as I think about the situation, we would still need to contact the buyer to confirm a refund address anyway. What we really need is to verify the identity of the person we're potentially sending the refund to...we need a way of determining that the person we're sending the refund to is the same person that paid the original invoice. Bitcoin addresses are identities, but they are too low level. HD wallets come to mind...the top level or intermediate levels of a deterministic hierarchy could be used for identity purposes...but it also seems like it might be conflating payments and identity (which for many reasons you might want to keep separate). What if bitcoin clients could manage one or more identities used for the purpose of communications? You could have a bitcoin identity file that could be used by multiple wallets. These identities would be used for signing messages and verifying the authenticity of communications...when sending a payment, instead of a refund address, you would include one of these identities which could later be used to confirm a refund address. In fact, the refund would be processed by the buyer generating another payment request message signed by the identity used in the original payment. People would understand that their identities are important for communications and they would keep those even when changing to new wallets and such (identities could be stored in ~/.bitcoin/id or something (encrypted of course)). There are some other interesting possibilities if messaging and identities are done right...for example, I could add check feature (analogous to paper checks). It would work like this...you create a transaction that spends to a newly generated address...you put that transaction, along with the private key into an encrypted container (sent to the identity of the person you want to pay). The recipient can open it and their wallet would go ahead and generate and broadcast a transaction moving the funds into their wallet (optionally including a fee). But, if the recipient never cashes the check, the sender could pull those funds back after a certain period of time. This also eliminates the possibility of accidentally sending the funds to the wrong address (or an old address) and the bitcoins being forever lost...the recipient can sweep the transaction into any wallet of their choice. As I'm writing this, I'm beginning to wonder if the identity management problem is unavoidable. Maybe that needs to be dealt with first. It would enable so many other interesting possibilities. I like the use of merchant_data...this means that you no longer will need
Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts
On Thu, Dec 20, 2012 at 12:43 PM, Mike Hearn m...@plan99.net wrote: you may find yourself in a situation needing to parse a protobuf message in a web browser Nothing stops you converting them into whatever form you want on the server side. If you don't care about the signature checking then it's no problem to use a server. If you do then you'd need to ship all the code for verifying signatures that to the client anyway, at which point a small protobuf parser is hardly a deal killer. No, it's not a killer...just a hassle. JSON is convenient and ubiquitous and there is something to be said for that (and I wanted to point out that the JOSE objection was invalid). Protobufs are nice and efficient, but who cares. You're talking about direct communications rather than something that will be bounced around every node in the mesh network. I don't really care much either way, it's not worth debating. I'm just thankful no one is arguing for XML or IIOP. :) ...like what about the casual user that wants to create a payment request to send to their friend over email They can send an unsigned payment request. Note that if you mail it as an attachment from a competent, up to date email provider then the attachment isn't really unsigned. The whole thing is covered by the emails DKIM signature which is applied transparently by the ESP. If the signature fails to verify then the mail client can show that or treat the mail differently (as Gmail does). This is easy to use for the end user - they don't have to think about cryptography or PKI. As long as their email account is secure then they can send signed mails asserting to their identity. This leaves too much to chance for my taste. Forget email, what about jabber, ICQ, skype, IRC? Email is just one communications medium, there are many others for which there would be no assurance that the payment request hasn't been tampered with. You could at a minimum allow a person to create a normal ECC key, but have it used as an identity in communications rather than a payment address. You store it in a separate file in ~/.bitcoin/id ...you don't have to solve the whole set of PKI problems, people could exchange identities using any secure channel they are comfortable with (email + phone verification of a short hash id would be sufficient). In another scenario, an id could be made available over https, using the normal SSL certificate and CA infrastructure to verify authenticity. This way all messages could be signed and/or encrypted without the user having to go out of their way to use external tools or infrastructure that is often not very user friendly. You also need encryption for the cheque feature...asking people to use GPG would be too much of a burden (and email DKIM doesn't offer encryption). wandering off topic Indeed, cheques could become the dominant method of person to person payments...first, you would obtain someone's id, which you might already have on file (rather than obtaining a bitcoin address), then you would generate a cheque for the amount desired and send it to them...the recipient then has full control over what address they want to sweep the funds to as well as whether they'd like to include a miner fee to speed the confirmation along. Despite the fact that you may send many payments to the same identity, the only thing showing up on the p2p network and the block chain is the one time use address for the cheque and the recipient's wallet address. This means the recipient has much more control over the address policy used (compared with simply giving out a bitcoin address that may be reused). Refund addresses...this is not going to be as useful as people might think...most refunds that bitpay needs to process happen days or even months after the initial purchase Useful feedback, thanks. Still, there may be other types of merchants for whom it's useful, and many users won't change their wallet. It certainly simplifies things if you can present the refund address and give a one-click option to use it. If the user wants to use a different address, then they can go onto the slow/complicated path. This current spec deliberately punts on the topic of identifying end users. It's a difficult problem. I know, but as I was responding, I began to realize this is a mistake. It's worthwhile to tackle that problem first...if done right, it would pay huge dividends. Also, identity is one thing, an elaborate trust based identity verification system (like CA's) is a whole other thing. I think the former is pretty simple actually...and it's all that's really needed for the time being (as I alluded, a bitcoin identity could be communicated or verified using the existing X.509/CA infrastructure if desired...you could also use the PGP infrastructure). I like the use of merchant_data...this means that you no longer will need a unique bitcoin address for every invoice. It's still a good idea to use one
Re: [Bitcoin-development] Chain dust mitigation: Demurrage based Chain Vacuuming
On Mon, Dec 3, 2012 at 10:30 AM, Mike Hearn m...@plan99.net wrote: Second thing, it's best to carefully separate anonymity from privacy. Privacy is supposed to be a feature of the system (it says so in Satoshis paper) because people demand it. If I loan a tenner to my friend and he is able to find out what I earned last month, then that trade was neither anonymous nor private. In this case I want privacy but anonymity isn't useful. Mixing up anonymity with privacy is not only a public relations problem, but can lead to confusion from users when they, eg, try and buy Bitcoins from an exchange and are asked to provide ID proofs. I would like to second this point...privacy is essential because the market demands it. If Bitcoin doesn't do it well (and I would argue that it doesn't today), then eventually a competitor to Bitcoin will do it better and that would be the beginning of the end for Bitcoin. Debates about whether it was or wasn't a core feature are pointless. -- Keep yourself connected to Go Parallel: BUILD Helping you discover the best ways to construct your parallel projects. http://goparallel.sourceforge.net___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
