Re: [bitcoin-dev] Bitcoin Core to disable Bloom-based Filtering by default
On 7/23/19 9:47 AM, Andreas Schildbach via bitcoin-dev wrote: > BIP 157/158 is not an alternative to BIP 37: They complement each other pretty well though. Wallets can save the deterministic GCS filters in the same way as headers, which means blocks can be re-scanned if necessary (importing new keys, etc) offline. Bloom filters are good for limiting mempool bandwidth as well as controlling the fraction of each block that is downloaded. On the BTC chain that last point doesn't matter as so much, but on chains with larger blocks I expect that clients will ultimately end up using both filter schemes for exactly that reason. 0x9B2D74E2A30A85B9.asc Description: application/pgp-keys ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Bitcoin Core to disable Bloom-based Filtering by default
On 7/22/19 12:01 AM, Matt Corallo via bitcoin-dev wrote: > Finally, regarding alternatives, the filter-generation code for BIP > 157/158 has been in Bitcoin Core for some time, though the P2P serving > side of things appears to have lost any champions working on it. I > presume one of the Lightning folks will eventually, given they appear to > be requiring their users connect to a handful of their own servers right > now, but if you really need it, its likely not a ton of work to pipe > them through. If you want projects to adopt BIP-157/158, you'd do well to fix the numerous errors in the specification. As it stands right now it is impossible to implement the protocol using the specification because he code examples are broken to the point of appearing intentionally sabotaged. 0x9B2D74E2A30A85B9.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Block size: It's economics & user preparation & moral hazard
On 12/26/2015 06:13 PM, Bryan Bishop wrote: > I think you'll find that there hasn't been stalling regarding an > uncontroversial hard-fork deployment. You might be confusing an > uncontroversial hard-fork decision instead with how developers have > brought up many issues about various (hard-forking) block size > proposals I suspect this is what you're intending to mention > instead, given your mention of "capacity emergencies" and also the > subject line. I think you'll find that writing in that tone makes one come across as a complete and utter douchebag. I suspect what you're intending to do is to use faux-polite condescension to bait me into responding in a way to will justify my subsequent banning from this mailing list so that the people who aren't interested in answering certain uncomfortable questions will have a plausible excuse for preventing them from being asked here. > There wasn't 6 months of "stonewalling" or "denial" about an > uncontroversial hard-fork proposal. There has been extensive discussion > regarding the controversial (flawed?) properties of other (block size) > proposals. But that's something else. Much of this has been rehashed ad > nauseum on this mailing list already... thankfully I think your future > emails could be improved and made more useful if you were to read the > mailing list archives, try to employ more careful reasoning, etc. Thanks. Actually there's been 3+ years of stonewalling, deception, conflicts of interest, and outright crimes, which have been generally ignored by those who are desperately attempting to assume good faith. The purpose of my email was to remind everyone that nobody is going to get away with avoiding ownership of the consequences of their actions. If the network experiences a painful upgrade because six months of time that could have been used to prepare a smooth upgrade was lost, the individuals who squandered that time own the result. They can't get around it by demanding six additional months, as if they had nothing to do with the six lost months. 0xEAD9E623.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Segregated witness softfork with moderate adoption has very small block size effect
On 12/19/2015 10:49 AM, jl2012 via bitcoin-dev wrote: > I am not convinced that SW softfork should be the *only* short term > scalability solution I don't think SW is relevant at all with respect to scalability. Fraud proofs are extremely important from a security perspective. The network as it exists now places too much trust in miners. Creating a way for non-full node clients to reject chains with contain invalid transactions regardless of how much hashing power produces the invalid chains is essential for the security of the network. Adding a fraud proof system into blocks means that other features, like committed UTXO sets, become less unsafe to deploy. Solving transaction malleability is a very nice to have feature. A scalability solution, IMHO, is "how do we buy some time to allow continue usage growth while working on creating a situation where it becomes safe to eliminate maximum block size as a consensus rule?" 0xEAD9E623.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Capacity increases for the Bitcoin system.
On 12/08/2015 09:12 AM, Gavin Andresen via bitcoin-dev wrote: > Stuffing the segwitness merkle tree in the coinbase If such a change is going to be deployed via a soft fork instead of a hard fork, then the coinbase is the worst place to put the segwitness merkle root. Instead, put it in the first output of the generation transaction as an OP_RETURN script. This is a better pattern because coinbase space is limited while output space is not. The next time there's a good reason to tie another merkle tree to a block, that proposal can be designated for the second output of the generation transaction. 0xEAD9E623.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Capacity increases for the Bitcoin system.
On 12/08/2015 11:41 AM, Mark Friedenbach wrote: > A far better place than the generation transaction (which I assume means > coinbase transaction?) is the last transaction in the block. That allows > you to save, on average, half of the hashes in the Merkle tree. I don't care what color that bikeshed is painted. In whatever transaction it is placed, the hash should be on the output side, That way is more future-proof since it does not crowd out other hashes which might be equally valuable to commit someday. 0xEAD9E623.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Compatibility requirements for hard or soft forks
On 02/11/15 14:33, Gavin Andresen via bitcoin-dev wrote: > I like those guidelines, although I'm sure there may be lots of arguing > over what fits under "protects the integrity of the network" or what > constitutes "reasonable notice" (publish a BIP at least 30 days before > rolling out a change? 60 days? a year?) If Bitcoin were perfect. then it would be the case that any transaction that was valid at the time it was signed would always remain valid until spent regardless of any protocol changes which occurred in the interim. Certainly, that property, if it was possible to achieve, would give Bitcoin maximum possible utility compared to alternative properties. There are cases in which that guarantee can be met, and there are some pathological cases where it can not be met. It's not possible to know if the pathological cases are actually a real problem in practice, because the possible existence of unbroadcast transactions which would trigger them is unknowable. A possible lazy/optimistic strategy is to implement as much non-pathological backward compatibility as possible, and treat unhandled cases as outstanding bugs whose resolution is deferred unless and until they are actually triggered. 0xEAD9E623.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Compatibility requirements for hard or soft forks
On 10/30/2015 10:43 PM, Rusty Russell via bitcoin-dev wrote: > By that benchmark, we should aim for "reasonable certainty". A > transaction which would never have been generated by any known software > is the minimum bar. Adding "...which would have to be deliberately > stupid with many redundant OP_CHECKSIG etc" surpasses it. The only extra > safeguard I can think of is clear, widespread notification of the > change. If the policy of Bitcoin Core development includes a willingness to makes the utxos created by software other than Bitcoin Core unspendable, then it certainly merits clear, widespread notification. Even if that is actually a good policy, the reasons why should be made abundantly clear. 0xEAD9E623.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Compatibility requirements for hard or soft forks
On 11/01/2015 07:30 PM, Tier Nolan via bitcoin-dev wrote: > If at least one year's notice was given, then people aren't going to > lose their money, since they have notice. So after realizing that I misread substantial portions of this thread due to a lack of attention to detail I'd like to point out this: Bitcoin nodes have the capability to validate blocks going back to the genesis block, including blocks which would not be valid if mined today under current rules. Therefore it must be the case that all the old consensus rules are preserved somewhere in the current code bases of the various implementations. Given that, there shouldn't be any technical barrier to validating input scripts according to the consensus rules that were in effect at the time the input being spent was added to the blockchain. Maybe dealing with output is more difficult. Had every consensus rule change (deliberate and accidental) been accompanied by a version number bump, it would have been possible to phase out old versions without invaliding signed-but-unbroadcast transactions by saying "as of block height x, transactions with version y or lower are invalid unless their inputs are exclusively sourced from blocks with heights < x" If there already have been rule changes which have retroactively invalided unbroadcast transactions which were valid at the time they were signed, those rules could be relaxed to not apply to transactions which exclusively spend inputs that existed before the rule change. 0xEAD9E623.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] [Bitcoin-development] Reusable payment codes
On 22/10/15 20:22, Peter Todd wrote: > FWIW multi-push OP_RETURN outputs will be standard in v0.12.0: > > https://github.com/bitcoin/bitcoin/pull/6424 > As I said before, once the prerequisites for a better notification method are usable in the network, I'd love to define a version 2 payment code that uses such an better notification system. In the meantime. every block mined shows very consistent 70% address reuse. Anything that can bring that number down is a good thing. Even if version 1 payment codes could only potentially drop that number from 70% to 30% instead of to 0%, they'd still be worth using while we wait for version 2. 0xEAD9E623.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] [Bitcoin-development] Reusable payment codes
On 22/10/15 15:43, Luke Dashjr wrote: > BIPs should in general not be > designed around current software I strongly disagree with this statement. There is a version byte in the payment code specification for a reason. Version 1 payment codes are designed to be deployable by wallet implementers today, without requiring them to wait on any network-level changes whatsoever, which includes IsStandard() redefinitions, or yet-to-be-invented-and-deployed filtering schemes. As far as I know, multi-push OP_RETURN outputs are not standard transactions and so wallet users can not rely on transactions containing them to be relayed through the network, therefore any improvement to the protocol which requires that feature is not appropriate for version 1. When additional capabilities are deployed in the network such that Bitcoin users can rely on their existence, that would be a great time to specify a version 2 payment code that uses those features and encourage users to upgrade (which should be a fairly smooth process since their actual keys don't need to change). 0xEAD9E623.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] [Bitcoin-development] Reusable payment codes
On 22/10/15 00:53, Luke Dashjr wrote: > Sorry for the late review. I'm concerned with the "notification address" > requirement, which entails address reuse and blockchain spam. Since it > entails > address reuse, the recipient is forced to either leave them unspent forever > (bloating the UTXO set), or spend it which potentially compromises the > private > key, and (combined with the payment code) possibly as much as the entire > wallet. > > Instead, I suggest making it a single zero-value OP_RETURN output with two > pushes: 1) a hash of the recipient's payment code, and 2) the encrypted > payment code. This can be searched with standard bloom filters, or indexed > with whatever other optimised algorithms are desired. At the same time, it > never uses any space in the UTXO set, and never needs to be > spent/mixed/dusted. The notification transaction portion is my least-favorite portion of the spec, but I don't see any alternatives that provide an unambiguous improvement, including your suggestion. One of the most highly-weighted goals of this proposal is to be usable on as many mobile/light wallets as possible. I know for sure that all existing platforms for balance querying index by address. Support for bloom filters or other querying methods is less comprehensive, meaning the set of wallets that can support payment codes would be smaller. 0xEAD9E623.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Proposed list moderation policy and conduct
On 14/10/15 19:02, Jeff Garzik via bitcoin-dev wrote: > *Disclose potential conflicts* > > 1. List discussions often involve interested parties. We expect > participants to be aware when they are conflicted due to employment or > other projects they are involved in, and disclose those interests to other > project members. > 2. When in doubt, over-disclose. Perceived conflicts of interest are > important to address, so that the lists’ decisions are credible even when > unpopular, difficult or favorable to the interests of one group over > another. Even if we assume everybody will try to approach that topic in good faith, I don't think it's that simple. A term that's become popular recently is "Bitcoin maximalist", and it's frequently used as a slur or insult. I honestly find that to be incomprehensible. If somebody at a Ford board meeting started talking about how Ford needed to make sure Toyota was able to sell enough cars, they wouldn't get very far by labelling their critics as "Ford maximalists". Anyone who works at Ford and who isn't a Ford maximalist is in the wrong job. And yet in Bitcoin, a much development is funded by companies who offer products which compete with Bitcoin, or at least would be in competition if Bitcoin were to achieve unlimited success. I expect this is a minority view on this list, but my position is that anyone who is not a Bitcoin maximalists has a potential conflict of interest if they're also involved in Bitcoin development. I also suspect this issue is a cause of much user dissatisfaction with Bitcoin development. If Bitcoin users and investors don't trust that the developers are working toward the unlimited success case, they can and will revolt. 0xEAD9E623.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] RFC: HD Bitmessage address derivation based on BIP-43
On 09/03/2015 07:06 PM, Luke Dashjr via bitcoin-dev wrote: > Since BIP 43 is still a draft, I propose modifying it to refer non- > Bitcoin purpose codes to the SLIP repository: > https://doc.satoshilabs.com/slips/ What benefit is created by delegating the BIP-43 namespace management to that company in particular? BIP-43 as it is currently composed provides the convenient feature of purpose codes matching the BIP number. Moving purpose codes to a separate namespace add complexity to its usage for no discernible benefit. -- Justus Ranvier Open Bitcoin Privacy Project http://www.openbitcoinprivacyproject.org/ jus...@openbitcoinprivacyproject.org E7AD 8215 8497 3673 6D9E 61C4 2A5F DA70 EAD9 E623 0xEAD9E623.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Your Gmaxwell exchange
On 09/01/2015 03:29 PM, Wladimir J. van der Laan wrote: > On Mon, Aug 31, 2015 at 01:55:43PM -0500, Justus Ranvier via bitcoin-dev > wrote: > >> * They should own their bitcoins, meaning that they retain exclusive >> control over their balances. Even more precisely, the network must >> always honour the conditions of the scripts associated with unspent outputs. >> >> * Their fraction of the Bitcoin ledger must not be diluted. >> >> * When they decide to spend their coins, they will be able to do so >> without requiring permission from a third party. > > All of these properties are contingent on the system being decentralized. That is not true, unless you are using a definition of the word "decentralized" which is so broad as to convey no information whatsoever. Saying that Bitcoin's security depends on decentralization is like saying that a bridge's structural integrity depends on good materials. Statements like that convey zero relevant information. Potential users of a bridge want to know about the maximum working load of the bridge, and under which conditions it is safe to use. At what wind speed should the bridge be closed? Is it ok to keep using it after a magnitude 4 earthquake, or should it be closed for inspection? Repeatedly asserting that bridges need to be made of good materials as an alternative to answering those kinds of questions would be easily recognized as useless in that context, but for some reason people seem to accept it in this one. -- Justus Ranvier Open Bitcoin Privacy Project http://www.openbitcoinprivacyproject.org/ jus...@openbitcoinprivacyproject.org E7AD 8215 8497 3673 6D9E 61C4 2A5F DA70 EAD9 E623 0xEAD9E623.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Your Gmaxwell exchange
On 08/30/2015 01:38 AM, Adam Ritter via bitcoin-dev wrote: > Still, it doesn't have anything that is practical for me as an user of > the Bitcoin network (I use it for storing long-term purchase value, as > most of the people who I know): it doesn't help me if I still need to > pay transaction fees after the blocksize limit is gone. My (and other > users') main concern is about centralization, which has nothing to do > with transaction fees. I would be OK with $100 transaction fee as > well, as long as the network is fair and secure (which comes from > decentralization). I don't believe that any Bitcoin user actually cares about decentralization, because none of them I've asked can define that term. "decentralization" has become a placeholder word for "features or ideas that I like" and it's long past time to drag the discussion back into the realm of concrete and achievable goals. I think there are a few specific things we can surmise about what users might mean when they say they want Bitcoin to be "decentralized": * They should own their bitcoins, meaning that they retain exclusive control over their balances. Even more precisely, the network must always honour the conditions of the scripts associated with unspent outputs. * Their fraction of the Bitcoin ledger must not be diluted. * When they decide to spend their coins, they will be able to do so without requiring permission from a third party. A decentralized architecture in certain parts of the network can be helpful for achieving those goals, but it is not always necessary, nor is it always sufficient to achieve them. -- Justus Ranvier Open Bitcoin Privacy Project http://www.openbitcoinprivacyproject.org/ jus...@openbitcoinprivacyproject.org E7AD 8215 8497 3673 6D9E 61C4 2A5F DA70 EAD9 E623 0xEAD9E623.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Your Gmaxwell exchange
On 08/31/2015 04:42 PM, Monarch wrote: > The justification for the existence of Bitcoins hinges on it. What is > described in the whitepaper is a system without the trust of third > parties to process electronic payments, this can not exist without > decentralization. Absent any unforseen revelations this is a > requirement rather than a suggestion or fleeting fancy. Below a > decentralized Bitcoin you are free to make systems as centralized as > you please without affecting the parent, below a centralized Bitcoin > there is no room to make it less. We really only have one shot at a > properly bootstrapped, decentralized currency, and it would be a great > shame to mess up the one we have with hasty decision making for > unclear goals. You keep using the word "decentralized" without explaining (and most likely, understanding) what it means. You say: > a system without the trust of third parties to process electronic payments What does it mean to use a decentralized network instead of a trusted third party to process electronic payments? What undesirable actions can a trusted third party perform that a decentralized network can not perform? The answer to those questions are the *actual* goals, for which decentralization is just one portion of a solution. It might be helpful to organize Bitcoin's various existing, potential, rejected, and proposed features using the Kano model: https://en.wikipedia.org/wiki/Kano_model Example: The ability of one entity to spend another entity's Bitcoins without their consent is a reverse quality. It would at least give us something objective to talk about. -- Justus Ranvier Open Bitcoin Privacy Project http://www.openbitcoinprivacyproject.org/ jus...@openbitcoinprivacyproject.org E7AD 8215 8497 3673 6D9E 61C4 2A5F DA70 EAD9 E623 0xEAD9E623.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Your Gmaxwell exchange
On 08/31/2015 05:53 PM, Monarch wrote: > > Bitcoin is a decentralized currency which allows any person the > ability to transact in a way that does not require specific trust in > any particular party. Users can independently verify that > transactions they receive are valid and confirmed, with strong > confidence that they can not be reversed or modified. A third party > does not hold these same properties, there is no reason to believe the > information they present other than trust they will not lie, cheat, or > violate privacy at their own will. Given information by a trusted > third party (such as a balance or existance of transaction), a person > has no ability to independently validate their claims as you do in a > decentralized system. This is on the right track, but still falls short in a few areas. It's a false dichotomy to say that our choices are: Bitcoin as it exists today (or in some theoretical perfect state of decentralization), or an Excel spreadsheet edited by a trusted third party who can change any number to be any other number they want. Imagine there was only one miner in the network. In spite of being the sole entity creating the blockchain there would still be many actions they could *not* do: * Falsify ECDSA signatures * Generate proof of work without expending energy * Produce blocks that non-mining nodes would recognize as including invalid transactions (including printing themselves unlimited balances) * Force other people to purchase the coins they mine so that they can pay their electric bills What they *can* do is: * Defraud recipients of transactions by including a payment transaction in a block, then orphaning that block with another block that contains a conflicting transaction (double spend). There is usually*** a cost to performing this attack, so miners would only be expected to do it if the benefit exceeds the cost. * Prevent the inclusion of valid transactions into any block using any criteria they want. The worse case scenario for mining monopolization is that the risk of profitable double spends means that transactions might require more confirmations to be reliable, and that some entity can censor transactions at will. Those aren't exactly end-of-the world failure cases. They are certainly undesirable and every means of preventing them should be investigated, but it does mean that it should be possible to dial back on the catastrophe language when analysing possible failure modes. The weakest area for Bitcoin to be attacked is via censorship enforced by miners. The first line of defence is to improve the privacy features of wallets to the point at which blacklists are not effective. I'm confident that this can be achieved. That leaves the censors with the choice of whether or not to escalate to whitelisting, which ultimately can be countered by users switching to a new system which does not have that particular anti-feature. tl;dr: Bitcoin security does not lie on a one-dimensional "centralized vs decentralized" axis. Treating it as if it does removes the clarity that is needed in order to effectively solve problems. ***Exploring the exact conditions under which this is true is an interesting exercise and relevant to long term discussions vis a vis the block subsidy and transaction fees in the future. -- Justus Ranvier Open Bitcoin Privacy Project http://www.openbitcoinprivacyproject.org/ jus...@openbitcoinprivacyproject.org E7AD 8215 8497 3673 6D9E 61C4 2A5F DA70 EAD9 E623 0xEAD9E623.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Why not Child-Pays-For-Parent?
On 07/10/2015 11:31 AM, Jeff Garzik wrote: This is a good explanation but it does not address reachability. TX_a, the first tx sent out on the network, presumably has insufficient fee to get mined - which also means it did not necessarily even reach all miners. Simply sending out TX_b with added fee does not guarantee that nodes suddenly have TX_a, which they may have ignored/dropped before. I'm not sure why that's actually a problem. CPFP is initiated by the recipient of the parent transaction, and so if the recipient is creating this transaction in the first place they must have a copy of the parent transaction which can/should broadcast at the same time. If the child reaches a CPFP miner, then presumably the parents made it as well (any path between the sender and the miner that doesn't relay the parent should reject the child as trying to spend non-existent coins), so both of the transactions can be mined at the same time. -- Justus Ranvier Open Bitcoin Privacy Project http://www.openbitcoinprivacyproject.org/ jus...@openbitcoinprivacyproject.org E7AD 8215 8497 3673 6D9E 61C4 2A5F DA70 EAD9 E623 0xEAD9E623.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Fork of invalid blocks due to BIP66 violations
On 07/04/2015 10:35 AM, Tier Nolan wrote: Even that can be handled with UTXO set commitments. If the UTXO tree is sorted you can prove that an entry doesn't exist. How do we know if a committed UTXO set is valid? If a majority of the hashing power is willing to extend an invalid branch, it's reasonable to assume they'd be willing to commit an invalid UTXO set as well. In order for the committed UTXO set to be reliable at a minimum it will need to contain at a source block reference for each item in the set. That would enable fraud proof to show that the committed UTXO set contains invalid entries. If each transaction input identified the block containing the referenced outpoint, then the proof of non-existence is either the block in question, or the list of block headers (to show that the block doesn't exist). That's a significant improvement in proof size over the entire blockchain. That is reasonable. Unconfirmed transactions can't include that info though. It could be committed in as an extra commitment. I agree the information should be an extra commitment produced by the miner, rather than changing the format of the transaction, since the author of a transaction can't always know the required information ahead of time. One issue is that you need to prove of of these commitments too. If items in the the proof tree are required to be sorted, then it's easy to proof that an item is missing. -- Justus Ranvier Open Bitcoin Privacy Project http://www.openbitcoinprivacyproject.org/ jus...@openbitcoinprivacyproject.org E7AD 8215 8497 3673 6D9E 61C4 2A5F DA70 EAD9 E623 0xEAD9E623.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Fork of invalid blocks due to BIP66 violations
On 07/04/2015 12:58 PM, Tier Nolan wrote: Yes, you can mostly get short proofs for each step, but you have to make sure your proofs are also provable. It means going through everything that needs to be proved for a block to be valid. I think the problem is tractable if some reasonable assumptions are made about the ability of SPV clients to perform validity checks that don't involve any state outside a single transaction (or block): https://gist.github.com/justusranvier/451616fa4697b5f25f60 -- Justus Ranvier Open Bitcoin Privacy Project http://www.openbitcoinprivacyproject.org/ jus...@openbitcoinprivacyproject.org E7AD 8215 8497 3673 6D9E 61C4 2A5F DA70 EAD9 E623 0xEAD9E623.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] RFC: HD Bitmessage address derivation based on BIP-43
The primary purpose is to allow Bitmessage users to benefit from eternal key backups by generating their addresses from a seed. In addition, they can use the same seed for a Bitcoin wallet and a Bitmessage client. This method also enables future use cases where senders calculate Bitmessage addresses based on a recipient's extended public key and some other index value. On Wed, Jul 1, 2015 at 12:07 PM, Kristov Atlas kristovatlas.li...@gmail.com wrote: Hi Justus, What are the potential applications for this BIP? -Kr On Jun 30, 2015 1:53 PM, Justus Ranvier justus.ranv...@monetas.net wrote: Monetas has developed a Bitmessage address derivation method from an HD seed based on BIP-43. https://github.com/monetas/bips/blob/bitmessage/bip-bm01.mediawiki We're proposing this as a BIP per the BIP-43 recommendation in order to reserve a purpose code. ___ 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] Bitcoin governance
On 07/01/2015 03:54 AM, Jeffrey Paul wrote: could we please limit ourselves to posting about the research and development of Bitcoin Core? If that's the purpose of this list, then it is misleadingly named. If development of Bitcoin Core, the application, is to be considered independent from development of Bitcoin, the protocol, then Bitcoin Core development needs its own list. 0xEAD9E623.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] block-size tradeoffs hypothetical alternatives (Re: Block size increase oppositionists: please clearly define what you need done to increase block size to a static 8MB, and help do
On 06/30/2015 02:54 PM, Adam Back wrote: Decentralisation is key to Bitcoin's security model, and it's differentiating properties. Continually repeating this statement without defining terms or providing evidence does not make it true or informative. Decentralization is a popular buzzword these days, but how about stating the problem description in a way that is more precise and accurate? One of Bitcoin's differentiating properties is that it prevents double spending without using a trusted third party. Now instead of arguing about some nebulous decentralization that nobody can define or measure, we can talk about more helpful questions like: Under what circumstances will miners and/or nodes behave as a trusted third party (collusion)? What incentives exist which increase, and which reduce, any tendencies that may exist for nodes to collude? In what ways specifically does MAX_BLOCK_SIZE relate to either of the following questions? 0xEAD9E623.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
