>
> The point I'm making is simply that to be useful, when you close a seal you
> have to be able to close it over some data, in particular, another seal.
> That's
> the key thing that makes the idea a useful construct for smart contacts,
> value
> transfer/currency systems, etc.
>
OK, your
>
> I would love to see an RFC-style standard "multiple-colored-coin-protocol"
> written by reps from all of the major protocols and that meta-merges the
> features of these implementations
>
We actually tried to do that in 2014-2015, but that effort have failed...
Nobody was really interested in
> I'm curious to hear the answers to the questions Luke asked earlier. I
> also read through the documentation and wasn't convinced it was thought out
> well enough to actually build something on top of,
>
There are many colored coin protocols in use. OpenAssets is probably the
most popular one,
> All practical single-use seals will be associated with some kind of
> condition,
> such as a pubkey, or deterministic expression, that needs to be satisfied
> for
> the seal to be closed.
I think it would be useful to classify systems w.r.t. what data is
available to condition.
I imagine it
> Ethically, this situation has some similarities to the DAO fork.
There are no similarities.
The DAO fork was against the principles of cryptocurrencies: a change of
the ledger done in violation of pre-agreed rules. The whole point of
cryptocurrency is to avoid shit like that. (E.g. a central
> Ethically, this situation has some similarities to the DAO fork.
Much better analogy:
1. An ISV make software which makes use of an undocumented OS feature.
2. That feature is no longer present in the next OS release.
3. ISV suffers losses because its software cannot work under new OS, and
> Agreed! There's no benefit to Bitcoin for having it - one way or the other
> miners are going to destroy ~12BTC/block worth of energy. Meanwhile it
> appears
> to have lead to something like a year of stupid political bullshit based
> on a
> secret advantage - there's no reason to invite a
> Can you please not forget to supply us more details on the claims made
> regarding the reverse engineering of the Asic chip?
>
> It is absolutely crucial that we get these independently verified ASAP.
>
Bitmain confirmed that their chips support ASICBOOST and it can be used for
mining:
>
> 2B. If Segwit has not activated at height H, Input 1 of the Bounty Payout
> is not valid since it spends a P2WPKH output
>
If SegWit has not activated at height H, P2WPKH is an "anyone can spend"
output.
SegWit is a soft fork, all SegWit transactions must be interpreted as valid
by old nodes.
>
> 2B. If Segwit has not activated at height H, Input 1 of the Bounty Payout
> is not valid since it spends a P2WPKH output, preventing the miner from
> including the Bounty Payout transaction in the block. (However, the output
> of the Segwit Assertion tx can be claimed since it is treated as
>
> Something I've recently realised is that TXO commitments do not need to be
> implemented as a consensus protocol change to be useful.
You're slow, Peter. I figured this out back in 2013:
https://bitcointalk.org/index.php?topic=153662.10
___
You should read this:
https://bitcointalk.org/index.php?topic=153662.10
On Wed, May 16, 2018 at 7:36 PM, Cory Fields via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Tl;dr: Rather than storing all unspent outputs, store their hashes.
> Untrusted
> peers can supply the full
12 matches
Mail list logo
