Re: [bitcoin-dev] Alternative chain support for payment protocol
I'm cautious of using human-meaningful identifiers, especially any that might require a central repository, due to name collisions. Examples that could be complicated include BitcoinDark, Litedoge, and other names that base on existing coins. I think the ability to differentiate between test networks is also useful. Could certainly just use the genesis hash as network ID, that would work. Bit long, but suspect 64 bytes isn't the end of the world! I'll see if any more responses come in then raise a BIP for using genesis hash as an alternative to short names. Ross On 09/08/2015 15:29, Mike Hearn wrote: I'd appreciate initial feedback on the idea, and if there's no major objections I'll raise this as a BIP. The reason BIP 70 doesn't do this is the assumption that alt coins are ... well alt. They can vary in arbitrary ways from Bitcoin, and so things in BIP70 that work for Bitcoin may or may not work for other coins. If your alt coin is close enough to BIP 70 that you can reuse it as is then IMO we should just define a new network string for your alt. network = dogecoin-main or whatever. You could also use the genesis hash as the network name. That works too. But it's less clear and would involve lookups to figure out what the request is for, if you find such a request in the wild. I don't care much either way. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] Alternative chain support for payment protocol
BIP 70 currently lists two networks, main and test (inferred as testnet3) for payment protocol requests. This means that different testnets cannot be supported trivially, and the protocol cannot be used for alternative coins (or, lacks context to indicate which coin the request applies to, which is particularly dangerous in cases where coins share address prefixes). I propose adding a new optional genesis field as a 16 byte sequence containing the SHA-256 hash of the genesis block of the network the request belongs to, uniquely identifying chains without any requirement for a central registry. For backwards compatibility, the network field would contain main for Bitcoin main net, test for Bitcoin testnet3, and other for other networks apart from those two. I'd appreciate initial feedback on the idea, and if there's no major objections I'll raise this as a BIP. Ross ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] For discussion: limit transaction size to mitigate CVE-2013-2292
I take it there's no feasibility in suggesting the script execution code has run time maximums? I'm aware these would be much harder to have consensus on, but would seem like the better solution if at all possible. Ross On 20/07/2015 20:10, Gavin Andresen via bitcoin-dev wrote: Draft BIP to prevent a potential CPU exhaustion attack if a significantly larger maximum blocksize is adopted: Title: Limit maximum transaction size Author: Gavin Andresen gavinandre...@gmail.com mailto:gavinandre...@gmail.com Status: Draft Type: Standards Track Created: 2015-07-17 ==Abstract== Mitigate a potential CPU exhaustion denial-of-service attack by limiting the maximum size of a transaction included in a block. ==Motivation== Sergio Demian Lerner reported that a maliciously constructed block could take several minutes to validate, due to the way signature hashes are computed for OP_CHECKSIG/OP_CHECKMULTISIG ([[https://bitcointalk.org/?topic=140078|CVE-2013-2292]] https://bitcointalk.org/?topic=140078%7CCVE-2013-2292]]). Each signature validation can require hashing most of the transaction's bytes, resulting in O(s*b) scaling (where n is the number of signature operations and m is the number of bytes in the transaction, excluding signatures). If there are no limits on n or m the result is O(n^2) scaling. This potential attack was mitigated by changing the default relay and mining policies so transactions larger than 100,000 bytes were not relayed across the network or included in blocks. However, a miner not following the default policy could choose to include a transaction that filled the entire one-megaybte block and took a long time to validate. ==Specification== After deployment, the maximum serialized size of a transaction allowed in a block shall be 100,000 bytes. ==Compatibility== This change should be compatible with existing transaction-creation software, because transactions larger than 100,000 bytes have been considered non-standard (they are not relayed or mined by default) for years. Software that assembles transactions into blocks and that validates blocks must be updated to reject oversize transactions. ==Deployment== This change will be deployed with BIP 100 or BIP 101. ==Discussion== Alternatives to this BIP: 1. A new consensus rule that limits the number of signature operations in a single transaction instead of limiting size. This might be more compatible with future opcodes that require larger-than-100,000-byte transactions, although any such future opcodes would likely require changes to the Script validation rules anyway (e.g. the 520-byte limit on data items). 2. Fix the SIG opcodes so they don't re-hash variations of the transaction's data. This is the most correct solution, but would require updating every piece of transaction-creating and transaction-validating software to change how they compute the signature hash. ==References== [[https://bitcointalk.org/?topic=140078|CVE-2013-2292] https://bitcointalk.org/?topic=140078%7CCVE-2013-2292]]: Sergio Demian Lerner's original report ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP 102 - kick the can down the road to 2MB
I'd back this if we can't find a permanent solution - 2MB gives us a lot more wiggle room in the interim at least; one of my concerns with block size is 3 transactions per second is absolutely tiny, and we need space for the network to search for an equilibrium between volume and pricing without risk of an adoption spike rendering it essentially unusable. I'd favour switching over by block height rather than time, and I'd suggest that given virtually every wallet/node out there will require testing (even if many do not currently enforce a limit and therefore do not need changing), 6 months should be considered a minimum target. I'd open with a suggestion of block 390k as a target. Ross On 17/07/2015 16:55, Jeff Garzik via bitcoin-dev wrote: Opening a mailing list thread on this BIP: BIP PR: https://github.com/bitcoin/bips/pull/173 Code PR: https://github.com/bitcoin/bitcoin/pull/6451 The general intent of this BIP is as a minimum viable alternative plan to my preferred proposal (BIP 100). If agreement is not reached on a more comprehensive solution, then this solution is at least available and a known quantity. A good backup plan. Benefits: conservative increase. proves network can upgrade. permits some added growth, while the community market gathers data on how an increased block size impacts privacy, security, centralization, transaction throughput and other metrics. 2MB seems to be a Least Common Denominator on an increase. Costs: requires a hard fork. requires another hard fork down the road. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
