1) It's more private. Bloom filters gives away quite accurate statistical
information about what coins you own to whom ever you happen to be
connected too. An attacker can easily use this to deanonymize you even if
you don't reuse addresses; Tor does not help much against this attack.
There
At this point, I don't think what you are doing is even colored coins
anymore. You might want to look into Counterparty or Mastercoin.
Nope, it's still colored coins. The difference between colored coin model
and Mastercoin model is that colored coins are linked to transaction
outputs, while
This is outright ridiculous.
Zero-confirmation double-spending is a small problem, and possible
solutions are known. (E.g. trusted third party + multi-sig addresses for
small-value transactions.)
On the other hand, protocol changes like described above might have
game-theoretical implications
And it still would. Non-collusive miners cast votes based on the outcome
of their own attempts to double spend.
Individually rational strategy is to vote for coinbase reallocation on
every block.
Yes, in that case nobody will get reward. It is similar to prisoner's
dilemma: equilibrium has
These sorts of proposals are all just ways of saying block chains kind of
suck and we should go back to using trusted third parties.
No.
Different approaches have different trade-offs, and thus different areas of
applicability.
Proof-of-work's inherent disadvantage is that it takes some time
It is also useful for betting: an oracle will associate a hash with each
possible outcome, and when outcome is know, it will reveal a corresponding
preimage which will unlock the transaction.
This approach has several advantages over approach with multi-sig script:
1. oracle doesn't need to be
I can't remember who I saw discussing this idea. Might have been Vitalik
Buterin?
Yes, he described it in an article a couple of months ago:
http://blog.ethereum.org/2014/01/15/slasher-a-punitive-proof-of-stake-algorithm/
but it is an old idea.
For example, I've mentioned punishment of this
A distinction there is that they can only become invalid via a
conflict— replaced by another transaction authored by the prior
signers. If no other transaction could be created (e.g. you're a
multisigner and won't sign it again) then there is no such risk.
You need to check transaction's
I've heard about this idea from TierNolan. Here's some quick an dirty
analysis:
Suppose the last known block claimed a large tx fee of L. A miner who owns
1/N of the total hashrate needs to choose between two strategies:
1. Mine on top of that block and win usual reward R with probability 1/N.
# Death by halving
## Summary
If miner's income margin are less than 50% (which is a healthy situation
when mining hardware is readily available), we might experience
catastrophic loss of hashpower (and, more importantly, catastrophic loss of
security) after reward halving.
## A simple model
For the sake of argument, lets assume that somehow (quite unlikely)
Why is it unlikely? Do you believe that the cost of electricity cannot be
higher than expected mining revenue?
Or do you expect miners to keep mining when it costs them money?
half the mining equipment gets shut off.
The
This thread is, in my opinion, a waste of time. It's yet again
another perennial bikeshedding proposal brought up many times since at
least 2011, suggesting random changes for
non-existing(/not-yet-existing) issues.
There is a lot more complexity to the system than the subsidy schedule.
For those following this thread, we have now written a paper
describing the side-chains, 2-way pegs and compact SPV proofs.
(With additional authors Andrew Poelstra Andrew Miller).
http://blockstream.com/sidechains.pdf
Haven't seen any material discussion of this paper in this mailing
From the introduction [...]Because signers prove computational work,
rather than proving secret knowledge as
is typical for digital signatures, we refer to them as miners. To
achieve stable consensus on the
blockchain history, economic incentives are provided where miners are
rewarded with
Secure and client side validation don't really belong in the same
sentence, do they?
Well, client-side validation is mathematically secure, while SPV is
economically secure.
I.e. it is secure if you make several assumptions about economics of the
whole thing.
In my opinion the former is
I think what Gareth was getting at was that with client-side validation
there can be no concept of a soft-fork. And how certain are you that the
consensus rules will never change?
Yes, it is true that you can't do a soft-fork, but you can do a hard-fork.
Using scheduled updates: client simply
To remain useful as border router, the replace-by-fee patched core should
only relay double spend if it actually replaces an earlier transaction, as
otherwise the replace logic that is according to your commit more than just
fee comparison, would have to be replicated in the proprietary stack
Your scorched earth plan is aptly named, as it's guaranteed to make
unconfirmed payments useless.
Scorched earth makes no sense by itself. However, it can be a part of a
bigger picture. Imagine an insurance service which will make sure that
merchants are compensated for every scorched-earth or
The approach is how Bitcoin has always worked.
Mike, you're making it worked before, and thus it will work in future
kind of an argument.
It is an extremely shitty kind of an argument. And it can be used to
justify any kind of bullshit.
E.g. any scamcoin which haven't yet collapsed will work
Miners are *not* incentivised to earn the most money in the next block
possible. They are incentivised to maximise their return on investment.
This would be right if you assume that all Bitcoin miners act as a single
entity. In that case it is true that that entity's goal is to maximize
Just to add to the noise, did you consider linear growth?
Unlike exponential growth, it approximates diminishing returns (i.e. tech
advances become slower with time). And unlike single step, it will give
people time to adapt to new realities.
E.g. 2 MB in 2016, 3 MB in 2017 and so on.
So in 20
Adaptive schedules, i.e. those where block size limit depends not only on
block height, but on other parameters as well, are surely attractive in the
sense that the system can adapt to the actual use, but they also open a
possibility of a manipulation.
E.g. one of mining companies might try to
With POW, a new node only needs to know the genesis block (and network
rules) to fully determine which of two chains is the strongest.
But this matters if a new node has access to the globally strongest chain.
If attacker is able to block connections to legitimate nodes, a new node
will
Let's consider a concrete example:
1. User wants to accept Bitcoin payments, as his customers want this.
2. He downloads a recent version of Bitcoin Core, checks hashes and so on.
(Maybe even builds from source.)
3. Let's it to sync for several hours or days.
4. After wallet is synced, he gives
I don't really see how you can protect against total isolation of a node
(POS or POW). You would need to find an alternative route for the
information.
Alternative route for the information is the whole point of weak
subjectivity, no?
PoS depends on weak subjectivity to prevent long term
Yes, if you are on a slow network then you are at a (slight) disadvantage.
So?
Chun mentioned that his pool is on a slow network, and thus bigger blocks
give it an disadvantage. (Orphan rate is proportional to block size.)
You said that no, on contrary those who make big blocks have a
Stop trying to dictate block growth limits. Block size will be determined
by competition between miners and availability of transactions, not through
hard-coded limits.
Do you even game theory, bro? It doesn't work that way.
Mike Hearn described the problem in this article:
That orphan rate increase will go to whoever is producing the 20MB blocks,
NOT you.
This depends on how miners are connected.
E.g. suppose there are three miners, A and B have fast connectivity between
then, and C has a slow network.
Suppose that A miners a block and B receives it in 1
28 matches
Mail list logo
