On Monday, March 06, 2017 5:37:24 AM Tim Ruffing via bitcoin-dev wrote:
> But ignoring this, the server should be authenticated at a
> minimum. Otherwise manipulating exchange rates seems to be a nice
> way for the attacker on the wire to make money...
HTTPS would be used for that. It's not someth
I'm not sure if a BIP is the right thing in that case, given that the
provided functionality is not special to Bitcoin and can be used in
other contexts as well.
But ignoring this, the server should be authenticated at a
minimum. Otherwise manipulating exchange rates seems to be a nice
way for th
>I also think that the UASF is a good idea. Hashrate follows coin price. If
the UASF has the higher coin price, the other chain will be annihilated. If
the UASF has a lower coin price, the user activated chain can still exist
(though their coins can be trivially stolen on the majority chain).
I do
There are two aspects of system security in Bitcoin, mining (hash power) and
payment validation (economy). The security of each is a function of its level
of decentralization. Another way to think of it is that a system with less
decentralization has a smaller community (consensus). A large cons
I also think that the UASF is a good idea. Hashrate follows coin price. If
the UASF has the higher coin price, the other chain will be annihilated. If
the UASF has a lower coin price, the user activated chain can still exist
(though their coins can be trivially stolen on the majority chain).
The s
I think UASF is a great idea for the reasons mentioned before that it
more closely matches the balance of powers in bitcoin, and that its much
more opt-in.
Many people are comparing an UASF fork with a hard fork. I disagree with
this view and I think there is a difference between the two kinds of
Nodes are by design not supposed to be identifiable in any way, including
persisting identities across IPs changes or when connecting over different
networks (e.g. clearnet/tor). Anything that makes Bitcoin less private is a
step backwards. Also absolute node count is pretty meaningless since only
Peter Todd & Eric Lombrozo,
I also think communicating the UTXO would be increadibly useful. I just made a
writeup called "Synchronization Checkpoints" on github.
"https://github.com/bitcoin/bitcoin/issues/9885"; This idea also doesn't use
commitments.
But... Commitments would be a plus, becau
> Wouldn't this actually *need* to be a bitcoin address that is included in a
> block
I think it being a bitcoin address probably makes the most sense. The address
could even be used for donations to incentivise identifier use.
I had not really envisaged this having any blockchain presence thou
> This could even come in the form of a Bitcoin address.
Wouldn't this actually *need* to be a bitcoin address that is included in a
block to get any real assurances about the age if this node id? Otherwise
malicous nodes could lie and claim to have seen a brand new node id years
ago already.
Eve
10 matches
Mail list logo
