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 s
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?
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.
>
Po
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 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_retur
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 tim
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 rem
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,
