<unnamed>

Public Key

npub1q96r67z2pgf6zg3t7zkxd77fdgzz8euhwazmkdh4adrlrlt40unqnw5u98

Profile Code

nprofile1qqsqzapa0p9q5yapyg4lptrxl0yk5ppru7thw3dmxm67k3l3l46h7fspz4mhxue69uhhyetvv9ujumn0wd68ytnwv46qzrthwden5te0dehhxtnvdakqz9rhwden5te0wfjkccte9ejxzmt4wvhxjmcx40gxx

Publishing to

relay.nostr.net

nos.lol

relay.damus.io

Last Notes

2023-06-07 15:39:03 UTC

- 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:22:46 UTC

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

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

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

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

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

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

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

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