Lawrence Nahum [ARCHIVE] / is on Nostr

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

Last Notes

2023-06-07 15:39:03

- reply

📅 Original date posted:2015-06-19
📝 Original message:Chun Wang <1240902 <at> gmail.com> writes:
> Hello. We recognize the problem. We will switch to FSS RBF soon. Thanks.
FSS RBF is better than no RBF but we think it is better to use full RBF.
We think Full RBF is better for a number of reasons:
-user experience
-efficiency
-cost
-code complexity
We think FSS RBF is great progress but ultimately less efficient and more
complicated to keep alive something that never worked properly.
And why would miner pick the option paying less when other miners run the
option paying more? It may be soon more than 1-5% of block reward.
A lot of users don't have multiple UTXO handy.
Full RBF is the best, second FSS RBF and we'd be looking into supporting
them both separately so that miners and users can pick whichever they
prefer.
If users only had one UTXO it makes sense to use Full RBF since there are no
other options.
Disclosure: GreenAddress always believed zero conf transactions are not
secure and that miners have the incentive to run FBF; this bias doesn't make
the above less true

2023-06-07 15:38:43

- reply

📅 Original date posted:2015-06-18
📝 Original message:Mike Hearn <mike <at> plan99.net> writes:
> It's the only way to keep a project making progress at a reasonable pace.
[SNIP]
If Bitcoin is managed with a linux kernel style dictator it would be
centralized (yet unlike linux, where people can fork without impacting others
in Bitcoin a hard fork puts at risks everyone's bitcoins) - I hope we all
agree there is no point in a centralized Bitcoin?
In addition and more importantly, it would put Gavin in tremendous dangers,
both from violent threats/blackmailing prospective as well as regulatory
prospective - how can you not see that?
I hope all this confrontation will be worth something in the end: to show
that Bitcoin can't be changed centrally and that it can't be changed without
consensus

2023-06-07 15:30:27

- reply

📅 Original date posted:2015-02-12
📝 Original message:Mike Hearn <mike <at> plan99.net> writes:
>
>
> I know you will ignore this as usual, but the entire replace-by-fee folly
is based on your fundamental misunderstanding of miner incentives.
I disagree, I think it is inevitable (but then of course I'm probably biased
and why wouldn't I disagree given I run a service that allows for zero
confirmation/double spend protection with third party trust.)
Fixing it now avoids having people build on top of very weak/broken
foundations (see Coinbase https://botbot.me/freenode/bitcoin-
wizards/msg/29818058/) which would cause bigger problems down the line.
One thing I don't understand from your position is how do you propose
handling transactions being stuck for days or longer because of low fees?
Even with floating fees you can have a sudden inflow of high fees
transactions taking over post broadcasting your transaction.
I also assume restricted replacement is very hard, especially from a UX point
of view and adds undue complexity

2023-06-07 15:22:51

- reply

📅 Original date posted:2014-06-16
📝 Original message:Mike Hearn <mike <at> plan99.net> writes:
> Sure. I buy this. Although the credit card market is a great example of
what we don't want: a stagnant duopoly of trusted third parties who
rampantly abuse their position. So I'd hope we see either (a) nobody really
caring about this BIP because Bitcoin gives good enough double spend
protection or (b) lots of anti-double-spend providers (hundreds seems fine).
Maybe hundreds, maybe less. I can imagine there would/could be local ones.
It's not the same as credit cards though: it's an open protocol with
explicit intent from all parties and no forced fees for normal transactions
- just for instant ones.
> No, I will never wait. Neither me nor the merchant wants to me to be
pointlessly hanging around for an hour. The alternative is to pay by credit
card or cash. Outside of experiments there is no such thing as a shop that
only accepts only Bitcoin and will require me to wait for a block because I
didn't use a TTP to guarantee anti-double spends.
I tend to agree but _today_ people are trying to use bitcoin and are waiting
and waiting ..
> So this seems like a fundamental problem to me: having the ability to say,
"here is a proof I won't double spend" is fine, but it doesn't achieve
anything if the merchant would have sold me the goods in return for a normal
Bitcoin tx anyway, which in practice they always will because this system
starts out from zero users and would have to work upwards. I especially will
never use this system if I have to pay for it - I'd much rather just put my
money into a wallet that can't generate these proofs and pay the sticker
price.
This is a cultural thing. In some places if you pay by cards you pay extra.
I think it may be good to support both models but I like better the
transparent one even if I'm going to admit that the least transparent one
may be more attractive as it fools consumers.
> Maybe what this BIP needs is an extra field that lets the merchant say, I
will give you a discount of X satoshis if you give me a no-double-spends
proof. In other words invert it: the sticker price is what normal Bitcoin
transactions cost, and then your wallet shows you the regular BIP70 price
minus the discount plus the third parties fee as what you finally pay. I
compare it to the sticker price the merchant is asking and if it's lower I'm
happy, and if it's higher my wallet would automatically avoid using the TTP
because I don't want to ever pay more, only less.
> The market would then figure out if the fees the TTP charges are worth the
lower losses due to double spending fraud.
I think this is worth discussing further. Would love also more input from
other people on this.

2023-06-07 15:22:50

- reply

📅 Original date posted:2014-06-16
📝 Original message:Mike Hearn <mike <at> plan99.net> writes:
[snip]
> Daniel is right that putting every possible provider in the Payment
message might not scale in a world where there are huge numbers of instant-
confirmation providers, but I'm hoping that we never have to scale to that
size, because if we did that'd rather imply that Bitcoin has become useless
for in-person payments without trusted third parties and avoiding that is
rather the whole point of the project :) So I'm OK with some theoretical
lack of scalability for now.
Hard to say for now. I like the current simplicity but if someone can come
up with some use case for other options we should discuss and investigate
them. I don't see more than a bunch of accepted payment methods anywhere I
ever been in my life, I don't see merchants trusting more than a handful of
third parties.
> A more scalable approach would be for the user to send the name and
signature of their "instant provider" every time and the merchant just
chooses whether to ignore it or not, but as Lawrence points out, this is
incompatible with the provider charging extra fees for "instantness". But
should we care? I'm trying to imagine what the purchasing experience is like
with optional paid-for third party anti-double-spend protection. Ultimately
it's the merchant who cares about this, not me, so why would I ever pay?
I think you are wrong here.
Just because up to date credit cards charged the merchant which in turn
charged you and the ordinary cash payer doesn't mean a newer and better
system can't be transparent from day one.
Ultimately you care because the alternative is to wait.
> It makes no sense for me to pay for double spend protection for the
merchant: after all, I'm honest.
It's quite simple, in a low amounts world people will probably accept zero
confs, just like occasionally people can walk out with a bag of crisps
without paying from a Pret in London. Guards would cost more than what
they'd save from thefts.
With higher amounts they will either not accept bitcoin unless instant
confirmed or they will make you wait if that's even feasible (unlikely in a
supermarket or petrol station but perfectly fine at the restaurant maybe).
> This is why it doesn't make sense for me to pay miners fees either, it's
the receiver who cares about confirmations, not the sender.
You care too: time and money, or just money if you want to use the old
simplification.
> So I wonder if a smarter design is that the user always submits the
details of their instantness provider and we just don't allow for optional
selection of instantness. I'm not sure that works, UX wise, so is having a
less scalable design to support it worthwhile?
We would not support that I think. Explicit is better than implicit.
We will charge for instant confirmation and wouldn't want the user charged
unless pre-agreed, especially if then they also have to wait because the
instant tx was not recognized as such.
Yeah we can charge the merchant that can then in turn charge you, we may as
well charge you and be transparent about it but also have deals with
merchant where they pay fixed amounts per month for unlimited tx and make it
free for their users.
Perhaps just like today people ask you which card you are going to use and
they may not accept Amex or Diners the same will go for instant and they,
the merchants, will just pick the instant provider from a touch screen
before allowing the payment in.

2023-06-07 15:22:46

- reply

📅 Original date posted:2014-06-16
📝 Original message:Mike Hearn <mike <at> plan99.net> writes:
> As long as miners stick to Satoshi's first seen rule, which is the
default, it's useful:
>
>
> https://bitcointalk.org/index.php?topic=423.msg3819#msg3819
>
>
>
>
> (this is the famous "snack machine" thread from 2010)
>
> If they decide to change to something like highest-fee-always-wins, then
they (again) centralise things by forcing all instant transactions to pay
GreenAddress and its competitors money - much though I like your product
Lawrence, let's hope they don't collectively lemming us all off a cliff by
doing that ;)
I assume we can't enforce to miners rules about which tx will go in and
which won't and therefore whether this will cause more or less double
spends.
I mean, you can try but I would rather have to option to pick an third party
instant provider explicitly than enforce bigger rules on mining which would
IMHO lead to implicit centralization.

2023-06-07 15:22:45

- reply

📅 Original date posted:2014-06-16
📝 Original message:Mike Hearn <mike <at> plan99.net> writes:
> Please see https://github.com/bitcoin/bitcoin/pull/3883 which implements
this exact scheme. It can solve some kinds of double spends (probably), but
others - like ones done by corrupt miners (see bitundo) - can't be solved
this way.
I read the comments on the PR. I mean no disrespect but this patch can't
prevent double spends minutes apart and a solution is as good as it's
weakest link.
It also seems to suffer from potential ddos and otherwise may provide a
false sense of security. I wouldn't call it a solution in sight just yet.
> Lawrence's motivation for this BIP is essentially to act as a backup in
case the Bitcoin native double spending protections end up being too weak to
be useful. It reintroduces a notion of centralised trust as a layer on top
of the Bitcoin protocol, but only for cases where the seller/recipient feels
it'd be useful. In this way it gives us slack: if someone is able to
reliably double spend and the merchants losses due to payment fraud go up,
we can fall back to TTPs for a while until someone finds a solution for
Bitcoin, or we just give up on the Bitcoin experiment, but hey - at least we
now have a better intermediary protocol than SWIFT
I wouldn't put it just like that. Sure, it's a backup to the double spend
solution in case we don't reach one - but also, even if you reach some
reasonable compromise I assume it won't be instant and instant confirmation
between exchanges can create huge arbitrage opportunities and as such
liquidity.
It's not really aimed at the merchant but more at service providers and
payment processors - or simply, between users that don't know each other in
local traders environments/squares, assuming they are ok trusting a
known/respected/reputable third party.
> In practice of course this is something payment processors like Bitpay and
Coinbase will think about. Individual cafes etc who are just using mobile
wallets won't be able to deal with this complexity: if we can't make native
Bitcoin work well enough there, we're most likely to just lose that market
or watch it become entirely centralised around a handful of payment
processing companies.
What do you expect for e-commerce and escrow to happen? Don't you think the
market will naturally converge to a handful of hubs that will helps with
refunds and things like that? Or do you expect to just 'trust' all people on
online markets and smaller unknown online shops?
I mean, the beauty of Bitcoin is that it brings much more transparency and
the tools to build such things without huge barriers to entry and without
using closed protocols - not that it solves _every_ problem.

2023-06-07 15:22:45

- reply

📅 Original date posted:2014-06-16
📝 Original message:Mike Hearn <mike <at> plan99.net> writes:
> Actually Tom is running a page where he shows double spends detected by
his node or relayed by mine (there are only two nodes in this little
detection network currently), and it does show double spends that occur
seconds, minutes or even days apart.
I only meant that double spends minutes apart are possible and that by then
the sole use of a monitor is too late even if it will tell you.
> Regardless, whether that approach helps or not is off topic for this
thread. Let's all hope it does and discuss the details in some other thread,
or on the pull request.
Fair enough.
> Yes indeed, if you want to do high frequency trading then every
millisecond counts and you probably don't want to rely on watching
transactions propagate across the block chain. For inter-exchange traffic
this BIP would probably be useful. I've been talking about the consumer
case.
That's quite different, granted.
> No, I expect there to be many kinds of trades where dispute mediation is
unnecessary, e.g. when I buy a drink at Starbucks or a burger at McDonalds
the chances of me wanting to charge it back is basically zero. Same for
sending between people who know each other, large corporate transactions
where the threat of a lawsuit is more useful than mediation, etc.
I wouldn't assume that if bitcoin alone (i.e. without third parties) can't
be used for medium-high value purchases then it's useless.
> But for transactions where third parties are needed for dispute mediation,
yes, I'd expect there to be a handful of well known trusted names for the
majority of such transactions, and then a long tail of specialists who only
mediate e.g. purchases of rare Aztec artifacts or other things where a
generic company might be easily fooled.
Agreed.

2023-06-07 15:22:43

- reply

📅 Original date posted:2014-06-16
📝 Original message:Daniel Rice <drice <at> greenmangosystems.com> writes:
> If double spends are not resolved, there will be a million instant
providers in the long run and if double spends are resolved then this BIP
extension is completely unnecessary.
I am not sure if double spends can be resolved, at the moment they are not
and I highly doubt you will see millions instant providers just like I don't
see millions Certificate Authorities and I don't see Million Credit Card
networks.
Any reason you think people will spread trust instead of consolidating of a
bunch of instant transaction providers when time is critical?

2023-06-07 15:22:41

- reply

📅 Original date posted:2014-06-18
📝 Original message:Andreas Schildbach <andreas <at> schildbach.de> writes:
>
> What is the use of the Transactions message? Note the Payment message
> already contains a transactions field that could be signed. Can you
> briefly describe the whole flow of messages on an example, including the
> BIP70 messages?
Updated the BIP draft with an example and a few corrections (like the
redundant parameter).
You can see the diff here
https://github.com/greenaddress/bips/commit/636d5819c1be9cc099dca0a47a3148332
522a3d4
Allow me to recap BIP changes in discussion:
- making some changes to allow merchants to offer discounts in case of
instant ?
- allowing multiple signatures ?
Did I miss anything? Thoughts on the above from others?

2023-06-07 15:22:41

- reply

📅 Original date posted:2014-06-15
📝 Original message:Andreas Schildbach <andreas <at> schildbach.de> writes:
> Generally I like the simplicity of this BIP. Still, I have more questions:
>
> What is the use of the Transactions message? Note the Payment message
> already contains a transactions field that could be signed.
Transactions message sole purpose is to allow easy signing of all
transactions
i don't think you can serialise a single field
maybe i missed something, not sure
> Can you
> briefly describe the whole flow of messages on an example, including the
> BIP70 messages?
I'll get back to the list with something tomorrow,
can be useful in the BIP as an example anyway I guess.
> Should we allow adding multiple signatures (from different instant
> providers
maybe in some different scheme of "instantness" that could be useful,
although i wonder if it's possible to keep the BIP simple with
such non immediately obvious use cases.
> or maybe while transitioning to another PKI)?
another PKI, not sure, I understand there are already somewhat weak industry
schemes to revoke.
I do wonder if there's any better and more "future proof" way.
I'll think about it but for now I hope someone with more experience can
share some insight.

2023-06-07 15:22:40

- reply

📅 Original date posted:2014-06-15
📝 Original message:Andreas Schildbach <andreas <at> schildbach.de> writes:
> Just a quick comment:
>
> The supports_instant field seems redundant to me. First, as per your
> spec, you can derive it from trusted_instant_providers. And second, why
> do you need it at all? Protobuf is designed so it will simply ignore
> fields you don't know. So you can just send the instant_* fields in the
> Payment message without harm.
Agreed, supports_instant is redundant and can/should/will go.
trusted_instant_providers on the other hand I think is needed.
Sometimes the providers will charge fees for instant.
While the software can ignore the fields,
users may not want to pay for instant when the merchant may not accept it or
care (even if it would not break the protocol it would still be a waste of
fees)
Does it make sense?
Not all transactions from GreenAddress provide double spend protection, there
are additional checks on prevout that are normally not done when spending
normally, etc

2023-06-07 15:22:40

- reply

📅 Original date posted:2014-06-14
📝 Original message:Hello,
I had the pleasure to meet some of you in Amsterdam and/or to speak on
#bitcoin-dev but this is actually my first message to the mailing list - I
feel a bit clumsy so apologies in advance if I make any mistake :)
Quick introduction/background: my name is Lawrence Nahum and I'm the
founder of GreenAddress, a BIP32 multisignature service and instant
confirmation platform available in form of web socket APIs and Wallet for
mobile, desktop and web. My background is in CS with distributed systems
and I've worked most of my career in the City on OTC financial services
like confirmation and clearing platforms.
This post is to gather feedback, comments and reviews about a BIP70 payment
protocol proto buffer extension proposal.
https://github.com/greenaddress/bips/blob/bip-payment-request-instant-confirmations/bip-payment-request-instant-confirmations.mediawiki
If you are interested in GreenAddress design or for more information on
GreenAddress you can find the white paper here
http://ghgreenaddress.files.wordpress.com/2014/04/greenaddressp2sh2of2hd-61.pdf
and our homepage on https://greenaddress.it
Cheers,
Lawrence
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140614/e2fdcb16/attachment.html>