Re: [bitcoin-dev] Claiming an OP_RETURN Prefix
On Thursday 16 August 2018 02:22:21 Lautaro Dragan wrote: > > Choosing not to mine transactions is not censorship. > > Is it not, if for political rather than economical reasons? These > transactions pay fees like any other. Miners have always chosen transaction on "political" basises, and doing such is their right. That's why the system is supposed to be comprised of many miners, all with their own policies - so the choices of one do not impact the overall ability to spend (presumably only spam should be rejected by all miners). For fees to themselves justify the cost of a transaction, they would need to be magnitudes higher than we've ever seen on Bitcoin. But even then, nobody has an obligation to accept payment, no matter how reasonable it is, for a service they don't want to provide. Luke ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Claiming an OP_RETURN Prefix
On Wednesday 15 August 2018 21:54:50 Christopher Allen via bitcoin-dev wrote: > On Wed, Aug 15, 2018 at 2:24 PM Jude Nelson via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > > Can a miner identify which transactions came from your software simply by > > running a copy themselves? If so, then they can censor your transactions > > no matter how you encode them. > > Possibly, but in the IPFS case I suspect the latency required to inspect > all hashes would likely impact the ability of the miner to succeed in the > block. (True? I don’t touch mining software.) Not true at all. > Thus as long as all hashes look the same, and there are multiple content > addressable schemes that use hashes that have to be searched in order to > know to censor, you have to censor all or none. Choosing not to mine transactions is not censorship. Luke ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Claiming an OP_RETURN Prefix
On Wed, Aug 15, 2018 at 2:24 PM Jude Nelson via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Can a miner identify which transactions came from your software simply by > running a copy themselves? If so, then they can censor your transactions > no matter how you encode them. > Possibly, but in the IPFS case I suspect the latency required to inspect all hashes would likely impact the ability of the miner to succeed in the block. (True? I don’t touch mining software.) Thus as long as all hashes look the same, and there are multiple content addressable schemes that use hashes that have to be searched in order to know to censor, you have to censor all or none. — Christopher Allen > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Claiming an OP_RETURN Prefix
On August 15, 2018 8:33:43 PM UTC, "Jorge Timón via bitcoin-dev" wrote: >op_return outputs can be pruned because they are not spendable. >putting a hash on in the witness script data won't make things better >(it would actually make them worse) and it definitely doesn't help >"block size bloat". >I think I'm missing some context, but if you're using op_return purely >for timestamping I would recommend using pay 2 contract instead. If you're *actually* just doing timestamping you're better off using OpenTimestamps. But many times people think they're just doing timestamping in reality mere timestamps are insufficient for the task. Notably, this is something the Satoshi Bitcoin white paper gets wrong, incorrectly describing Bitcoin as a timestamping system: timestamping is insufficient to prevent double-spends. -- https://petertodd.org 'peter'[:-1]@petertodd.org ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Claiming an OP_RETURN Prefix
> I recommend against using an op_return prefix, > as they allow for transaction censorship. > In fact, in our case, where we use an IPFS hash in > an op_return, we remove the IPFS multihash prefix > information to post a “bare” SHA256 hash to look like > many other hashes being posted in op_returns, to > minimize any ability for a miner to identify our transaction. > The more projects that do this the better — a form of herd > immunity. Can a miner identify which transactions came from your software simply by running a copy themselves? If so, then they can censor your transactions no matter how you encode them. On Wed, Aug 15, 2018 at 8:34 PM Jorge Timón via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > op_return outputs can be pruned because they are not spendable. > putting a hash on in the witness script data won't make things better > (it would actually make them worse) and it definitely doesn't help > "block size bloat". > I think I'm missing some context, but if you're using op_return purely > for timestamping I would recommend using pay 2 contract instead. > > On Tue, Aug 14, 2018 at 8:34 PM, Christopher Allen via bitcoin-dev > wrote: > > On August 5, 2018 9:11:26 PM UTC, Lautaro Dragan via bitcoin-dev > > wrote: > >>Should we actually be using the BIP process to claim a prefix? > > > > I recommend against using an op_return prefix, as they allow for > transaction > > censorship. > > > > In fact, in our case, where we use an IPFS hash in an op_return, we > remove > > the IPFS multihash prefix information to post a “bare” SHA256 hash to > look > > like many other hashes being posted in op_returns, to minimize any > ability > > for a miner to identify our transaction. The more projects that do this > the > > better — a form of herd immunity. > > > > Longer term I’m looking for more responsible ways to publish this hash, > for > > instance have the hash be in the witness script data, so that it can be > > easily purged from nodes that do not wish to preserve it and prevent > block > > size bloat. However, to do so everyone has to do it the same way, ideally > > have it look like any other transaction. I’ve not quite seen a solid > > proposal for best practices here. > > > > — Christopher Allen > > > > ___ > > bitcoin-dev mailing list > > bitcoin-dev@lists.linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > > ___ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Claiming an OP_RETURN Prefix
op_return outputs can be pruned because they are not spendable. putting a hash on in the witness script data won't make things better (it would actually make them worse) and it definitely doesn't help "block size bloat". I think I'm missing some context, but if you're using op_return purely for timestamping I would recommend using pay 2 contract instead. On Tue, Aug 14, 2018 at 8:34 PM, Christopher Allen via bitcoin-dev wrote: > On August 5, 2018 9:11:26 PM UTC, Lautaro Dragan via bitcoin-dev > wrote: >>Should we actually be using the BIP process to claim a prefix? > > I recommend against using an op_return prefix, as they allow for transaction > censorship. > > In fact, in our case, where we use an IPFS hash in an op_return, we remove > the IPFS multihash prefix information to post a “bare” SHA256 hash to look > like many other hashes being posted in op_returns, to minimize any ability > for a miner to identify our transaction. The more projects that do this the > better — a form of herd immunity. > > Longer term I’m looking for more responsible ways to publish this hash, for > instance have the hash be in the witness script data, so that it can be > easily purged from nodes that do not wish to preserve it and prevent block > size bloat. However, to do so everyone has to do it the same way, ideally > have it look like any other transaction. I’ve not quite seen a solid > proposal for best practices here. > > — Christopher Allen > > ___ > 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] Claiming an OP_RETURN Prefix
On August 5, 2018 9:11:26 PM UTC, Lautaro Dragan via bitcoin-dev wrote: >Should we actually be using the BIP process to claim a prefix? I recommend against using an op_return prefix, as they allow for transaction censorship. In fact, in our case, where we use an IPFS hash in an op_return, we remove the IPFS multihash prefix information to post a “bare” SHA256 hash to look like many other hashes being posted in op_returns, to minimize any ability for a miner to identify our transaction. The more projects that do this the better — a form of herd immunity. Longer term I’m looking for more responsible ways to publish this hash, for instance have the hash be in the witness script data, so that it can be easily purged from nodes that do not wish to preserve it and prevent block size bloat. However, to do so everyone has to do it the same way, ideally have it look like any other transaction. I’ve not quite seen a solid proposal for best practices here. — Christopher Allen ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] Fwd: Simple change to the "merkleblock" command to protect from SPV proof extension attacks
Hi, While fixing RSK's SPV bridge I came up with an idea to fix the MERKLEBLOCK command to prevent rogue peers from attacking SPV peers using Bitcoin's Merkle tree structure flaws. The most annoying attack is the one that tries to confuse a victim peer into thinking a transaction is an inner node, extending such node with a new right-sided branch with a fake transaction (*) . The old idea to soft-fork Bitcoin to make invalid 64-byte transactions is attractive, but also a coordination problem that could be avoided with this new proposal. The idea is simple, and it's not a fork, but a network protocol improvement. Let A be the hash digest that must be combined with the hash digest B, such that the upper node hash is SHA256(SHA256(A | B)). Therefore A = SHA256(SHA256(X)) and B = SHA256(SHA256(Y)), and X and Y are either Bitcoin transactions or other inner nodes. Instead of storing A, the merkleblock structure should store a pre-image of A, or SHA256(X). If the block only has the coinbase, nothing is done. The pre-image change could be done to both left and right hashes, but it's enough to do it to all left-side hashes that do not have children in the partial merkle tree structure (let's call them terminal hahes. to avoid confusion with leaf hashes). Verifiers (SPV nodes) would apply a single SHA256() operation to the left-sided terminal hashes before combining them. The cost to the verifier is in the worse case only 33% more. This basically limits the attacker's ability to supply chosen-hash digests in order to build a transaction. Because the left side contains most of the previn hash, the attacker would need to bruteforce a huge space (about 208 bits) in order to come up with a pre-image that maps to a owned previn. Meet-in-the-middle attacks would be expensive as UTXOs are not free. To implement this change, a new command MERKLEBLOCK2 could be implemented or the protocol version could be used to differentiate between the two modes of the MERKLEBLOCK command. If the idea gets community support, I may write the BIP/code or invite anyone to do it. regards (*) https://bitslog.wordpress.com/2018/06/09/leaf-node-weakness-in-bitcoin-merkle-tree-design/ ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
