Re: [bitcoin-dev] Currency/exchange rate information API

[Luke Dashjr via bitcoin-dev]

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 something that needs to be at a higher 
layer.

> Apart from that, my feeling is that it could be simplified. Is 
> longpolling useful?

I would think so, at least for Bitcoin since rates can change significantly in 
a short period of time (or can they anymore? I haven't really watched lately.)

> And is the historical rate thing really necessary for typical applications?

When displaying historical transactions, it doesn't really make sense to use 
the current market rate, but rather the market rate at the time the payment 
was made. While wallets might simply cache it with the transaction, it would 
be perhaps nicer if it could be automatically restored for seed-only 
recoveries. In any case, if a service/wallet doesn't want to provide/use 
historical information, it can simply not implement that part.

> If yes, the client should be allowed to decide on which time scale the
> data should be. (tick, min, hour, day, ...) That goes together with
> clearly defining the type field (something like low, high, open, close,
> but without flexibility). Think of a candle-stick chart basically.

How is the current draft insufficient for this?

> Also, pushing may be more appropriate for "current" rates than polling.
> Then no polling interval is necessary. On the other hand, this adds
> complexity in other places, e.g., state.

Pushing is what longpolling does.

Luke
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Currency/exchange rate information API

[Tim Ruffing via bitcoin-dev]

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 the attacker on the wire to make money...

Apart from that, my feeling is that it could be simplified. Is 
longpolling useful? And is the historical rate thing really necessary
for typical applications?

If yes, the client should be allowed to decide on which time scale the
data should be. (tick, min, hour, day, ...) That goes together with
clearly defining the type field (something like low, high, open, close,
but without flexibility). Think of a candle-stick chart basically.

Also, pushing may be more appropriate for "current" rates than polling.
Then no polling interval is necessary. On the other hand, this adds
complexity in other places, e.g., state.

Tim  

On Sat, 2017-03-04 at 08:27 +, Luke Dashjr via bitcoin-dev wrote:
> Investigating what it would take to add fiat currency information to
> Bitcoin 
> Knots, I noticed Electrum currently has many implementations, one for
> each 
> exchange rate provider, due to lack of a common format for such data.
> 
> Therefore, I put together an initial draft of a BIP that could
> standardise 
> this so wallets (or other software) and exchange rate providers can
> simply 
> interoperate without a lot of overhead reimplementing the same thing
> many 
> ways.
> 
> One thing I am unsure about, is that currently this draft requires
> using XBT 
> (as BTC) for Bitcoin amounts. It would seem nicer to use satoshis,
> but those 
> don't really have a pseudo-ISO currency code to fit in nicely...
> 
> Current draft here:
> https://github.com/luke-jr/bips/blob/bip-xchgrate/bip-xchgrate.me
> diawiki
> 
> Thoughts? Anything critical missing? Ways to make the interface
> better?
> 
> Luke
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Moving towards user activated soft fork activation

[Eric Voskuil via bitcoin-dev]

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 consensus is more 
secure in that it is more resistant to change (forks) than a system with a 
small consensus.

The fact that mining is highly centralized makes it relatively easy to enforce 
a fork via miner collaboration, and hard to do so without it.

So clearly the other option, as being discussed here, is to enforce a fork via 
the economy. Given the highly centralized nature of the economy, described 
below as "economic hubs", it is also relatively easy as well.

Independent of one's opinion on the merits of one fork or another, the state of 
centralization in Bitcoin is an area of great concern. If "we" can sit down 
with 75% of the economy and/or 90% of the hash power (which of course has been 
done) and negotiate a change to any rule, Bitcoin is a purely political money.

If "we" can do this, so can "they".

e

> On Mar 5, 2017, at 10:10 AM, David Vorick via bitcoin-dev 
>  wrote:
> 
> 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 success of the UASF depends entirely on the price. And actually, the 
> price is easy to manipulate. If you, as an economically active full node, 
> refuse to acknowledge the old chain and demand that incoming coins arrive 
> over the UASF chain. In doing so, you drive down the utility of the old chain 
> and drive up the utility of the new chain. This ultimately impacts the price.
> 
> I think it would be pretty easy to get high confidence of the success of a 
> UASF. Basically you need all the major economic hubs to agree to upgrade and 
> then exclusively accept UASF coins. I don't have a comprehensive list, but if 
> we could sign on 75% of the major exchanges and payment processors, and get 
> 75% of the wallets to upgrade, then the UASF would be very likely to 
> successfully obliterate the old rules, as miners would be unable to sell 
> their coins or pay their bills by stubbornly sticking to the old chain. It's 
> less risky than a hard fork by far, because there is zero risk of coin split 
> if the UASF has majority hashrate, which will follow majority economic value.
> 
> A serious proposal I think would get all the code ready and merged, but 
> without setting a flag day. Then we would get signatures from the major 
> institutions promising to use the software and saying that they are ready for 
> a flag day. After that, you release a patch with a flag day 12 months in the 
> future. People can upgrade immediately, and have a full year to transition.
> 
> That gives tons of time for people to upgrade, and tons of confidence that 
> the UASF will end up as the majority chain.
> 
> If we cannot get enough major exchanges, payment processors, and other 
> economic hubs to upgrade,  the flag day should remain upset, as the risk of 
> coin split will be non-zero.
> 
> I would suggest that a carefully executed UASF is much riskier than a soft 
> fork, but far, far less risky than a hard fork.
> 
> 
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Moving towards user activated soft fork activation

[Chris Belcher via bitcoin-dev]

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
forks. The situation between hard and soft forks is reversed.

In a fork between segwit-invalid and segwit-valid after a UASF, if the
segwit-valid chain ever ends up with more work then the segwit-invalid
chain will be annihilated in a big re-organization as
non-segwit-enforcing nodes move to the segwit-valid chain. The less-work
chain will simply cease to exist.

Only a miner that recodes their software can initiate such a fork,
because segwit transactions are non-standard and won't be relayed by
default.

A closer situation is the accidental fork created soon after the BIP66
soft fork. The fork lasted a few blocks and did not mine any
transactions except the coinbase. It was annihilated with a monetary
loss to any miner that took part.


Here is an argument for why chain fork is unlikely to last long or be
created by a rational self-interested miner, assuming the bitcoin
economic majority even slightly enforces the UASF.

Because the segwit-invalid coins can be annihilated in this way and
segwit-valid coins cannot, segwit-invalid coins are more risky to hold
as an asset, all else equal.

A more risky asset has a lower price, all else equal. Because investors
demand higher risk premiums for holding it and also short sellers may
sell down the price in the hopes of making a profit if it's value goes
to zero.

In cryptocurrencies like bitcoin, hashpower follows price. This is very
clear from historical trends and the underlying economic forces.

A lower-hashrate chain will eventually be overtaken in work by a
higher-hashrate chain.

Therefore, the segwit-invalid chain will be annihilated sooner or later
if the price of its coin is higher.

Of course as the old saying goes markets can stay irrational longer than
we can stay solvent, which is why I think UASF should only go ahead if
we're sure that a big part of the economic majority will enforce it.
This will make the value and liquidity of the segwit-invalid chain very
low and make the annihilating re-organization happen faster.
User-activated means it _must_ be done by the users of bitcoin.

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Unique node identifiers

[Btc Drak via bitcoin-dev]

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
fully validating nodes that participate in economic activity really matter.

As a side note, this should probably have started out as a bitcoin-discuss
post.

On Sat, Mar 4, 2017 at 4:04 PM, John Hardy via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> The discussion of UASF got me thinking about whether such a method might
> lead to sybil attacks, with new nodes created purely to inflate the node
> count for a particular implementation in an attempt at social engineering.
>
> I had an idea for an anonymous, opt-in, unique node identification
> mechanism to help counter this.
>
> This would give every node the opportunity to create a node
> ‘address’/unique identifier. This could even come in the form of a Bitcoin
> address.
>
> The node on first installation generates and backs up a private key. The
> corresponding public key becomes that node’s unique identifier. If the node
> switches to a new software version or a new IP, the identifier can remain
> constant if the node operator chooses.
>
> Asking a node for its identifier can be done by sending a message the
> command ‘identify’ and a challenge. The node can then respond with its
> unique identifier and a signature for the challenge to prove it. The node
> can also include what software it is running and sign this information so
> it can be verified as legitimate by third parties.
>
> Why would we do this?
>
> Well, it adds a small but very useful piece of data when compiling lists
> of active nodes.
>
> Any register of active nodes can have a record of when a node identifier
> was “first seen”, and how many IPs the same identifier has broadcast from.
> Also, crucially, we could see what software the node operator has been seen
> running historically.
>
> This information would make it easy to identify patterns. For example if a
> huge new group of nodes appeared on the network with no history for their
> identifier they could likely be dismissed as sybil attacks. If a huge
> number of nodes that had been reporting as Bitcoin Core for an extended
> period of time started switching to a rival implementation, this would add
> credibility but not certainty (keys could be traded), that the shift was
> more organic.
>
> This would be trivial to implement, is (to me?) non-controversial, and
> would give a way for a node to link itself to a pseudo-anonymous identity,
> but with the freedom to opt-out at any time.
>
> Keen to hear any thoughts?
>
> Thanks,
>
> John Hardy
>
> j...@seebitcoin.com
>
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] TXO commitments do not need a soft-fork to be useful

[praxeology_guy via bitcoin-dev]

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, because then we having all of the miners 
verifying the UTXO. Below I brainstorm on how to make this happen with my 
"Synchronization Checkpoints" idea.

I think if there were commitments, such would not be feasible without it being 
a commitment on the UTXO as it was N blocks in the past rather than the highest 
block's UTXO set... because just one little fork of height 1 would be a big 
waste of effort for the miners.

- Miners would put a commitment at the current Checkpoint Block that would be a 
hash of the full state of the UTXO at the previous Checkpoint Block.
- I'll point out that blocks are like "incremental diffs" to the UTXO state.

I was thinking that say if a miner and other nodes are OK with storing multiple 
copies/backups of the UTXO state then to make this work with high performance:
1. Maintain a DB table who's only purpose is to sort UTXO.txid concat 
UTXO.vout.index.
2. Some Wait for no Forks blocks after a CheckPoint Block is made, begin 
populating a new UTXO Checkpoint File that is a serialized sorted UTXO set.
3. Merkle tree or bittorrent style hash the UTXO Checkpoint File
4. Party!

Cheers,
Praxeology___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Unique node identifiers

[John Hardy via bitcoin-dev]

> 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 though. It was 
just an easy way to give third party node monitors like coin.dance and 
bitnodes.21.co a few more metrics.

That said, it would allow the creation of a 'nodepool', where each node could 
broadcast its latest status like a transaction, and every node has a register 
of active nodes. Like a mempool, but for nodes.

By leveraging the randomness of node identities, it could be that a 
deterministic subset of nodes randomly check that a new node status update is 
legitimate by querying the node directly (a small enough subset to not cause a 
DDOS). If a threshhold of those random checking nodes reports that the node 
either doesn't exist or is responding with conflicting information, this will 
become evident to the network and can be flagged.

This should paint a pretty accurate picture of the state of the network, and 
might also prove useful for developing lightning routing?


From: Marcel Jamin 
Sent: Sunday, March 5, 2017 6:29 AM
To: John Hardy; Bitcoin Protocol Discussion
Subject: Re: [bitcoin-dev] Unique node identifiers

> 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.

Even if included in a block, people could sell their aged IDs (if we were to 
rely on those for anything).

Also funding that ID address would might tie your economic activity (or even 
identity) to a node.

On 4 March 2017 at 17:04, John Hardy via bitcoin-dev 
>
 wrote:

The discussion of UASF got me thinking about whether such a method might lead 
to sybil attacks, with new nodes created purely to inflate the node count for a 
particular implementation in an attempt at social engineering.


I had an idea for an anonymous, opt-in, unique node identification mechanism to 
help counter this.


This would give every node the opportunity to create a node ‘address’/unique 
identifier. This could even come in the form of a Bitcoin address.


The node on first installation generates and backs up a private key. The 
corresponding public key becomes that node’s unique identifier. If the node 
switches to a new software version or a new IP, the identifier can remain 
constant if the node operator chooses.


Asking a node for its identifier can be done by sending a message the command 
‘identify’ and a challenge. The node can then respond with its unique 
identifier and a signature for the challenge to prove it. The node can also 
include what software it is running and sign this information so it can be 
verified as legitimate by third parties.


Why would we do this?


Well, it adds a small but very useful piece of data when compiling lists of 
active nodes.


Any register of active nodes can have a record of when a node identifier was 
“first seen”, and how many IPs the same identifier has broadcast from. Also, 
crucially, we could see what software the node operator has been seen running 
historically.


This information would make it easy to identify patterns. For example if a huge 
new group of nodes appeared on the network with no history for their identifier 
they could likely be dismissed as sybil attacks. If a huge number of nodes that 
had been reporting as Bitcoin Core for an extended period of time started 
switching to a rival implementation, this would add credibility but not 
certainty (keys could be traded), that the shift was more organic.


This would be trivial to implement, is (to me?) non-controversial, and would 
give a way for a node to link itself to a pseudo-anonymous identity, but with 
the freedom to opt-out at any time.


Keen to hear any thoughts?


Thanks,


John Hardy

j...@seebitcoin.com

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Unique node identifiers

[Marcel Jamin via bitcoin-dev]

> 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.

Even if included in a block, people could sell their aged IDs (if we were
to rely on those for anything).

Also funding that ID address would might tie your economic activity (or
even identity) to a node.

On 4 March 2017 at 17:04, John Hardy via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> The discussion of UASF got me thinking about whether such a method might
> lead to sybil attacks, with new nodes created purely to inflate the node
> count for a particular implementation in an attempt at social engineering.
>
> I had an idea for an anonymous, opt-in, unique node identification
> mechanism to help counter this.
>
> This would give every node the opportunity to create a node
> ‘address’/unique identifier. This could even come in the form of a Bitcoin
> address.
>
> The node on first installation generates and backs up a private key. The
> corresponding public key becomes that node’s unique identifier. If the node
> switches to a new software version or a new IP, the identifier can remain
> constant if the node operator chooses.
>
> Asking a node for its identifier can be done by sending a message the
> command ‘identify’ and a challenge. The node can then respond with its
> unique identifier and a signature for the challenge to prove it. The node
> can also include what software it is running and sign this information so
> it can be verified as legitimate by third parties.
>
> Why would we do this?
>
> Well, it adds a small but very useful piece of data when compiling lists
> of active nodes.
>
> Any register of active nodes can have a record of when a node identifier
> was “first seen”, and how many IPs the same identifier has broadcast from.
> Also, crucially, we could see what software the node operator has been seen
> running historically.
>
> This information would make it easy to identify patterns. For example if a
> huge new group of nodes appeared on the network with no history for their
> identifier they could likely be dismissed as sybil attacks. If a huge
> number of nodes that had been reporting as Bitcoin Core for an extended
> period of time started switching to a rival implementation, this would add
> credibility but not certainty (keys could be traded), that the shift was
> more organic.
>
> This would be trivial to implement, is (to me?) non-controversial, and
> would give a way for a node to link itself to a pseudo-anonymous identity,
> but with the freedom to opt-out at any time.
>
> Keen to hear any thoughts?
>
> Thanks,
>
> John Hardy
>
> j...@seebitcoin.com
>
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev