Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee

2015-06-20 Thread justusranvier
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 2015-06-20 19:19, Eric Lombrozo wrote:
 On Jun 20, 2015, at 4:37 PM, justusranv...@riseup.net wrote:
 
 Signed PGP part
 On 2015-06-20 18:20, Jorge Timón wrote:
  On Fri, Jun 19, 2015 at 6:42 PM, Eric Lombrozo elombr...@gmail.com
  wrote:
  If we want a non-repudiation mechanism in the protocol, we should
  explicitly define one rather than relying on “prima facie”
  assumptions. Otherwise, I would recommend not relying on the existence
  of a signed transaction as proof of intent to pay…
 
  Non-repudiation can be built on top of the payment protocol layer.
 
 
 Non-repudiation is an intrinsic property of the ECDSA signatures which
 Bitcoin uses - it's not a feature that needs to be built.
 
 There's no way to accidentally sign a transaction and accidentally
 announce it publicly. There is no form of third-party error that can
 result in a payee receiving an erroneous contract.
 
 
 
 Justus,
 
 We don’t even have a concept of identity in the Bitcoin protocol, let
 alone non-repudiation. What good is non-repudiation if there’s no way
 to even associate a signature with a legal entity?
 
 Sure, we could use the ECDSA signatures in transactions as part of a
 non-repudiation scheme - but the recipient would have to also have a
 means to establish the identity of the sender and associate it with
 the the transaction.
 
 
 Furthermore, in light of the fact that there *are* fully legitimate
 use cases for sending conflicting transactions…and the fact that
 determination of intent isn’t always entirely clear…we should refrain
 from attaching any further significance transaction signatures other
 than that “the sender was willing to have it included in the
 blockchain if a miner were to have seen it and accepted it…but perhaps
 the sender would have changed their mind before it actually did get
 accepted.”

Bitcoin has no concept of identity, but in any type of commercial 
transaction the parties involved must know some minimal amount of 
identity information in order to transact at all.

Except for some identifiable special cases, I think a payee is perfectly 
justified in treating a double spend of a payment sent to them as part 
of a commercial transaction as a fraud attempt and employing whatever 
non-Bitcoin recourse mechanisms, if any, they have access to.

- From the perspective of the network, the obviously correct action for 
any node or miner is to relay the first version of any transaction they 
see. The primary purpose of mining is to resolve this 
otherwise-unresolvable problem of determining which transaction among a 
set of conflicting transactions happened first.

If a node or miner wants to deviate from the obviously correct 
behaviour, and if they want to avoid harming the value of the network, 
they should be particularly careful to make sure their deviation from 
first seen doesn't introduce harmful unintended side effects, like 
making fraud easier.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJVhgTgAAoJECpf2nDq2eYjkksQAJyRVhT2vNQUqlOfH9Z/9EeT
LkUm8eg3f1i3xhJVxtLGVJkRmMYmuNtH0lIsH/B3iED732oZSzhwM1F5ky948Mw7
FFG65iUTrXVup9eKZuD7T3/FaQHfC5YME36F4UvEtSUcRDUKmongRGuuw7sNv617
APl3MDwZ8tVWaDb7yZ251is6Fx1l3b6tR4tHUzyIWPyIOuXOsyUaoS1cYJ00YcI5
WIzIXIlRDNpvpIXv4NFtr0BH6BmTCCZOJH3X9Hmtxqrg/dlnfnmc1pZgAyqRXj1d
5of7dYwb+bhHpU9TvcDYprN55Kmida2gTZewfr33rTXcVyjhs5N3bmIRIRrPltMA
fFqlKJ7Fo4ldyJ4OEK6upuFHwmQRNL7qr/ODmYg83rJj3BdTzXsJ1l3BRAUBS+cm
gc8Q3urxmVyspht+U64GO+ieLA9xb9izFMa+GL8nag0VuHc5J7XDjfzXBT8VK5be
646AZ0tFULNLOBWEJuBRbCRUs90YK2ePpGnAwiZ7HuwHMAC333FYiBuRxgwgn+xv
hHMlQWTtrl0zJrxD+pcb5axC7zQdVHVeyNJDi4RF1Wau2NX/itHcUqRr75N8/Si+
GPF8JSnvLlplEsEMBAtbKvg4dn1AOEuJpXtDYrWrzZDs+/wwz5PfQ2oCZ3YRHNx2
po6di9uOSlLq0BJJfSrM
=HbNG
-END PGP SIGNATURE-

--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee

2015-06-19 Thread justusranvier
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 2015-06-19 15:11, Peter Todd wrote:
 If you ask me to pay you 1BTC at address A and I create tx1 that pays
 1BTC to A1 and 2BTC of chain to C, what's wrong with me creating tx2
 that still pays 1BTC to A, but now only pays 1.999BTC to C? I'm not
 defrauding you, I'm just reducing the value of my change address to pay
 a higher fee. Similarly if I now need to pay Bob 0.5BTC, I can create
 tx3 paying 1BTC to A, 0.5BTC to B, and 1.498BTC to C.
 
 Yet from the point of view of an external observer they have no idea 
 why
 the transaction outputs reduced in size, nor any way of knowing if 
 fraud
 did or did not occur.

If there are two transactions which spend the same inputs, and each 
transaction has completely different output scripts, then this is prima 
facie fraudulent. https://en.wikipedia.org/wiki/Prima_facie

If the two transactions have identical output scripts, and one output is 
reduced in value to increase the transaction fee, that has the 
appearance of honest dealing. There is a possibility that the payer has 
chose to under-pay their payee in order to over-pay the miner, but 
that's not what a reasonable observer would assume at first glance.

Adding outputs to a transaction, while keeping all the existing outputs 
exactly how they are is another way of increasing the transaction fee of 
a transaction and is prima facie non-fraudulent.

Note that child-pays-for-parent has none of this ambiguity.

 What do you think of Bitcoin XT then? It relays double-spends, which
 makes it much easier to get double-spends to miners than before. In
 particular you see a lot of zero-fee transactions being replaced by
 fee-paying transactions, relayed through Bitcoin XT nodes and then
 mined. Is that encouraging fraud?

I haven't closely looked into the features of Bitcoin XT because I'm 
hoping that it never becomes relevant. I do want to see a heterogenous 
implementation network develop, but Bitcoin XT doesn't really count 
since it's a derivative of the Bitcoin Core codebase.

In general, I think every signed Bitcoin transaction sent between 
different parties is part of a valid, enforceable contract (using common 
law definitions which predate any particular legal jurisdiction). 
Handling contracts and money is Serious Business and so the decision of 
how software should respond to double spends should not be made 
frivolously.

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJVhDcpAAoJECpf2nDq2eYj23gP/ja9zqWZBoI/EfTJM0ZDVVY1
7lNwPJrAhO7oKQOKDrqhimA0TPRkoU0rCoYXSUEWn5X8ZIFlz9SQnGwXjIxt7PfG
yZTxF+vJbFCDifNcUlF7DRs07cavEFM9AOutYi8PyVg0LoV5+0VMhhWT4Kc5vnlZ
4Tw91r1lvtI9MCif+KFpida/PnPlhvIfjASEuaK+vYx3ro1ovSUesh558xZmCZ9A
Jfs+EwXBrxDO0zC0fatnaoRMkYQN7i/Dq1PFis7OHcZYBaQwgQTUoF8/wASvr8fQ
dPXJNzhgpYYXeu4IsYH/Of9HkEw+N+/0DEW07asJJ5OIgQmcyoGn+ph8QzrPqG5m
Rgb9BAmpqfCX+KrG6VDxU7xHLebwPhrPoYMIppvf77xhB2mV8c7Xky16Y/1tmxcH
NLOL/WQelNBqCvx2+6c9yDJsJoY12Z0n1tdbIfp3m65xcFzqHPFPtTpsNl0p/gX7
xOMSEUdSVyjvsJjXxWOG3B06+dVRqjS0Pr9ERjjviqx40XVpg4Q0b6y+LL0ZVweE
vs8ECN4y3vB7Qg2swYryVA7kNBh6GwCs7pMCh0DFw1mynGKndCKD+cPh8r3taP1u
8SlrKaD33schk4x70kxbtUzU+C7Yb5187Ct4U5kmsXhz1sypu4ebFPuWbJYG/Sjl
uEW4Vcn+HxlNI/rhxBw4
=odRL
-END PGP SIGNATURE-


--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee

2015-06-19 Thread justusranvier
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 2015-06-19 10:39, Peter Todd wrote:

 Yesterday F2Pool, currently the largest pool with 21% of the hashing
 power, enabled full replace-by-fee (RBF) support after discussions 
with
 me. This means that transactions that F2Pool has will be replaced if 
a
 conflicting transaction pays a higher fee. There are no requirements 
for
 the replacement transaction to pay addresses that were paid by the
 previous transaction.


Intentional fraud is a bad thing to add to a financial protocol.

A user who creates conflicting transactions, one that pays someone else 
and another which does not pay them, and broadcasts both of them, has 
just self-incriminated themselves by producing prima facie evidence of 
fraud.

It may be the case that since Bitcoin spans multiple legal jurisdictions 
and can be use anonymously that the victims of such fraud can not rely 
on legal recourse, and it may also be the case that proof of work is how 
Bitcoin deals with the aforementioned factors, but regardless 
un-prosecutable fraud is still fraud and anyone who encourages it should 
be recognied as a bad actors.

Committing vandalism and encouraging fraud to prove a point may be 
something the network can't stop on a technical level, but there's no 
reason not to call it out for what it is.

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJVhCsXAAoJECpf2nDq2eYjA08P/ApDFcIGws55TsgDFxPhDpN+
Iq9a06mPbXVjUfRxP5ZwmJuiM+XzHQ4QL3C2BH0OETatIV+bh7GP2mGHPcUAISYt
1j4TKhurnC+mqN+YAsiI5hQsws8DvPYXBTYYn0savaJTbq6/Q77+xvfRgNxofcPW
EHpnl/5wcmYGgp3mVyStGJ+qIP17yywzCLnSA3WEPaZG/9/FPrIq3Ptw2+RHod79
nzDiFBiKLK8E5NPbdbXS+gkjkkBA/QeCzZObpMOeWMriu/PIifVi8KssLSznnEwx
r7hiv6ISW47BTzkRbjxmXmGep3wfl8MjH7BZq3g0uyiApMdmjohIJ2lyuvOXdh7s
47+4r2xA8gG+z0aQTmCx5TS75T0Hnj3I78ZtCVr31Ip2OLbNI1mQ2gPR2zaoZkUZ
atp2XCssHDlY2s30k5hAnIHxuN6CkyGkZCECSuv46Z3ok6ll/nIP80qB7BBzVlP1
xfSOPZh57J31U8PxZBZcwgdRg+HBiExvg484grE+h18izxcrjNfPRSWP4+7nEZtK
LN7JL7YcmhVfhqKTSd6+C4bD2LsKsrcMiUhH1xHkD/hzAxc7egL6lgYTHJjU+yPu
BTIh0VHJxBgroHB45Vq6loa4B3l4ZCl4Ykw8Opm7NJIfueJ0l0ySyJXi6ix4bjVf
ZRF0Ot9RP0M0fHEwOpT6
=s0w/
-END PGP SIGNATURE-


--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee

2015-06-19 Thread justusranvier
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 2015-06-19 16:36, Matt Whitlock wrote:
 On Friday, 19 June 2015, at 3:53 pm, justusranv...@riseup.net wrote:
 I'd also like to note that prima facie doesn't mean always, it 
 means
 that the default assumption, unless proven otherwise.
 
 Why would you automatically assume fraud by default? Shouldn't the
 null hypothesis be the default? Without any information one way or
 another, you ought to make *no assumption* about the fraudulence or
 non-fraudulence of any given double-spend.

If we have ECDSA proof that an entity intentionally made and publicly 
announced incompatible promises regarding the disposition of particular 
Bitcoins under their control, then why shouldn't that be assumed to be a 
fraud attempt unless shown otherwise?

There are ways of achiving transaction fee adjustment after broadcast 
that do not present the appearance of, or opportunity for, fraud. If 
those options are available and the user chooses not to use them in 
favor of the option that does, that makes bad intentions even more 
probable.

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJVhEasAAoJECpf2nDq2eYjcwIP/25yoRpNvZkkdFfYiBKaiL/g
XRH8iFAyM5q3/75sA23vD/fzCNGIRRWYyp8PWk+23NF1gdsgVU6gFNNCUmDbjANv
nWTt2Bd926St24jcU+OxMewSGlxpenDSFDNQVtxhNFKst6hoPatwK1Zfa0Eq7/Qw
+r0H2Pse1ulrN4P1n5xnrYMq2w/GF3zinNZbrn2KOZCnsDa8lKlP8y9eNFHBJ//Z
wDrOcfZ1WLhf5/5xlV1NiH0tdxzABilH0ITimm2LCKbj3JcSJayZlyu4n3NypE0E
cVFeYpBaVZW9wuKUv/va5fzcyWDFPAo+OrR2B3siAb8nfY1jONXNhuV3yZ76pzMr
j39lvuSpoTbLobnEWMCJQ5bI/ngbhatT57gqMfF92sO0YjMe/gi/iU6urR9fi5Gz
3Ov6QA78vxzy/YduFjkc/1FV2dNdbGJtq6b0stmz5TtM1uljeGUoj6JZ8kOJ0EXn
857KFAqEd3hG9eYtBdFQcYeV2ShndALBQE0k3cqQvV6XYdHwHuTY15i1nq+u91MZ
VwsR1M69PrDX5Ps6qo1F6QYJA/fA4fyOZ9dwIvh+cgtu4wBptr/NOpL3XH0kE2+G
b2FRGOwdb2KlejIXSL9p4mfJTX9lmk4twbZe2Spjiy4FinOUyzxEobNoUTMcFCU7
Zu2i5yjMlJzrDB8yXz/N
=xtXD
-END PGP SIGNATURE-


--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee

2015-06-19 Thread justusranvier
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 2015-06-19 16:42, Eric Lombrozo wrote:
 If we want a non-repudiation mechanism in the protocol, we should
 explicitly define one rather than relying on “prima facie”
 assumptions. Otherwise, I would recommend not relying on the existence
 of a signed transaction as proof of intent to pay…

Again, I'm not talking about any changes to the protocol. The mining 
mechanism in the Bitcoin protocol is the fallback method of resolving 
fraud that isn't prevented or resolved via other mechanisms.

There are plenty of other ways economic actors resolve their 
disagreements other than blockchain adjudication. Sometimes when both 
parties are identified and reside in the same legal jurisdiction, 
contract violations and fraud can be adjudicated in courts. In some 
situations, the parties involved may have access to private dispute 
resolution techniques.

Sometimes the stakeholders in the network act to preserve the long term 
value of their investments, even if it means passing short-term profits. 
The more of those stakeholders there are in Bitcoin, the more effective 
it is to make the case for choices that are long-term beneficial.

The degree to which anyone should rely on a signed transaction as 
assurance of future payment is not a question with a universal answer. 
It depends on the particular details of the situation, and the parties 
involved, and their own risk tolerances and time preferences. There's no 
right answer for everyone, which is why let's break zeroconf because 
*I* don't think it's safe enough is a kind of vandalism.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJVhEkhAAoJECpf2nDq2eYj8qAP/0qYP7FJDjke1qNARGkySjC5
8fSuefu8bus/O2fNYsvPf0OcHeqepLUtQ/hgTml5AHaF1Fa9iZopVr8nZv0NFMuF
sv9RfkBKvnnrLWre3e/kQIdKzdMXompEsDwGfIeM3qvVV9AD3mKrz/YNmjs60+hU
rEdLCX8xw3ZvF3CGOzE1KnOMbADEd7i3E/Pm1n7pLVdRAg2CIU+w6mjErgucSdvB
kQ9SNAVQngjhMJyVbxsQh/+/xgecdqeZ07aaGsLhiw6zML2Tz8KMhrjJ9xw9+7h0
Gze+JdqxpgH4QrvD8KMDnlZjM+cWDUGyoVfsRvrVvPdW6kejU1r1B5Pf6dJg9TwZ
kK48RJFdd2rpAkz/kAbvQtoNMxSxhm2gKKFLEMi7g8MZUiGa/Rxj0tWL7OL9SA1U
VfpUzgAovoat9lBQM92T5vcS6kfhiNgAmF24ULGGYIhts77Ae6h8Fl3TECtnR0dM
1U1yio4Im1TfUDfjqNSK+ZjVpzkQli0R057y6XzI9HWkSYo94WyjNVoUlUozuAam
/2+tUMTrMYPeApRv+1nv13InYO8RZiFqs0E4w4TmB5V4Xt6uGUz4Olioyuo0NqMO
lBZwa1ZWKw4fLgHHDu9FhTEOXsOcX5W0gEgcoqMlzTzyoapekk9Esd0pAFLYxYMY
YQyAWtWUA4JBbgLxlB8Y
=x8eh
-END PGP SIGNATURE-


--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee

2015-06-19 Thread justusranvier
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 2015-06-19 15:37, Eric Lombrozo wrote:
 OK, a few things here:
 
 The Bitcoin network was designed (or should be designed) with the
 requirement that it can withstand deliberate double-spend attacks that
 can come from anywhere at any time…and relaxing this assumption
 without adequately assessing the risk (i.e. I’ve never been hacked
 before so I can assume it’s safe) is extremely dangerous at best and
 just horrid security practice at worst. Your users might not thank you
 for not getting hacked - but they surely will not like it when you DO
 get hacked…and lack a proper recovery plan.
 
 Furthermore, the protocol itself makes no assumptions regarding the
 intentions behind someone signing two conflicting transactions. There
 are many potential use cases where doing so could make a lot of sense.
 Had the protocol been designed along the lines of, say,
 tendermint…where signing multiple conflicting blocks results in loss
 of one’s funds…then the protocol itself disincentivizes the behavior
 without requiring any sort of altruistic, moralistic assumptions. That
 would also mean we’d need a different mechanism for the use cases that
 things like RBF address.
 
 Thirdly, taken to the extreme, the viewpoint of “signing a conflicting
 transaction is fraud and vandalism” means that if for whatever reason
 you attempt to propagate a transaction and nobody mines it for a very
 long time, you’re not entitled to immediately reclaim those funds…they
 must remain in limbo forever.

I'm not talking about changing the protocol - I'm talking about the 
business relationships between users of Bitcoin.

I would expect a payment processor to inform the merchants of relevant 
double spends that it observes on the network, even if the payment is 
actually successful, so that the merchant can decide for themselves 
whether or not to pursue it out of band.

Mining is a kind of technical fallback that allows the network to 
resolve human misbehavior without human intervention. If nobody ever 
attempted to make a fraudulent payment, we wouldn't need mining at all 
because the signed transaction itself is proof of intention to pay. That 
it exists doesn't suddenly make fraud less fraudulent and mean that 
users who are in a position to pursue out of band recourse shouldn't do 
so.

I agree that there are valid reasons for replacing transactions in the 
mempool, I just think they should be implemented in a way that doesn't 
facilitate fraud.

I'd also like to note that prima facie doesn't mean always, it means 
that the default assumption, unless proven otherwise.

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJVhDqcAAoJECpf2nDq2eYjX/UP/RlVIGqzwvdKftFW8kRW1+Dk
3befE2vEIEWFAShNt0pk7/Isqk7prRWQDKP+VNZSJfaoyE3akOe7s3OPWuevVRqM
Y1N658hYnG6NPebkyp5zUQkjT3mXVxOo9Fw9k7JyHgkWaDcwx330z2n6yztleodq
7hlKdW6sZrgqHw+DoF0Zal3QPN0WYm0XAno3uy71RXOs5cAoUxViuVzWHY0oReTQ
uggTggT1A5acmyOM7v65h9Cb2AKcLvHKfSEIwVQbHxYMOT+3GIJOXPKAluh8MjB3
oWg8ERy5dEEHu5kF/MLPQMg5yVQACuQmO2dlmtRoOs3mUQQj+q7dEil/dZMIp0f+
unDKIwLhXMa0sZ+63123UOgaKGZkF7afed3ueniJWQM80VS0WoZvZYhQadT/sCED
Ntfxifi1ZqCiKFeshyN9z7jDC8QEJ3N176Kr/wX76h/vvnPYicMEcfRgSE8EGd10
+oRQQpYzb69WPSFRhhrR3yG9Dev1JfzNPEaIKKYerDk9Vo3OnQ3VaaqBNZwBDo46
4r3O5orFES/ZxMdzWE1cWp99n4T4L6KxdZXmfQSYHehUJBnt62vKuEk9X/Li2ZWo
i3dr3yxx8xhKGGjsSjG03arz70bkXE7SvrICPOs9OEAdGlJI2liLrSWzYU9BbTle
eWvElyVQJsJHgAU8ygvn
=77NP
-END PGP SIGNATURE-


--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee

2015-06-19 Thread justusranvier
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 2015-06-19 17:50, Jeff Garzik wrote:
 No.  You cannot know which is the 'right' or wrong transaction.  One tx 
 has
 obvious nSequence adjustments, the other - the refund transaction - may 
 not.

I'm still not seeing a case where a node could see conflicting 
transactions on the network as part of a micropayment channel, and not 
know it was observing the resolution of a channel rather than a likely 
retail double spend.

If both transactions have been broadcast, then one of the conflicting 
members of the set will have nSequence adjustments.

Maybe a clever griefer could try to make their retail double spend look 
like a micropayment channel, but it seems like they'd be missing the 
other identifiable markers of that protocol.

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJVhFhqAAoJECpf2nDq2eYjWtgP/2ir11TUfxoIIzK9t0groKY3
yMR32HP3caDLKdc5ML41jf0l0cp7a54sFPuRE+Am8rkg9ogcf6fho/hCwLnhhNb4
YYBqJ2pzqCU1uN8jwPYSwSw3AO+F+hPE8gcm7lKD297a1k9xpYayAFjChJowoyNT
Wuq9YDkakQeSjV1aCiRHuXNxqnnbymf9xHEiB0buVnSgnyXrgZNCnefAo8DeXYqi
FTSceakNwdkklddK5ObNNK9ZoLpjHhX6hZwRiXsOoG+WUzXhLQ+BsyIFzsCKxQk1
cXjTvLn+Ub9FasRCK5KXMBkkPa1U5JLs1nTn6eTbPyroTs10WLkXWjIpZHrkf7ZW
9RsxoKIRaJur8gbYd6BMvV5rgkfGdb6j24pVNxFF2t89SLo44H0NvqE6koNzgubG
4DyXZ+UlzxzwRVBNDeF4pdlKZGsz2ycvQPuNHRoaZY2IsieMBN/5HEqGNOmXsvKf
tCg1SInO/FkE4njCxSW0R31s2KXCpgVCuq3qmoIKZobDdx7AC8GnpY1rdxUGpVoy
USJwZ2IOgtNfl/rBtOpkp/BaUCmCYOiUj13/ycDrqWvnM4TmiDdzJNEZNfez5UQp
Uvgvstoo88sewv9hGsuBWX0nC+ze/m43ZRReFhQDsypEaOw6pL2LSG9dD3tzulax
TrbPXPlN55NarQ3nmPIW
=Hj0x
-END PGP SIGNATURE-


--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers

2015-06-18 Thread justusranvier
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 2015-06-18 16:28, Jeff Garzik wrote:
 This is an engineering list.  The quote precisely describes how the 
 bitcoin
 consensus system functions.
 
 Users' choice is largely binary:  Follow the rules, or bitcoin software
 ignores you.


Software engineers should understand that they have a binary choice: 
produce the software that your customers want, or the world will ignore 
your software.

There is *no inherent value* to Bitcoin's software rules. The only value 
that is exists is that produced by the individuals who voluntarily 
choose to run the software.

Failing to account for all design requirements is bad engineering. 
Nobody cares about the design features of a bridge to nowhere.

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJVgvoDAAoJECpf2nDq2eYj0h4P/0YaTsS963qpb63zvB6WlIPS
2lhCJ9FtAd3II5Et+5c/cisfJ9YI2OnM0y8nQpyB9NEOeueN1L1sLFcayE5aHASd
EgF7F81AhQD2iSIVwQNs2qAzrZNC2/Nx+nBzBDcrgZ6gRiPpQdsNLy2p0OuZdOgX
yG4xl6tKADB2kNi6tVPtZqUC300uQHvggtm+pexYilT0ojEbeVHCoDV40MNDZC2h
1kcdTnGU2SHJJqeZN2vChJCOMfhmK4JwKgoz7JRXe/GHkUUJKriE6Kb7SVczii9e
9qfcosbnR3gjATMoHFYuJX/nsUx52Q1LM9eQgvE8Ml+6Mim5bj2KCJFh7YISxSq9
FhDujfZFCRRQLPJCSkEUePxU/LS7lmoTZXYl3Zz1j9zbq4ncpRHpIFy9QX6iIqK6
Dursnge9ELQwB+H6HoosWRzxOZyo+oiGj17OngJvZYcvzrc2wjHbpZfVqSkmZepU
SfJZ64O7yjjXjITwhOc4XF2drzvhsjTsHH5BIwdbCn82SoCkJIwXraj7sxIundli
LUJBPiAE0csdmsvW/2kkxLsd9JwTw9lJ9Pf8fiqH3itgrkPkO5mf10DPPnay1SNk
Wnm1bAJ05WnKXSo0m0SzaFgZkdfFuhWR4fieSzhLpa+s/HHj18NZvJCmCBR6ic9G
0A+51wwSZnAdMIw7lwIb
=r4Co
-END PGP SIGNATURE-


--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] The Bitcoin Node Market

2015-06-16 Thread justusranvier
On 2015-06-16 07:55, Aaron Voisine wrote:
 Suppose a billion mobile phones wanted to run SPV wallets tomorrow. 
 Who
 would provide the nodes they would need connect to?
 
 The SPV wallet author would if they wanted their wallet to function.

How will the SPV wallet users pay for this service? With their money, or 
with their privacy?

--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] The Bitcoin Node Market

2015-06-15 Thread justusranvier
On 2015-06-16 03:49, Kevin Greene wrote:
 ​Hah, fair enough, there is no such thing as the right way to do
 anything. But I still think punishing users who use SPV wallets is ​a
 less-than-ideal way to incentive people to run full nodes. Right now 
 SPV is
 the best way that exists for mobile phones to participate in the 
 network in
 a decentralized way. This proposal makes the user experience for mobile
 wallets a little more confusing and annoying.

Suppose a billion mobile phones wanted to run SPV wallets tomorrow. Who 
would provide the nodes they would need connect to? The decentralization 
fairy?

There's absolutely no reason that paying for connectivity would be any 
more confusing or annoying than transaction fees are.

If some full nodes in the network started offering paid connection 
slots, that would just mean that users who checked the pay subscription 
fee box in their wallet configuration would have an easier time 
connecting than the users who did't, just like how your transaction 
might eventually get mined without a fee but paying one makes it faster 
and more probable.

--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development