Topic: Bitcoin XT - Officially #REKT (also goes for BIP101 fraud) - page 20. (Read 378991 times)

Coinbase is now running BitcoinXT (BIP101) in production as an experiment, blog post w more details coming soon

Duly noted.

Last night I dreamt I was loading the washing machine.  I stepped out for a minute and when I returned Greg Maxwell had stuffed three knit blankets into the same machine, overloading it.  I called out to him, but he did not respond.  I never saw him, but sometimes in dreams you know things.

This is 100% true.

Overloading blocks?  Commit access to my washing machine?  I don't know what it means, but investors should take note.

... ignored.

you know I had you with benefit of the doubt for the longest time, on the odd occasion you say something vaguely interesting but generally keep a low level of snark, just below the level of ignore radar ... too bad for you that you stuck your head up today ... ignored.

A mechanism that forces transactions to carry an attractive fee is good for the network as creates a fee market to the benefit of the miners, which will increase network security. It is important that bitcoin have this fee market as eventually fees will be all that there is to incentivize miners to secure the network (and therefore it is good to cultivate the market early).

--No, it is not. Increasing fees right now REDUCES adoption by pricing out the very market you want to attract. Mining will ALWAYS be competitive. It might SEEM like it increases security, but in reality, increased fees=reduced transaction count, which reduces the demand for mining, because people will use the network less, or for who who would have been new, not even try it at all. We miners have enough incentive. Don't buy into the 'I need to ROI before everyone else' hype.

Do I know what a payment channel is? DO I KNOW WHAT A PAYMENT CHANNEL IS?!?

...

.... do you even know what a payment channel is?

I'm very upset with you people. Are we sticking all the unbanked in payment channel??

god damit forkers, seems you figured it all out, bravo!

I think we should all need to take a few minutes and read latest Peter Todd's email (on btc dev mailing list):

"Segregated witnesses and validationless mining"
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/012103.html

separates transaction information

segregated witnesses makes validationless mining
easier and more profitable than the status quo

easily fixed by changing the protocol

Of course, when this goes wrong it goes very wrong, greatly amplifying
the effect of 51% attacks and technical screwups

We can fully expect miners to take advantage of
this to reduce latency and thus improve their profitability.

At best the codepaths that actually do validation will be rarely,
if ever, tested in production.

Mining could continue indefinitely on an invalid chain, producing blocks
that in isolation appear totally normal and contain apparently valid
transactions.

# Easy [] solution: previous witness data proof

To return segregated witnesses to the status quo, we need to at least
make having the previous block's witness data be a precondition to
creating a block with transactions; ideally we would make it a
precondition to making any valid block, although going this far may
receive pushback from miners who are currently using validationless
mining techniques.

We can require blocks to include the previous witness data, hashed with
a different hash function that the commitment in the previous block.
With witness data W, and H(W) the witness commitment in the previous
block, require the current block to include H'(W)

A possible concrete implementation would be to compute the hash of the
current block's coinbase txouts (unique per miner for obvious reasons!)
as well as the previous block hash. Then recompute the previous block's
witness data merkle tree (and optionally, transaction data merkle tree)
with that hash prepended to the serialized data for each witness.

This calculation can only be done by a trusted entity with access to all
witness data [ ] from the previous block, forcing miners to both publish
their witness data promptly, as well as at least obtain witness data
from other miners. (if not actually validate it!) This returns us to at
least the status quo, if not slightly better.

This solution is a soft-fork [yea we all know by now hardforks are failures, so lets be more practical and sneaky in debasing satoshi's codebase] . As the calculation is only done once per
block, it is *not* a change to the PoW algorithm and is thus compatible
with existing miner/hasher setups. (modulo validationless mining
optimizations, which are no longer possible)

# Proofs of non-inflation vs. proofs of non-theft

Currently [yep that's right.. c u r r e n t l y] full nodes can easily verify both that inflation of the
currency has no occured, as well as verify that theft of coins through
invalid scriptSigs has not occured. (though as an optimisation currently
scriptSig's prior to checkpoints are not validated by default in Bitcoin
Core)

It has been proposed that with segregated witnesses old witness data
will be discarded entirely. This makes it impossible to know if miner
theft has occured in the past[]; as a practical matter due to the
significant amount of lost coins this also makes it possible to inflate
the currency.

How to fix this problem is an open question; it may be sufficient have
the previous witness data proof solution above require proving posession
of not just the n-1 block, but a (random?) selection of other previous
blocks as well. Adding this to the protocol could be done as soft-fork [sneaky sneaky tiny winy bikini]
with respect to the above previous witness data proof.

Who? brg444? or gavin? Was it in Virginia?     

He definitely doesn't know everything and he often makes mistakes too.  I've met him more than once, so I'm pretty sure I'm right about this.   

Well, shouldn't OP know this?

The lolcows are unusually agitated since Core's most recent show of strength.

Behold here Peter R Rizun, Managing Editor of the Ledger academic publication, openly lobbying Gavin to.... you guessed it..... censor the contributors out of the Bitcoin Core repo.