Gareth Williams [ARCHIVE]

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2014-04-25 to 2017-03-06
💬 Posted a total of 22 messages
📚 Participated in the following categories: Bitcoin-development, bitcoin-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Public Key

npub1jkdfcglr59lwnhek94l393g0hhhaj0v5yzz3n5s3p0r9u0576sgs7373ck

Profile Code

nprofile1qqsftx5uy036zlhfmumz6lcjc58mmm7e8k2zppge6ggsh3j7860dgygzdke9r

Author Public Key

npub1jkdfcglr59lwnhek94l393g0hhhaj0v5yzz3n5s3p0r9u0576sgs7373ck

Show more details

Last Notes

2023-06-07 17:57:04

- reply

📅 Original date posted:2017-03-06
📝 Original message:What you're describing is a hashpower activated soft fork to censor transactions, in response to a user activated soft fork that the majority of hashpower disagrees with.
It is always possible for a majority of hashpower to censor transactions they disagree with. Users may view that as an attack, and can always respond with a POW hard fork.
Bitcoin only works if the majority of hashpower is not hostile to the users.
On 6 March 2017 9:29:35 PM AEDT, Edmund Edgar via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>On 6 March 2017 at 18:18, David Vorick via bitcoin-dev
><bitcoin-dev at lists.linuxfoundation.org> wrote:
>> User activated soft forks, or perhaps more accurately called
>'economically
>> forced soft forks' are a tool to use if the miners are in clear
>opposition
>> to the broader economy.
>
>I don't think they work for that, at least not for new features,
>because miners will presumably just head the whole thing off by
>orphaning the whole class of non-standard transactions that are the
>subject of the fork. In the SegWit case, they'd just orphan anything
>that looks like a SegWit transaction, valid or not. That way they
>don't need to worry about ending up on the wrong side of the upgrade,
>because no transaction affected by the proposed rule change will ever
>get into the longest chain. Rational node operators (particularly
>exchanges) will likely also adopt their stricter rule change, since
>they know any chain that breaks it will end up being orphaned, so you
>don't want to act on a payment that you see confirmed in it. So then
>you're back where you started, except that your soft-fork is now a
>de-facto hard-fork, because you have to undo the new, stricter rule
>that the miners introduced to head off your shenannigans.
>
>Where they're interesting is where you can do something meaningful by
>forcing some transactions through on a once-off basis. For example, if
>the Chinese government identified an address belonging to Uighur
>separatists and leaned on Chinese miners to prevent anything from that
>address confirming, it might be interesting for users to say, "If
>these utxos are not spent by block X, your block is invalid".
>
>They might also be interesting for feature upgrades in a world where
>mining is radically decentralized and upgrades are fighting against
>inertia rather than opposition, but sadly that's not the world we
>currently live in.

2023-06-07 17:32:29

- reply

📅 Original date posted:2015-08-05
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
On 4 August 2015 11:12:36 PM AEST, Gavin Andresen via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>On Tue, Aug 4, 2015 at 7:27 AM, Pieter Wuille via bitcoin-dev <
>bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> I would say that things already demonstrately got terrible. The
>mining
>> landscape is very centralized, with apparently a majority depending
>on
>> agreements to trust each other's announced blocks without validation.
>>
>And that is a problem... why?
With all due respect Gavin, large-block advocates appear to hold the position that:
* pushing individual economic actors away from running full nodes is a natural and unproblematic consequence of block size increase, as they're expected to rely on SPV
You now also appear to hold the position that:
* pushing miners to SPV mining is unproblematic
Have I misunderstood? Is one of these not an expected outcome of large blocks? I can understand the validity of either argument alone -- the assertion that we can trust miners to validate and just trust most-POW ourselves, /or/ the assertion that lack of miner validation is safe under certain circumstances. But together?
Who do you expect to actually validate large blocks if not miners, and what do you expect their incentive to do so to be?
-----BEGIN PGP SIGNATURE-----
Version: APG v1.1.1
iQFABAEBCgAqBQJVwcYAIxxHYXJldGggV2lsbGlhbXMgPGdhY3J1eEBnbWFpbC5j
b20+AAoJEEY5w2E3jkVEEWQH/Aty47q71H/ZcMMX/6qcTpOumI9h/buUfsvYA2H+
J6Al5S8JvCy3/0yMFCLmqolHoxOdWu5jwtUf/w2fepgA1RJyZItFo1EG9cJB0Cpz
JgM+2s4L/F3l4+Gea2ddjhvE5JqGS0Qh3EWaR/xy1bouq0FZjtDendmK7vFRj/oS
Gowm+g5EFBiT1XwCQQXJc9k0RxzDpPQ0ouSOXWdPUuxfQAjPyX89eQBeQzgVDtEf
zVfROZVHQuBu85rKTd32TdCNLQ0oEhAYmwgdtmJyLLgieeqHmNbaikBaVDEOvixn
S+fmnfD8CVeeXo5zKdlLZXazc5geRx97H4NMBMjTyjPzR5k=
=WG0I
-----END PGP SIGNATURE-----

2023-06-07 15:44:48

- reply

2023-06-07 15:43:31

- reply

📅 Original date posted:2015-07-23
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
>I don't understand the situation here. Is the assumption of a group of
>miners suddenly switching (for example, they realise that they didn't
>intend to support the new rules)?
Or they're economically rational miners, and a large difficulty decrease on the original chain, without an equally large decrease in the value of original chain tokens, has made it profitable to switch?
It's dangerous to assume all miners will continue to support the side they have initially signaled. They're only invested in the chain they mine for a short time (until coinbase maturity.)
If both sides if a fork retain value you'd expect mining to redistribute itself WRT short term profitability at every difficulty adjustment, irrespective of initially signaled support for the fork.
-----BEGIN PGP SIGNATURE-----
Version: APG v1.1.1
iQFABAEBCgAqBQJVsZIuIxxHYXJldGggV2lsbGlhbXMgPGdhY3J1eEBnbWFpbC5j
b20+AAoJEEY5w2E3jkVEN7YIAIlgaAahHCssIEXYzqB1gRKYRP4fPsq8NtOMrkki
dc1gfKmprlPDShFvu2Hn5L8amP51ouRpmDSJwNyU//1DyU5p1tcWTAtkHr6SY7TY
uJtcPMM03BUD2i3rXSY4FbpWn8aOoUnQrkYFhx5Y/Aru+l47C0I5KF4fgMag7FhI
RxkTFylvq7uWvu0QCUkVh1MgohNxMqIGAvE5t8yoj5LxrNzOq95TcOGwFngWCdJM
a5BADFjq7v4j/+cP748ZTPcLUusTQTwEuIsCIhpwwiKADsy1FKjmAdHhKTff/6wn
cpNYvwimKNSSESCwzAnxekaJCTXpEOWQV7/6FO9vJbTMKw8=
=/hJk
-----END PGP SIGNATURE-----

2023-06-07 15:43:10

- reply

📅 Original date posted:2015-07-23
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
I've seen a lot of talk on this list debating the role of Bitcoin Core and its maintainers WRT consensus, typically focused around whether they can technically force anyone to run their code (of course, they can't.)
I've yet to see the discussion framed in terms of influence and leadership. Which is why I want to highlight:
>I believe it is the responsibility of the maintainers/developers of
>Bitcoin
>Core to create software which helps guarantee the security and
>operation of
>the Bitcoin network
Perhaps s/helps guarantee/promotes/ , but this stands out as an excellent description of Bitcoin Core's relationship to the Bitcoin network.
Defaults are powerful. Users technically /can/ compile and run any code they like, but very few even bother to change configurable settings. They just want a trusted brand ("Bitcoin Core") that does the right thing out of the box. Bitcoin Core and its maintainers play a valuable /leadership/ role for the network. Whether they can force people to run their code is uninteresting -- people trust them.
That trust is well earned, precisely because they have always promoted the operation and security of the network.
In light of this responsibility it seems unreasonable for anyone to expect Core maintainers to promote patches that endanger network consensus (e.g. user configurable consensus parameters.)
Consensus is order of business #1. If we can't all agree to use the same money then the grand experiment is resolved as a failure. Everyone has consensus parameters they'd (strongly) prefer. Somebody needs to heard us all toward using the same ones, sometimes even in the face of very high costs.
- -Gareth
-----BEGIN PGP SIGNATURE-----
Version: APG v1.1.1
iQFABAEBCgAqBQJVsKPgIxxHYXJldGggV2lsbGlhbXMgPGdhY3J1eEBnbWFpbC5j
b20+AAoJEEY5w2E3jkVEZuEIAIKC9jTO33y4YC/cl1mO/+ux9YUqBlFUpuElKjNe
NLUIqPANrMV3nTjUm666Hk3tVHk8IpYLUU1pRuYBAT17d1t/2bFC4CpfpWssF9Nw
YhoYOKKVMvLUR4DRlkyhMD4YxorJ/TGiuEaFD4K/1s5uKf1+7Vj/BTi+SP+AIAIW
gTbn2CA3T4n8WjDYADE0dqcYSqzt2M1fjXB+Ld95JGLun8m+6lDPhFy/o5aGhBk6
5j86SITT9UtyyA6oaV5NNNgumcNBievnVwjTxjaWm8CBJlJ5jNpW65PQGkoSnCgz
TpYt/wZHcdSqBeNHyno9XaEBSm99Ylk3i2Z1dGQwrSsZU0Q=
=0pac
-----END PGP SIGNATURE-----

2023-06-07 15:40:12

- reply

📅 Original date posted:2015-06-25
📝 Original message:On Thu, Jun 25, 2015 at 10:07 AM, Milly Bitcoin <milly at bitcoins.info>
wrote:
<snip>
> Also, the incentive for new
> developers to come in is that they will be paid by companies who want to
> influence the code and this should be considered
<snip>
> Now you are left with a broken, unwritten/unspoken process.
Your former statement is a great example of why "rough consensus and
running code" is superior to design by committee.
An argument should be assessed on its technical merit alone, not on
the number of people advancing it -- a process that would be open to
exactly the type of external manipulation you say you are concerned
about.

2023-06-07 15:39:51

- reply

📅 Original date posted:2015-06-25
📝 Original message:On 24 June 2015 1:49:51 PM AEST, Jeff Garzik <jgarzik at gmail.com> wrote:
>Miners can collude today to lower the block size limit.
Of course they can. What, then, is the need for BIP100's hard-limit voting mechanism?
You only need consensus rules to enforce block size limits if you're enforcing them _against_ miners. Which may be a perfectly valid thing to do (if your threat model includes, for example, the possibility that large miners deliberately create large blocks to gain an advantage over small miners.) But BIP100 doesn't address that anyway.
Wouldn't it be safer for consensus to get behind Gavin's simpler 8MB->8GB hard-limit growth curve*, and then encourage miners to enforce a soft limit below that, agreed through a voting mechanism? The later can be implemented at any time without consensus changes -- nobody can prevent miners from coordinating the max block size they'll build on anyway.
* but with a safer "supermajority" than 75% please :)
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

2023-06-07 15:27:54

- reply

📅 Original date posted:2014-12-17
📝 Original message:On Mon, Dec 15, 2014 at 3:52 PM, Peter Todd <pete at petertodd.org> wrote:
>> Comparisons with the SPV security of sidechains are fallacious. The
>> alternative to a proof-of-publication system reliant on client-side
>> validation is a blockchain. The question of whether the token used on
>> said blockchain should be two-way-pegged to BTC is completely orthogonal.
>>
>> (ie. yes, sidechains are "economically secure", in that you're reduced
>> to balancing economic incentives to avoid peg theft. But sidechains also
>> give us something unique in return - the ability to innovate without
>> needing to start new artificial scarcity races. Nothing else can do that.)
>
> I covered this in my original post: 1-way-pegs allow the creation of new
> valuable tokens without those tokens being useful for speculation.
I stand corrected. A permanent 1-way-peg is sufficient to preserve
scarcity; "nothing else can do that" WRT 2-way-pegs was overreaching.
I still don't see what "2-way-peg vs. 1-way-peg" has to do with
"embedded consensus vs. blockchain consensus" though, and feel it
disingenious to conflate them.
Blockchain consensus (eg. sidechains) can utilise either mechanism,
1-way-peg or 2-way-peg. Arguments in favour of 1-way-peg are
interesting, but they're ultimatley just arguments in favour of one
type of sidechain over another.
Arguments in favour of embedded consensus - and I feel I'm being
generous with the term "consensus" here - should surely stand on their
own merit against blockchain consensus, if they're to be convincing.
> Of course even without 1-way-pegs there's a much more important issue
> with your objection: worrying about creating new artificial scarcity
> races while innovating is fundementally a *moralistic* and *regulatory*
> concern that has no little if any bearing on whether or not the systems
> created are useful and secure. It's also an objection that raises
> serious questions about conflicts of interest between giving accurate
> and honest technical advice and promoting ways of using Bitcoin that
> will drive the price up.
IMO the question of whether scarcity can be preserved while enabling
innovation bears heavily on the liklihood of longterm viability of
said innovations - and perhaps of Bitcoin itself.
FWIW I'll happily declare that I hold a modest amount of BTC and have
an interest in the price appreciating. I'm sure you'll admit you're
hardly an impartial party in this discussion yourself Peter :) But it
really shouldn't matter. I'm not here today to make it, but I think
the argument for preservation of scarcity stands quite well on its own
merits - as rightly it should, regardless of anybody's interests.
> A number of mechanisms for detecting divergence are possible in embedded
> consensus systems, some of them even natural outcomes. For instance
> transactions can contain a hash of the previous consensus state, thereby
> creating an indicator of consensus measured in terms of economic stake.
> Extending that idea many anti-censorship proposals are to use such state
> hashes as encryption keys - if you are out of consensus you won't even
> see the transaction. (and you can't be double-spent either if
> implemented correctly; see my other reply to this thread today)
<snip>
> Indeed I did, which is why I worked out a better way to do upgrades
> almost a year ago:
>
> http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg06578.html
<snip>
> The quality of Counterparty's software engineering has no bearing on
> whether or not the underlying idea is a good one; you wouldn't say ring
> signatures are an inherently bad idea just because the CryptoNote
> implementation of them is atrocious.
Very interesting. I admit I hadn't come across these ideas before; I
really must search the archive before posting :) They certainly offer
a measure of robustness over the naive approach. I'm not sure they
address my primary concerns however, WRT how consensus is demonstrated
and incentivised.
I know what my own node considers valid transaction history; how can I
be confident that everyone else takes the same view? For contrast,
with blockchain consensus, I can be confident that there is consensus
on the longest chain observed. If I receive a new transaction, simply
waiting for it to be buried under N blocks of PoW provides a high
level of confidence that everyone else considers it valid.
The obvious "embedded consensus" answer of "wait until N other
transactions have occurred that include a hash of system state that
includes your transaction" doesn't provide me with any confidence; it
could be simulated with a Sybil attack.
<snip>
> I prefer to make robust arguments; if I can start with accepting that
> 95% of what my opponents say is true, yet still end up being correct,
> all the better!
Indeed :) To avoid wasting time it's only ever worth arguing against
the strongest opposing position you're aware of (whether your opponent
is aware of it or not.)
https://en.wikipedia.org/wiki/Principle_of_charity

2023-06-07 15:27:53

- reply

📅 Original date posted:2014-12-13
📝 Original message:On 13/12/14 04:04, Alex Mizrahi wrote:
> 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.
Comparisons with the SPV security of sidechains are fallacious. The
alternative to a proof-of-publication system reliant on client-side
validation is a blockchain. The question of whether the token used on
said blockchain should be two-way-pegged to BTC is completely orthogonal.
(ie. yes, sidechains are "economically secure", in that you're reduced
to balancing economic incentives to avoid peg theft. But sidechains also
give us something unique in return - the ability to innovate without
needing to start new artificial scarcity races. Nothing else can do that.)
<snip>
> You know, The Great Fork of 2013 was resolved through human
> intervention, Bitcoin nodes were not smart enough to detect that
> something is going awry on their own.
I hate to think what the outcome would've been on a proof-of-publication
system. You don't even have a fork. You just have a whole bunch of nodes
who sort-of-mostly agree on a shared history, except where they don't.
Maybe they just disagree on the validity of a single transaction.
They'll slowly diverge over time (as bad transactions are used as input
to other transactions.) You have no reliable way to detect this lapse in
consensus, nor any mechanism to incentivse convergence. Indeed, you have
no consensus mechanism in the first place.
Bitcoin is where it is today because of Satoshi's elegant solution to
exactly such problems. Which some people now appear to be in a hurry to
discard :)
Alex Mizrahi wrote:
> Using scheduled updates: client simply stops working at a certain block,
> and user is required to download an update.
<snip>
> An alternative to this is to make updates mandatory. You will no longer
> need to maintain compatibility with version 0.1 (which is impossible)
> and you can also evolve consensus rules over time.
Peter Todd might disagree with the wisdom of that :) He wrote an
excellent email to this list not long ago warning of the dangers of
centralisation. IIRC one point he made was that scheduled, regular
hardforks were a real threat - if a single entity (eg. the Bitcoin
Foundation) were to become politically established as the coordinator of
such forks, they would have de-facto control over the protocol.
Even in that dark scenario, I would feel a measure of confidence that
past transactions I had received could not be tampered with. The fact
that those transactions happened, and that there was (and is) consensus
they were valid, is publicly documented in the blockchain. I trust any
reasonable person would not accept a client that ignored validated data
in the blockchain as "Bitcoin" any more.
Your proof-of-publication system with mandatory updates is another
matter entirely. No public record of transactions I have received with
that system exists, anywhere. If tomorrow's mandatory update has the
effect of zeroing my account balance (by happening to now interpret one
or more transactions I received, or their inputs, as invalid) then I
have no recourse. I won't find sympathy with the majority of users, who
are unaffected and just accept the update.
In short, what you describe doesn't sound very decentralised :) Do you
want transactions you receive validated by distributed consensus and
burried under PoW, or validated by some guy's mandatory-updating python
script?
(Also worth noting: all such systems are effectively "mandatory
updating" due to the risk of subtle consensus bugs of the type I
described above. Your only assurance that your view of the world is the
same as everyone elses' is that you're running the exact same software.
I played with Counterparty a while ago and quickly learned - the hard
way - to do a 'git pull' before any important operation.)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20141214/312b03d8/attachment.sig>

2023-06-07 15:27:51

- reply

📅 Original date posted:2014-12-12
📝 Original message:On 12/12/14 20:05, Peter Todd wrote:
> Secondly using a limited-supply token in a proof-of-publicaton system is
> what lets you have secure client side validation rather than the
> alternative of 2-way-pegging that requires users to trust miners not to
> steal the pegged funds.
"Secure" and "client side validation" don't really belong in the same
sentence, do they?
If I am to accept a transaction with any assurance of security at all,
the important question to ask is not: "does my client consider this
valid?" but: "does the rest of the world consider this valid?"
Validated data in the blockchain is far more useful for this purpose
than unvalidated data with a mere proof of publication in the
blockchain, precisely because it records what /everybody else/ considers
valid history (and very likely will continue to consider valid history
in future.)
Pegged sidechains have their challenges, but at least they provide
distributed consensus on transaction history.
Proof-of-publication systems like Counterparty and Mastercoin require me
to trust, with zero evidence, that everybody else's client has the exact
same interpretation of transaction history as mine, and will continue to
have for the indefinite future. How is that not a horribly broken
security model? I'd use a sidechain - with reasonable parameters that
disincentivise peg theft as much as practical - over that any day.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20141212/e4a2e4e2/attachment.sig>

2023-06-07 15:20:02

- reply

📅 Original date posted:2014-04-26
📝 Original message:Who said anything about a re-org? The original block remains valid, your block reward is just zero, upon maturity, in light of a valid fraud proof.
ie. the "coinbase confiscation" that I was just arguing against in another thread :P but of course here based on cryptographic proof, not human judgement.
On 27 April 2014 11:22:07 AM AEST, Mark Friedenbach <mark at monetize.io> wrote:
>That makes double-spends trivially easy: sign two blocks, withholding
>one. Then at a later point in time reveal the second signed block
>(demonstrating your own fraud) and force a reorg.
>
>On 04/26/2014 04:44 PM, Gareth Williams wrote:
>> What about using fraud proofs? Your coinbase only matures if nobody
>publishes proof that you signed a competing block.
>>
>> Then something is at least at stake. When it's your chance to sign a
>block, attempting to sign and publish more than one at the same height
>reliably punishes you (you effectively waste your chance and receive no
>reward.)
>>
>> I can't remember who I saw discussing this idea. Might have been
>Vitalik Buterin?
>>
>> On 27 April 2014 6:39:28 AM AEST, Mark Friedenbach <mark at monetize.io>
>wrote:
>>> There's no need to be confrontational. I don't think anyone here
>>> objects
>>> to the basic concept of proof-of-stake. Some people, myself
>included,
>>> have proposed protocols which involve some sort of proof of stake
>>> mechanism, and the idea itself originated as a mechanism for
>>> eliminating
>>> checkpoints, something which is very much on topic and of concern to
>>> many here.
>>>
>>> The problems come when one tries to *replace* proof-of-work mining
>with
>>> proof-of-stake "mining." You encounter problems related to the fact
>>> that
>>> with proof-of-stake nothing is actually at stake. You are free to
>sign
>>> as many different forks as you wish, and worse have incentive to do
>so,
>>> because whatever fork does win, you want it to be yours. In the
>worst
>>> case this results in double-spends at will, and in the best case
>with
>>> any of the various proposed protections deployed, it merely reduces
>to
>>> proof-of-work as miners grind blocks until they find one that names
>>> them
>>> or one of their sock puppets as the signer of the next block.
>>>
>>> I sincerely doubt you will find a solution to this, as it appears to
>be
>>> a fundamental issue with proof-of-stake, in that it must leverage an
>>> existing mechanism for enforced scarcity (e.g. proof-of-work) in
>order
>>> to work in a consensus algorithm. Is there some solution that you
>have
>>> in mind for this?
>>>
>>> Mark
>>>
>>> On 04/25/2014 12:33 AM, Troy Benjegerdes wrote:
>>>> Do it. Someone will scream harm. The loudest voices screaming how
>it
>>> would
>>>> be harmful are doing the most harm.
>>>>
>>>> The only way to know is build it, and test it. If the network
>breaks,
>>> then
>>>> it is better we find out sooner rather than later.
>>>>
>>>> My only suggestion is call it 'bitstake' or something to clearly
>>> differentiate
>>>> it from Bitcoin. This also might be an interesting application of
>the
>>> side
>>>> chains concept Peter Todd has discussed.
>>>>
>>>> On Thu, Apr 24, 2014 at 04:32:15PM -0700, Stephen Reed wrote:
>>>>> Hello all.
>>>>>
>>>>> I understand that Proof-of-Stake as a replacement for
>Proof-of-Work
>>> is a prohibited yet disputed change to Bitcoin Core. I would like to
>>> create a Bitcoin branch that provides a sandboxed testbed for
>>> researching the best PoS implementations. In the years to come,
>perhaps
>>> circumstances might arise, such as shifting of user opinion as to
>>> whether PoS should be moved from the prohibited list to the
>hard-fork
>>> list.
>>>>> -----
>>>>>
>>>>> A poll I conducted today on bitcointalk,
>>> https://bitcointalk.org/index.php?topic=581635.0 with an
>>> attention-grabbing title suggests some minority support for Bitcoin
>>> Proof-of-Stake. I invite any of you to critically comment on that
>>> thread.
>>>>>
>>>>> "Annual 10% bitcoin dividends can be ours if Proof-of-Stake full
>>> nodes outnumber existing Proof-of-Work full nodes by three-to-one.
>What
>>> is your choice?"
>>>>>
>>>>> "I do not care or do not know enough." - 5 (16.1%)
>>>>> "I would download and run the existing Proof-of-Work program to
>>> fight the change." - 14 (45.2%)
>>>>> "I would download and run the new Proof-of-Stake program to favor
>>> the change. " - 12 (38.7%)
>>>>> Total Voters: 31
>>>>> -----
>>>>>
>>>>> Before I branch the source code and learn the proper way of doing
>>> things in this community, I ask you simply if creating the branch is
>>> harmful? My goal is to develop, test and document PoS, while
>exploring
>>> its vulnerabilities and fixing them in a transparent fashion.
>>>>>
>>>>> Thanks for taking a bit of your time to read this message.
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>------------------------------------------------------------------------------
>>> Start Your Social Network Today - Download eXo Platform
>>> Build your Enterprise Intranet with eXo Platform Software
>>> Java Based Open Source Intranet - Social, Extensible, Cloud Ready
>>> Get Started Now And Turn Your Intranet Into A Collaboration Platform
>>> http://p.sf.net/sfu/ExoPlatform
>>> _______________________________________________
>>> Bitcoin-development mailing list
>>> Bitcoin-development at lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>
>------------------------------------------------------------------------------
>Start Your Social Network Today - Download eXo Platform
>Build your Enterprise Intranet with eXo Platform Software
>Java Based Open Source Intranet - Social, Extensible, Cloud Ready
>Get Started Now And Turn Your Intranet Into A Collaboration Platform
>http://p.sf.net/sfu/ExoPlatform
>_______________________________________________
>Bitcoin-development mailing list
>Bitcoin-development at lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/bitcoin-development
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

2023-06-07 15:20:00

- reply

📅 Original date posted:2014-04-26
📝 Original message:What about using fraud proofs? Your coinbase only matures if nobody publishes proof that you signed a competing block.
Then something is at least at stake. When it's your chance to sign a block, attempting to sign and publish more than one at the same height reliably punishes you (you effectively waste your chance and receive no reward.)
I can't remember who I saw discussing this idea. Might have been Vitalik Buterin?
On 27 April 2014 6:39:28 AM AEST, Mark Friedenbach <mark at monetize.io> wrote:
>There's no need to be confrontational. I don't think anyone here
>objects
>to the basic concept of proof-of-stake. Some people, myself included,
>have proposed protocols which involve some sort of proof of stake
>mechanism, and the idea itself originated as a mechanism for
>eliminating
>checkpoints, something which is very much on topic and of concern to
>many here.
>
>The problems come when one tries to *replace* proof-of-work mining with
>proof-of-stake "mining." You encounter problems related to the fact
>that
>with proof-of-stake nothing is actually at stake. You are free to sign
>as many different forks as you wish, and worse have incentive to do so,
>because whatever fork does win, you want it to be yours. In the worst
>case this results in double-spends at will, and in the best case with
>any of the various proposed protections deployed, it merely reduces to
>proof-of-work as miners grind blocks until they find one that names
>them
>or one of their sock puppets as the signer of the next block.
>
>I sincerely doubt you will find a solution to this, as it appears to be
>a fundamental issue with proof-of-stake, in that it must leverage an
>existing mechanism for enforced scarcity (e.g. proof-of-work) in order
>to work in a consensus algorithm. Is there some solution that you have
>in mind for this?
>
>Mark
>
>On 04/25/2014 12:33 AM, Troy Benjegerdes wrote:
>> Do it. Someone will scream harm. The loudest voices screaming how it
>would
>> be harmful are doing the most harm.
>>
>> The only way to know is build it, and test it. If the network breaks,
>then
>> it is better we find out sooner rather than later.
>>
>> My only suggestion is call it 'bitstake' or something to clearly
>differentiate
>> it from Bitcoin. This also might be an interesting application of the
>side
>> chains concept Peter Todd has discussed.
>>
>> On Thu, Apr 24, 2014 at 04:32:15PM -0700, Stephen Reed wrote:
>>> Hello all.
>>>
>>> I understand that Proof-of-Stake as a replacement for Proof-of-Work
>is a prohibited yet disputed change to Bitcoin Core. I would like to
>create a Bitcoin branch that provides a sandboxed testbed for
>researching the best PoS implementations. In the years to come, perhaps
>circumstances might arise, such as shifting of user opinion as to
>whether PoS should be moved from the prohibited list to the hard-fork
>list.
>>> -----
>>>
>>> A poll I conducted today on bitcointalk,
>https://bitcointalk.org/index.php?topic=581635.0 with an
>attention-grabbing title suggests some minority support for Bitcoin
>Proof-of-Stake. I invite any of you to critically comment on that
>thread.
>>>
>>> "Annual 10% bitcoin dividends can be ours if Proof-of-Stake full
>nodes outnumber existing Proof-of-Work full nodes by three-to-one. What
>is your choice?"
>>>
>>> "I do not care or do not know enough." - 5 (16.1%)
>>> "I would download and run the existing Proof-of-Work program to
>fight the change." - 14 (45.2%)
>>> "I would download and run the new Proof-of-Stake program to favor
>the change. " - 12 (38.7%)
>>> Total Voters: 31
>>> -----
>>>
>>> Before I branch the source code and learn the proper way of doing
>things in this community, I ask you simply if creating the branch is
>harmful? My goal is to develop, test and document PoS, while exploring
>its vulnerabilities and fixing them in a transparent fashion.
>>>
>>> Thanks for taking a bit of your time to read this message.
>>
>>
>>
>>
>
>------------------------------------------------------------------------------
>Start Your Social Network Today - Download eXo Platform
>Build your Enterprise Intranet with eXo Platform Software
>Java Based Open Source Intranet - Social, Extensible, Cloud Ready
>Get Started Now And Turn Your Intranet Into A Collaboration Platform
>http://p.sf.net/sfu/ExoPlatform
>_______________________________________________
>Bitcoin-development mailing list
>Bitcoin-development at lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/bitcoin-development
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

2023-06-07 15:19:58

- reply

📅 Original date posted:2014-04-25
📝 Original message:On 25/04/14 20:19, Mike Hearn wrote:
> You don't get any money back, but you do get an angry shopkeeper chasing
> you down the street / calling the police / blacklisting you from the
> store.
>
>
> If they could do that they'd just take the stolen property back and you
> would have failed to spend your money twice. So this is by definition,
> not a successful double spend. We are worried about the cases when you
> could successfully double spend, and the only thing stopping you is Bitcoin.
You might not succeed in catching them, but however small the risk of
getting caught is, they're taking that risk for an assured zero gain.
Any rational attacker would therefore not bother.
I think it's a very elegant solution to the typical "broadcast double
spend" attack. Of course it unfortunately does nothing to stop a
dishonest mining pool from secretly working on your double spend for a
fee. But that breaks down to:
* trade first and hope the dishonest pool finds the next block
* the dishonest pool finds and withholds the block while you trade
We can discount the second one entirely - the orphan risk makes it very
expensive to execute, and people are typically accepting zero-conf for
low value items like cups of coffee. For high value items it is probably
reasonable (and hopefully common practice?) to wait for a block.
So we're left with the first situation. As others have noted, given a
dishonest pool with 5% total hashrate, a dedicated attack is out (unless
you want to end up actually buying goods to 20x the value of the attack
in the process.)
That leaves the opportunists, who press the "attempt to take-back 70% of
this transaction" (remember the pool gets their cut) every time they buy
a coffee and very occasionally get lucky. They're the only unsolvable
problem I can see here. It remains to be seen how many such opportunists
we'll end up with, or how much hashrate the dishonest pool can actually
attract.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 555 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140425/4eec67b2/attachment.sig>

2023-06-07 15:19:57

- reply

📅 Original date posted:2014-04-25
📝 Original message:On 24/04/14 22:07, Chris Pacia wrote:
> It would work but it's an ugly hack IMO. What do people do if they don't
> have extra to pay when making a purchase? I have 200 mbtc and want to
> buy a 200 mbtc phone but I can't because I need 400 mbtc. Sucks for me.
I don't see why it couldn't work with just 200mBTC.
* you sign a 200mBTC TX to me, walk out of my shop with the phone
* you immediately sign & broadcast a double-spend TX with higher fee
* my POS computer (or BitPay's) sees the double spend, immediately
spends the initial TX to fees, and sounds the shoplifting alarm.
You don't get any money back, but you do get an angry shopkeeper chasing
you down the street / calling the police / blacklisting you from the
store. Assuming my POS computer's behaviour was completely automated and
widespread - and therefore predictable on your part - why would you ever
try this?
The number of people irrational enough to try this /knowing it never
works/ is likely to be way lower than the number who just stuff the
phone in their pocket and shoplift the old fashioned way. So I'd be
comfortable without the extra 200mBTC collateral :-)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 555 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140425/6303edf4/attachment.sig>

2023-06-07 15:19:42

- reply

📅 Original date posted:2014-04-30
📝 Original message:On 30/04/14 00:13, Mike Hearn wrote:
> I do think we need to move beyond this idea of Bitcoin being some kind
> of elegant embodiment of natural mathematical law. It just ain't so.
I haven't seen anybody arguing that it is.
Bitcoin is the elegant embodiment of /artificially contrived/
mathematical rules, which just so happen to be very useful in their
current configuration :-P
Nobody is saying those rules are immutable. Just that it isn't sensible
to undermine them by introducing imprecise and unpredictable elements
like human politics.
> Every time miners and nodes ignore a block that creates >formula() coins
> that's a majority vote on a controversial political matter
No it isn't. That's the node enforcing the protocol. It isn't a matter
of opinion, and it isn't a vote. The protocol is clearly defined: you
either follow it or you're not running a Bitcoin node. If 51% don't
follow it tomorrow /they're/ not running Bitcoin.
Contrast with your "vote to reinterpret the meaning of arbitrary blocks"
mechaism - you're free to vote either way while remaining within the
protocol. That's a /real/ vote - majority decides what the Bitcoin
protocol /and every node that follows it/ will recognise as valid.
Nothing like that currently exists. Thank $deity.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 555 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140430/3e39d0ea/attachment.sig>

2023-06-07 15:19:42

- reply

📅 Original date posted:2014-04-30
📝 Original message:On 30/04/14 00:13, Mike Hearn wrote:
> Every time miners and nodes ignore a block that creates >formula() coins
> that's a majority vote on a controversial political matter
Actually, there's one more thing I'd like to add. Apologies to the list,
but it bears repeating:
* rejecting a block at validation
Is /very different/ from:
* reinterpreting a block that has already passed validation
Nodes ignoring a block that creates >formula() coins is rejection at
block *validation*. That's the protocol working as it is supposed to.
It's deliberately an all-or-nothing mechanism; you can't pick and choose
which blocks you like. If 51% of the network say your block is invalid,
they're now on a different fork. The consequences are this drastic on
purpose, for stability.
Nodes reinterpreting a block that has already passed validation is
almost the polar opposite of this. They're /ignoring the protocol/ and
making up their own meaning for stuff. Sidestepping the mechanism in the
paragraph above. I would hope it'd be self evident that this is dangerous.
Adam Back is arguing practicality in this thread. I'm arguing
fundamental principle. (And, er, someone else is randomly throwing
around ad hominems, which we'll politely ignore; Mike could work for
Lucifer himself and his good ideas would still be good, and his bad
ideas would still be bad, so let's just stick to the ideas eh.)
So, fundamental principle: don't reinterpret history!
We have validation for a very good reason. Undermine it and you might as
well have an unvalidated system like Counterparty, which I wouldn't
ever trust with more than the value of a small hamburger.
If the economic majority starts reinterpreting history (through whatever
voting mechanism / side-channel you like) that completely undermines
Bitcoin's validation, and its PoW. It's worse than 51% of miners
deciding to rewrite history.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 555 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140501/cba8ecc6/attachment.sig>

2023-06-07 15:19:41

- reply

📅 Original date posted:2014-04-30
📝 Original message:On 30/04/14 23:55, Mike Hearn wrote:
> If Bitcoin works correctly nobody should have to care if they consider
> themselves attackers, defenders, or little green men from Mars.
>
>
> One last time, I request that people read the white paper from 2008
> before making statements like this. If the notion of attacker was
> irrelevant to Bitcoin, it would not be mentioned in the abstract, would it?
I've read it :) The notion of an attacker is obviously relevant to
someone designing the system. It should not be relevant to someone
running a node.
I'll retire from posting on this too, I've posted way too much.
Our fundamental disagreement is simply that you think Bitcoin is, or
should be, a /democratic/ system. I think Bitcoin is, and should be, a
/trustless/ system. If we're going to resort to appeal to authority,
I'll point to the words "Electronic Cash System" in the title of
Satoshi's whitepaper :-P He intended to create ecash; that's widely
understood to mean trustless.
If there was this magic computer up in the sky somewhere, free from
human influence, that would run Satoshi's code for him in perpetuity
(let's overlook the initial upload please, bear with me), then I believe
Satoshi would've built his perfectly trustless ecash to run on that.
For lack of such a magic masterless computer he had to approximate one,
ingeniously using distributed consensus to achieve it. That's his real
invention - the "magic masterless computer" simulator, and the incentive
scheme to get the world to run it for him. (We'll see more of what it
can do if Ethereum ever gets off the ground.)
But for Pete's sake, Bitcoin is trustless. Just because the
infrastructure it sits atop is "democratic" (because there was no other
way to implement it,) doesn't mean you suddenly have to start voting on
everything.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 555 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140501/afb10d09/attachment.sig>

2023-06-07 15:19:41

- reply

📅 Original date posted:2014-04-30
📝 Original message:On 30/04/14 00:26, Mike Hearn wrote:
> These parties wouldn't generally consider themselves attackers
>
>
> Of course not, attackers rarely do :)
If Bitcoin works correctly nobody should have to care if they consider
themselves attackers, defenders, or little green men from Mars. There
are simply nodes that follow the protocol, and nodes that do not.
The fact that you even need to think about who should and should not be
considered an attacker, in the context of your proposed change, should
be ringing alarm bells :)
> What do you think miners exist for?
Ordering transactions.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 555 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140430/e5d8bcd3/attachment.sig>

2023-06-07 15:19:39

- reply

📅 Original date posted:2014-04-27
📝 Original message:Agreed. I'm a pragmatist, certainly not anti-change (or even anti-zero-conf.) Useful and non-controversial hard forks don't keep me awake at night :) I support your general position on zero-conf payments (that they're useful and we should make them as reliable as practical.)
But the very essence of Bitcoin, to me, is trustlessness. Satoshi's great invention isn't just another payment network - it's /ecash/. Bearer-negotiable, whoever-controls-the-private-keys-owns-it, **ecash**.
If not that, what do you think it is? :-)
I like trustless systems for purely pragmatic, cost-benefit reasons. They allow us to avoid all the costs associated with imperfect humans, while reaping the benefits of reliability and predictability :P
On 28 April 2014 12:31:05 AM AEST, Mike Hearn <mike at plan99.net> wrote:
>>
>> That moves us away from a pure trustless system built upon a small
>> democratic foundation (as something of a necessary evil in an
>imperfect
>> world where humans run our computers and use our system) and toward a
>> "democratic system".
>>
>> You don't have to agree, but I hope you can understand the point I'm
>> making :-)
>
>
>Yep, your point is well made.
>
>I don't have much more to say about this proposal specifically, but I
>think
>this whole question of what changes are OK and what would be a
>violation of
>the social contract will get discussed endlessly over the coming years.
>Put
>another way, what do Bitcoin's users expect and want - a system that
>evolves or a system that remains exactly as they found it? There will
>be
>good arguments on both sides, and the answer will probably be different
>on
>a case by case basis. But personally I'm skeptical of any argument that
>argues against change for its own sake. It has to be an argument rooted
>in
>a careful analysis of costs and benefits.
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

2023-06-07 15:19:39

- reply

📅 Original date posted:2014-04-27
📝 Original message:On 27/04/14 11:42, Christophe Biocca wrote:> This seems like splitting
hairs, no? A block isn't a guarantee (it can
> get orphaned). And as a user of bitcoin (as opposed to a miner), this
> change cannot affect any payment you ever receive.
Disagree. Maybe we just have a fundamental disagreement about what
Bitcoin is? :)
Bitcoin is this perfect /trustless/ mathematical machine, built - most
unfortunately - upon a foundation of mushy humans.
We depend specifically upon these three assumptions:
1. >50% of hashpower will not cooperate to rewrite history
2. the economic majority will not cooperate to reinterpret history
3. enough people believe in the illusion of artificial scarcity to give
it real value
Given that the above hold, from there up the system operates completely
trustlessly, with predictable security parameters. (Of course a block
isn't a guarantee of anything, but I know the probability that you can
cause a re-org from depth N with X% hashpower, which allows me to reason
about security.)
Now, some people on this thread might point to the above 3 points and
say "that isn't really a trustless system, it's a democratic system."
And then advocate that we can do without assumption 2, replacing it with:
2. the economic majority will not cooperate to reinterpret history
against any good guys, only against bad guys; "please trust their good
judgement."
That moves us away from a pure trustless system built upon a small
democratic foundation (as something of a necessary evil in an imperfect
world where humans run our computers and use our system) and toward a
"democratic system".
You don't have to agree, but I hope you can understand the point I'm
making :-) It's a fundamental shift in the nature of the system, and to
some people a violation of the social contract. Definitely not splitting
hairs.
I feel I've now consumed rather more bytes of everyone's inboxes than I
ought to have with this topic. I appreciate you and Mike taking the time
to reply to a newbie/lurker.
-Gareth
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 555 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140427/421557d1/attachment.sig>

2023-06-07 15:19:38

- reply

📅 Original date posted:2014-04-26
📝 Original message:On 26/04/14 01:28, Mike Hearn wrote:
> When you have a *bitcoin* TXn buried under 100 blocks you can be damn
>
> sure that money is yours - but only because the rules for interpreting
> data in the blockchain are publicly documented and (hopefully)
> immutable. If they're mutable then the PoW alone gives me no confidence
> that the money is really mine, and we're left with a much less useful
> system. This should be more sacred than the 21m limit.
>
>
> Well, I think we should avoid the term "sacred" - nothing is sacred
> because we're not building a religion here, we're engineering a tool.
Are you sure there isn't room for just a touch of "religion"? :) As you
state below, all that protects my money from confiscation is strong
group consensus that it's mine - "a social rule, not a mathematical one."
Everything ultimately balances on that. People being a little bit
"religious" about following the protocol faithfully are the linchpin of
Bitcoin security, not PoW.
> Consider a world in which 1 satoshi is too valuable to represent some
> kinds of transactions, so those transactions stop happening even though
> we all agree they're useful. The obvious solution is to change the rules
> so there can be 210 million coins and 10x everyones UTXOs at some
> pre-agreed flag day. We probably wouldn't phrase it like that, it's
> easier for people to imagine what's happening if it's phrased as "adding
> more places after the decimal point" or something, but at the protocol
> level coins are represented using integers, so it'd have to be
> implemented as a multiply.
Agree.
> Would this be a violation of the social contract? A violation of all
> that is sacred? I don't think so, it'd just be sensible engineering and
> there'd be strong consensus for that exactly because 21 million /is/ so
> arbitrary. If all balances and prices multiply 100-fold overnight, no
> wealth is reallocated which would be the /actual/ violation of the
> social contract: we just get more resolution for setting prices.
Wholeheartedly agree. "21 million" is just shorthand for the
preservation of artificial scarcity. No rational person could argue that
what you described violates the social contract.
I do see what you're driving at - that there exists a situation where it
would be justified to change the interpretation of data in existing blocks.
But, please consider: if I controlled a single UTXO worth 1% of the
total money supply before your change, the network would still recognise
that I control a single UTXO worth 1% of the total money supply after
your change. So you haven't really changed the interpretation of
existing blocks at all there. It's just semantics :)
Contrast this with invalidating a coinbase before maturity, which
clearly has a very real impact. At the point the vote passes, you're ***
sidestepping the PoW mechanism and rewriting the meaning of an existing,
validated block ***.
> So. The thing that protects your money from confiscation is not proof of
> work. PoW is just a database synchronisation mechanism. The thing that
> protects your money from confiscation is a strong group consensus that
> theft is bad. But that's a social rule, not a mathematical rule.
Agree. That's my whole point :)
I recognise my security is in the hands of the users (the economic
majority.) Tomorrow they could all decide to patch their nodes to
reallocate my UTXOs, and there's not a damn thing I could do about it,
PoW and private keys notwithstanding. I must simply trust that they will
not do this.
So we can have:
1. "Neutral Bitcoin", where everyone is committed to prevention of theft
by following a simple set of mathematical rules which treat all
validated blocks as equal.
Or:
2. "Political Bitcoin", where everyone is committed to prevention of
theft based on human judgements, and the contents of some validated
blocks are more equal than others.
I recognise that the latter allows for a lot of flexibility in combating
fraud, but with (substantial) due respect, it isn't Bitcoin.
-Gareth
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 555 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140426/c5fcc01b/attachment.sig>

2023-06-07 15:19:37

- reply

📅 Original date posted:2014-04-25
📝 Original message:On 25/04/14 20:17, Mike Hearn wrote:
> Proving that you can convince the economic majority that the
>
> interpretation of existing blocks is in any way up for grabs would set a
> dangerous precedent, and shake some people's faith in Bitcoin's overall
> robustness and security (well, mine anyway.)
>
>
> Hmm, then I think your faith needs to be shaken. Bitcoin is money, and
> money is a purely artificial social construct. The interpretation of
> what a bitcoin means, or what a dollar means, has always been and always
> will be a human decision taken in order to achieve some socially useful
> goal.
My argument does not concern what a bitcoin means, just what data in the
blockchain means. People are free to value an individual bitcoin however
they like. But it's useful if we all agree on a standard that defines
who owns them - ie. the protocol as described in Satoshi's whitepaper. I
recognise that your ability to provide a valid scriptSig for /any
existing UTXO in the blockchain/ as proof of your ownership of the
corresponding bitcoin. You want to pick and choose which UTXO (well,
coinbase; same diff) you consider valid and spendable /after they've
become part of the blockchain/, regardless of the fact they're buried
under PoW.
As an illustration, consider Counterparty - an altcoin whose TXns are
embedded as unvalidated data in the bitcoin blockchain. A lot of people
imagine that an XCP transaction buried under 100 blocks and a BTC
transaction buried under the same 100 blocks are equally secure. You
tell me: are they? It's the same PoW chain after all.
Hell no they're not! The way Counterparty interprets that data in the
blockchain is anything but stable or well documented. On more than one
occasion they've gone "whoops, found a bug that caused some transactions
to occur that we don't consider valid - we'll just fix that." A suddenly
the reference client doesn't consider the XCP in your wallet valid
anymore - they just magically disappear - because the parent of the TXn
that paid you was actually invalid. Nobody rewrote history via PoW; they
simply tweaked their interpretation of the existing history.
When you have a *bitcoin* TXn buried under 100 blocks you can be damn
sure that money is yours - but only because the rules for interpreting
data in the blockchain are publicly documented and (hopefully)
immutable. If they're mutable then the PoW alone gives me no confidence
that the money is really mine, and we're left with a much less useful
system. This should be more sacred than the 21m limit.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 555 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140425/e6f0b788/attachment.sig>

2023-06-07 15:19:37

- reply

📅 Original date posted:2014-04-25
📝 Original message:On 25/04/14 00:28, Mike Hearn wrote:
> Why are we here? We are here because we were brought together by shared
> goals.
>
> What are those goals? They were defined at the start of the project by
> the creator of the project.
>
> Why do we issue 21 million coins and not 42? Because 21 million is the
> goal everyone signed up for.
Mike: the blockchain is a public document, with a very public and well
defined interpretation, which we've all signed up for too.
What's the point of piling PoW on top of some data to make it difficult
to modify if the interpretation itself is open to modification?
There is an important distinction to draw between a hard fork via a
change in block validation rules, and a hard fork via a change in the
/interpretation of the blockchain itself/.
Bitcoin validates data /before/ it makes it into a block; we can all be
confident that, short of a reorg, /if it's in a block, it's the law/. As
much as the 21m cap is the law anyway.
Proving that you can convince the economic majority that the
interpretation of existing blocks is in any way up for grabs would set a
dangerous precedent, and shake some people's faith in Bitcoin's overall
robustness and security (well, mine anyway.)
My 2 bits.
-Gareth
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 555 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140425/864fe1bb/attachment.sig>