<unnamed>

Public Key

npub1trckpcxmceskq4cykxgwxm63n8ugrjrpu5mk83c90e4upsf7d9gqf0f95j

Profile Code

nprofile1qqs93utqurduvctq2uztry8rdagen7ypeps72dmrcuzhu67qcylxj5qpzpmhxue69uhkummnw3ezuamfdejslh45c8

Publishing to

nostr.wine

Last Notes

2023-06-07 15:39:48 UTC

- reply

📅 Original date posted:2015-06-23
📝 Original message:> Consensus is that this process is too painful to go through once a year. I
> agree.
>
> If you disagree and would like to see a Blocksize Council meet once a year
> to issue a decree on what the maximum block size shall be for the next
> year, then propose a process for who gets to sit on the Council and how
> their decrees are enforced.....
We could just as well say that the increases continue for 20 years, or
until there is concensus to schedule a soft-fork to prevent further
increase - whichever comes first. That is the case already, of
course, since there is no way to prevent a modest supermajority of
miners from pushing through a soft-fork. But explicitly accepting the
possibility that the community might choose to cut the process short
might make the BIP more palatable to some.
It is also the reality: halting the blocksize increase before it hits
the final 8GB limit is relatively easy, compared to the task of
setting it in motion, so it does no real harm to set the "20 years"
figure at the upper range of what we think is reasonable - even though
under other circumstances one would probably say that extrapolating
exponentials that far out would be foolhardy...
roy

2023-06-07 15:29:44 UTC

- reply

📅 Original date posted:2015-02-05
📝 Original message:For peer-to-peer payments, how common do we think that the payment is
of an ad hoc nature rather than to a known contact?
If I want to pay my friends/colleagues/etc over a restaurant table
there's no reason why I couldn't already have their public keys in my
contact list - then it would be pretty straightforward to have a
watertight mechanism where I would know who I was paying. You could
probably even relatively securely bootstrap a key exchange over SMS,
relying only on the contacts already having each other in their
phonebooks.
As for comsumer-to-merchant transactions where the merchant is a
bricks and mortar merchant, IMHO it absolutely has to be "pay that
terminal over there". It's the trust model we all currently use -
whether paying cash or card - and it's the only trust model that works
IMHO (and customers and businesses alike are well aware of the risks
of a fraudster standing behind the counter pretending to be an
employee accepting payment - and by and large are pretty good at
mitigating it). OTOH as we've discussed here before there are many
use cases where the custoemr doesn't actually know or care about the
name of the shop or bar they walked into but is pretty damn sure that
they need to make payment to the person over there behind the counter.
Granted, there are cases taht dont' fall into either of the above -
but they're the cases that are (a) harder to figure out how to
authenticate and consequently (b) the use cases that are going to be
most subject to attempted fraud.
roy
On Thu, Feb 05, 2015 at 03:02:56PM -0800, William Swanson wrote:
> On Thu, Feb 5, 2015 at 2:10 PM, Eric Voskuil <eric at voskuil.org> wrote:
> > A MITM can receive the initial broadcast and then spoof it by jamming the
> > original. You then only see one.
>
> You are right, of course. There is no way to make Bluetooth 100%
> secure, since it is an over-the-air technology. You could try securing
> it using a CA or other identity server, but now you've excluded ad-hoc
> person-to-person payments. Plus, you need an active internet
> connection to reach the CA.
>
> You can try using proximity as a substitute for identity, like
> requiring NFC to kick-start the connection, but at that point you
> might as well use QR codes.
>
> This BIP is not trying to provide absolute bullet-proof security,
> since that's impossible given the physical limitations of the
> Bluetooth technology. Instead, it's trying to provide the
> best-possible security given those constraints. In exchange for this,
> we get greatly enhanced usability in common scenarios.
>
> There are plenty of usable, real-world technologies with big security
> holes. Anybody with lock-picking experience will tell you this, but
> nobody is welding their front door shut. The ability to go in and out
> is worth the security risk.
>
> Bluetooth payments add a whole new dimension to real-world Bitcoin
> usability. Do we shut that down because it can't be made perfect, or
> do we do the best we can and move forward?
>
> -William
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming. The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

2023-06-07 15:29:43 UTC

- reply

📅 Original date posted:2015-02-05
📝 Original message:Personally I like the simplicity of tapping two phones together to
make payment - it should be quicker and easier than scanning QR codes
and it's a trust model that's hard to misunderstand.
Is NFC good enough for that? I fear even with NFC it is possible to
produce a device with longer range than one would expect. What
happened to the idea of tapping two devices together and then
comparing the timing of the tap (as detected by the phones'
accelerometers) to make spoofing a transaction harder? I remember
hearing about that years ago - is that still a thing?
roy
On Thu, Feb 05, 2015 at 02:10:51PM -0800, Eric Voskuil wrote:
> A MITM can receive the initial broadcast and then spoof it by jamming the original. You then only see one.
>
> e
>
> > On Feb 5, 2015, at 2:07 PM, Paul Puey <paul at airbitz.co> wrote:
> >
> > So if you picked up the BLE broadcast request. All you know is that *someone* within 100m is requesting bitcoin at a certain address. Not necessarily who. The *name* is both optional, and possibly just a *handle* of the user. If I'm sitting 5 ft away from someone at dinner and wanted to pay them via BLE, I might see "Monkey Dude" on my list and simply ask him "is that you?" If so, I send it. If there are two "Monkey Dude's" Then I have to bother with the address prefix, but not otherwise.
> >
> >> On Thu, Feb 5, 2015 at 1:46 PM, Eric Voskuil <eric at voskuil.org> wrote:
> >> BLE has an advertised range of over 100m.
> >>
> >> http://www.bluetooth.com/Pages/low-energy-tech-info.aspx
> >>
> >> In the case of mass surveillance that range could most likely be extended dramatically by the reviewer. I've seen WiFi ranges of over a mile with a strong (not FCC approved) receiver.
> >>
> >> WiFi hotspots don't have strong identity or a guaranteed position, so they can't be trusted for location.
> >>
> >> e
> >>
> >> On Feb 5, 2015, at 1:36 PM, Mike Hearn <mike at plan99.net> wrote:
> >>
> >>>> This sounds horrible. You could basically monitor anyone with a wallet in a highly populated area and track them super easily by doing facial recognition.
> >>>
> >>> We're talking about BLE, still? The radio tech that runs in the so called "junk bands" because propagation is so poor?
> >>>
> >>> My watch loses its connection to my phone if I just put it down and walk around my apartment. I'm all for reasonable paranoia, but Bluetooth isn't going to be enabling mass surveillance any time soon. It barely goes through air, let alone walls.
> >>>
> >>> Anyway, whatever. I'm just bouncing around ideas for faster user interfaces. You could always switch it off or set it to be triggered by the presence of particular wifi hotspots, if you don't mind an initial bit of setup.
> >>>
> >>> Back on topic - the debate is interesting, but I think to get this to the stage of being a BIP we'd need at least another wallet to implement it? Then I guess a BIP would be useful regardless of the design issues. The prefix matching still feels flaky to me but it's hard to know if you could really swipe payments out of the air in practice, without actually trying it.
> >
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming. The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

2023-06-07 15:16:42 UTC

- reply

📅 Original date posted:2014-03-29
📝 Original message:On Sat, Mar 29, 2014 at 01:42:01PM -0400, Matt Whitlock wrote:
> On Saturday, 29 March 2014, at 5:28 pm, Roy Badami wrote:
> > Right now there are also people simply taking base58-encoded private
> > keys and running them through ssss-split.
> >
> > It has a lot going for it, since it can easily be reassembled on any
> > Linux machine without special software (B Poettering's Linux command
> > line SSSS implementation[1] seems to be included in most Linux distros).
> >
> > roy
> >
> > [1] http://point-at-infinity.org/ssss/
>
> Respectfully, it's also possible to take a base58-encoded private key and run it through GPG, which is included in most Linux distros. But yet we have BIP38.
And yet, how many wallets can import BIP38 keys? If someone gave me
one I would have no idea what software (if any) can understand it (nor
would I have any idea how to generate one in the first place).
Anyway, I'm not arguing against standardising these things - if people
are going to implement this then of course it's beneficial that they
implement it compatibly. It was just a simple observation - make of
it what you will.
roy

2023-06-07 15:16:42 UTC

- reply

📅 Original date posted:2014-03-29
📝 Original message:Right now there are also people simply taking base58-encoded private
keys and running them through ssss-split.
It has a lot going for it, since it can easily be reassembled on any
Linux machine without special software (B Poettering's Linux command
line SSSS implementation[1] seems to be included in most Linux distros).
roy
[1] http://point-at-infinity.org/ssss/
On Sat, Mar 29, 2014 at 12:59:19PM -0400, Alan Reiner wrote:
>
> Armory has had "Fragmented Backups" for over a year, now. Advanced
> users love it. Though, I would say it's kind of difficult to
> standardize the way I did it since I was able to implement all the
> finite field math with recursion, list comprehensions and python
> arbitrary-big-integers in about 100 lines. I'm not sure how "portable"
> it is to other languages. There's obviously better ways to do it, but I
> didn't need a better way, because I don't need to support fragmentation
> above M=8 and this was 100% sufficient for it. And I was the only one
> doing it, so there was no one to be compatible with.
>
> I won't lie, there's a lot of work that goes into making an interface
> that makes this feature "usable." The user needs clear ways to identify
> which fragments are associated with which wallet, and which fragments
> are compatible with each other. They need a way to save some fragments
> to file, print them, or simply write them down. They need a way to
> re-enter fragment, reject duplicates, identify errors, etc. Without it,
> the math fails silently, and you end up restoring a different wallet.
> And they need a way to test that it all works. Armory did all this,
> but it was no trivial task. Including an interface that will test up to
> 50 subsets of make sure the math produces the same values every time
> (which still is not sufficient for some users, who won't be satisified
> til they see they're wallet actually restored from fragments.
>
> Also I put the secret in the highest-order coefficient of the
> polynomial, and made sure that the other coefficients were
> deterministic. This meant that if print out an M-of-N wallet, I can
> later print out an M-of-(N+1) wallet and the first N fragments will be
> the same. I'm not sure how many users would trust this, but we felt it
> was important in case a user needs to export some fragments, even if
> they don't increase N.
>
> You might consider loading Armory in offline mode, create a wallet, and
> then do a fragmented backup to see how we did it. I am extremely
> satisfied with the interface, but it's most definitely an "advanced"
> tool. But so is Armory ... which made it a good fit. But it might not
> be for everyone.
>
> -Alan
>
>
>
> On 03/29/2014 11:44 AM, Matt Whitlock wrote:
> > On Saturday, 29 March 2014, at 11:08 am, Watson Ladd wrote:
> >> https://freedom-to-tinker.com/blog/stevenag/new-research-better-wallet-security-for-bitcoin/
> > Thanks. This is great, although it makes some critical references to an ACM paper for which no URL is provided, and thus I cannot implement it.
> >
> > A distributed ECDSA notwithstanding, we still need a way to decompose a BIP32 master seed into shares. I am envisioning a scenario in which I might meet my sudden and untimely demise, and I wish to allow my beneficiaries to reconstruct my wallet's master seed after my death. I would like to distribute seed shares to each of my beneficiaries and some close friends, such that some subset of the shares must be joined together to reconstitute my master seed. Shamir's Secret Sharing Scheme is perfect for this use case. I am presently working on extending my draft BIP so that it also applies to BIP32 master seeds of various sizes.
> >
> > ------------------------------------------------------------------------------
> > _______________________________________________
> > Bitcoin-development mailing list
> > Bitcoin-development at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

2023-06-07 15:15:31 UTC

- reply

📅 Original date posted:2014-03-14
📝 Original message:On Fri, Mar 14, 2014 at 03:05:25PM +0100, Andreas Schildbach wrote:
> btw. None of Bitcoin Wallet's users complained about confusion because
> of the mBTC switch. In contrast, I get many mails and questions if
> exchange rates happen to differ by >10%.
At the moment, I imagine the vast majority of Bitcoin users are
familliar with SI units and know what milli- and micro- mean.
I doubt that is true of the general population, though.
roy

2023-06-07 15:14:25 UTC

- reply

📅 Original date posted:2014-03-20
📝 Original message:On Thu, Mar 20, 2014 at 07:31:27PM +0100, Mike Hearn wrote:
> Yes, this overlaps somewhat with the PKI signing in BIP70, but not
> entirely - you might want to serve unsigned payment requests, but
> still have confidentiality and authenticity for a local face to face
> transaction. The signing and encryption does different things
I'm not sure if this what you're getting at, but in a common
face-to-face scenario, it really doesn't overlap so much (in that the
PKI in BIP70 isn't really helpful).
It's not unusual, in a face-to-face transaction at a bricks-and-mortar
establishment, that you know neither the legal name of the entity
running the establishment, nor any electronic identifier (domain name,
email address) that might be presented to you in an X.509 certificate,
even if such a certificate is presented in the PaymentRequest.
In many cases I want/need to simply be assured that I am paying "the
person/organisation which operates that machine behind the counter,
right there".
In many ways I'll miss the simplicity of BIP21 QR codes for
face-to-face transactions - because in this use case the payment
protocol complicates (and in many cases weakens) the assurance that
you really are paying the entity that prepared the QR code.
roy

2023-06-07 15:14:25 UTC

- reply

📅 Original date posted:2014-03-26
📝 Original message:On Fri, Mar 21, 2014 at 12:02:44AM +0100, Mike Hearn wrote:
> >
> > It's not unusual, in a face-to-face transaction at a bricks-and-mortar
> > establishment, that you know neither the legal name of the entity
> > running the establishment
>
>
> I'd hope that people can get certs for their actual business name, but
> sometimes it does differ yes.
The actual example I was thinking of is that of traditional British
pubs. Often a company will own several pubs - however the pubs
themselves will typically have individual traditional pub names. The
name of the company might not be at all prominently advertised in the
pubs.
Traders at music festivals are another example that comes to mind (they
often accept credit cards if they sell higher value items so why not
Bitcoin?) In this example there often are no clearly advertised
business names - at least, that the customer will be aware of.
roy

2023-06-07 15:12:43 UTC

- reply

📅 Original date posted:2014-01-27
📝 Original message:On Mon, Jan 27, 2014 at 09:11:08AM -0800, Jeremy Spilman wrote:
> On Mon, 27 Jan 2014 03:59:25 -0800, Andreas Schildbach
> <andreas at schildbach.de> wrote:
>
> > SCAN TO PAY
> > For scan-to-pay, the current landscape looks different. I assume at
> > least 50% of Bitcoin transactions are initiated by a BIP21 URL encoded
> > into a QR-code. Nevertheless, I tried to encode a payment request into
> > the bitcoin URL. I used my existing work on encoding transactions into
> > QR-codes. Steps to encode:
>
> Really interesting work. When using scan-to-pay, after the payer scans the
> QR code with the protobuf PaymentRequest (not a URL to download the
> PaymentRequest) are they using their own connectivity to submit the
> Payment response?
>
> If we assume connectivity on the phone, might as well just get a URL from
> the QR code and re-use existing infrastructure for serving that?
My first thought was likewise. In the case where the phone needs
Internet connectivity anyway, why not include an HTTPS URL in a BIP 72 URL?
I'm assuming that every client will have to support this is any case,
since it's effectively mandated by the BIP, so why add another mode of
operation?
However, PaymentRequest-over-QR-code does seem to me to have one
rather attractive advantage: the authentication model is orders of
magnitude simpler and more intuitive for a face-to-face transaction
than anything else. You're saying "pay the coins to that thing over
there displaying that QR code". Which, most of the time, is exactly
what you want.
In the web case, it's fine to ignore the case where the URL domain has
been subverted (and an cert obtained by the attacker) because in that
case you've lost before you even get to payments (MitM attacker shows
you a modified web page with different payment details). But the
face-to-face case isn't intrinsically dependent on SSL security, and
it's nice not to introduce that attack vector...
roy

2023-06-07 15:11:55 UTC

- reply

📅 Original date posted:2014-01-13
📝 Original message:> It's not public. When I say "please pay me" I also say "use this
> multiplier".
Sending a "please pay me" message is really great for business
transactions.
But I think the use case that Peter Todd mentions is actually *the*
most important currently under-addresesd use case:
> With stealth addresses the user experience can be as simple as you
> telling me on the phone "hey! send me that 0.234 BTC you owe me!",
> me clicking on "Send to Alan Reiner (verified by PGP)" (perhaps
> again on my off-line second factor device for a multi-sig wallet)
> and tellling you "OK, sent".
Lots of work is being done on handling consumer-to-merchant
transactions. BIP 70 does a good job of tackling the online purchase
case, and the work that Andreas Schildbach is doing with Bluetooth and
NFC will improve the options for a payer in a physical PoS transaction
who might not have Internet connectivity on their smartphone.
But relatively little work (that I know of) is being done on
non-transactional personal payments - that is, being able to pay money
to friends and other people that you have a face-to-face relationship
with.
What I want... no need... is to be able to open my wallet, select a
friend from my address book, and transfer the $10 I owe them from the
bar last night.
I don't care - within reason - what process is involved in getting my
friend set up in my address book. That may well requires two way
communication (e.g. over NFC). But once it's set up, I should be able
to just select the payee from the address book and send them some
funds. Anything else is just too complciated.
I don't know if stealth addresses are the best solution to address
this use case, but AFAIK the only current solution to this use case is
to store a long-lived Bitcoin address in the addresss book.
roy

2023-06-07 15:11:51 UTC

- reply

📅 Original date posted:2014-01-13
📝 Original message:On Mon, Jan 13, 2014 at 01:52:25AM -0800, Gregory Maxwell wrote:
> On Sun, Jan 12, 2014 at 1:18 PM, Gavin Andresen <gavinandresen at gmail.com> wrote:
> > No, please. Make it easy for non-geeks, extend the payment protocol, or
> > we'll spend the next two years writing code that tries to ignore linebreaks
> > and spaces and changing <input> elements in HTML forms to <textarea> ....
>
> However, if you're able to use the payment protocol then you probably
> don't need stealth addresses to prevent reuse.
I definitely think this is a case that should be addressed better than
at present.
To consider a concrete use case, imagine I wish to be able to give my
friends and acquaintances a paper business card with a QR code on it,
that they can use to make payments to me. I don't own a domain or any
kind of X.509 certificate and I don't run an HTTP server. I don't
feel comfortable with a solution that requires me to trust a third
party to complete the payments.
At the moment, I can give them a business card with a Bitcoin address.
Being able to give out a business card with a stealth address would be
a major advance.
roy

2023-06-07 15:11:51 UTC

- reply

📅 Original date posted:2014-01-13
📝 Original message:> > Likewise, I could attach a payment request to an email and send it to you,
> > and now you can pay me whenever you want forever.
>
> That certainly sounds like a plausible use case. You do still have
> the problem that e-mail is an insecure channel, but it's no worse than
> exchanging Bitcoin addreses over e-mail as things stand at the
> moment.
On further reflection, I'm not sure I understand this use case of the
payment protocol. Since a PaymentRequest currently contains the
Outputs that specify the addresses to send to, reusing a
PaymentRequest like this without using stealth addresses implies
address reuse.
(Granted there are alternative solutions to stealth addresses, such as
a BIP32-style derivation.)
roy

2023-06-07 15:11:51 UTC

- reply

📅 Original date posted:2014-01-13
📝 Original message:rOn Mon, Jan 13, 2014 at 08:57:33PM +0100, Mike Hearn wrote:
> >
> > On further reflection, I'm not sure I understand this use case of the
> > payment protocol. Since a PaymentRequest currently contains the
> > Outputs that specify the addresses to send to, reusing a
> > PaymentRequest like this without using stealth addresses implies
> > address reuse.
>
>
> Yes indeed ...... which is why we're talking about extending the protocol
> (in a future version! the first version isn't even out yet!).
Yes, sorry, I miscontrued the thread here and now see that your
message was exactly talking about using stealth addresses within the
payment protocol.
Sorry for the confusion.
roy

2023-06-07 15:11:42 UTC

- reply

📅 Original date posted:2014-01-15
📝 Original message:On Wed, Jan 15, 2014 at 11:17:33PM +0000, I wrote:
> How about just calling them 'type S addresses'?
(Assuming they're encoded in such as way that they actually start with 's'.
Otherwise whatever prefix is actually used, obviously.)

2023-06-07 15:11:42 UTC

- reply

📅 Original date posted:2014-01-15
📝 Original message:On Wed, Jan 15, 2014 at 03:44:17PM -0500, Jeff Garzik wrote:
> "static address" seems like a reasonable attempt at describing intended
> use/direction.
...as opposed to an address configured by DHCP?
More seriously, I don't think a typical user will understand anything from
the phrase "static address". But it is a neutral name, and it is shorter
than "address-of-a-type-for-which-reuse-is-not-deprecated". :-)
-roy

2023-06-07 15:11:42 UTC

- reply

📅 Original date posted:2014-01-15
📝 Original message:How about just calling them 'type S addresses'?
Not sure any other name will in reality convey much more meaning than
that.
On Wed, Jan 15, 2014 at 06:07:28PM -0500, Jeff Garzik wrote:
> "Routing address" is pretty good too. Unsure whether the synergy and
> familiarity with bank routing numbers improves the situation, or
> not...
>
>
> On Wed, Jan 15, 2014 at 6:04 PM, Roy Badami <roy at gnomon.org.uk> wrote:
> > On Wed, Jan 15, 2014 at 03:44:17PM -0500, Jeff Garzik wrote:
> >> "static address" seems like a reasonable attempt at describing intended
> >> use/direction.
> >
> > ...as opposed to an address configured by DHCP?
> >
> > More seriously, I don't think a typical user will understand anything from
> > the phrase "static address". But it is a neutral name, and it is shorter
> > than "address-of-a-type-for-which-reuse-is-not-deprecated". :-)
> >
> > -roy
>
>
>
> --
> Jeff Garzik
> Bitcoin core developer and open source evangelist
> BitPay, Inc. https://bitpay.com/
>

2023-06-07 15:11:40 UTC

- reply

📅 Original date posted:2014-01-14
📝 Original message:On Mon, Jan 13, 2014 at 04:58:01PM +0100, Mike Hearn wrote:
>
> Signing a payment request for an individual is easy, anyway, depending on
> the kind of ID you want. If you want to sign with an email address, just go
> here with a browser like Chrome/Safari/IE that uses the system keystore:
>
> http://www.comodo.com/home/email-security/free-email-certificate.php
Having now read that page, I'll just leave you with the first bullet
point from it:
* Digital signature ensures confidentiality
(I'm not trying to make any particular point here - I just couldn't resist)
roy

2023-06-07 15:11:40 UTC

- reply

📅 Original date posted:2014-01-13
📝 Original message:On Mon, Jan 13, 2014 at 04:58:01PM +0100, Mike Hearn wrote:
> Signing a payment request for an individual is easy, anyway, depending on
> the kind of ID you want. If you want to sign with an email address, just go
> here with a browser like Chrome/Safari/IE that uses the system keystore:
>
> http://www.comodo.com/home/email-security/free-email-certificate.php
>
Ok, cool, I wasn't aware of such services, and I can certainly see
they could be useful. But it's not that great for the business card
scenario.
As far as I can see, using it in that scenario would have to rely on
the payer scanning the QR code on the business card, and then check
that the email address displayed by their wallet matched the email
address printed on the business card.
roy

2023-06-07 15:11:39 UTC

- reply

📅 Original date posted:2014-01-13
📝 Original message:> I was thinking that people could upload a payment protocol file somewhere
> once (like to their personal web page, or shared via dropbox or google
> drive or some custom new pastebin style service), and then just encode a
> regular bitcoin URI into the qrcode on the billboard.
That does require trusting the third party not to later tamper with
the payment request, though. (I'm assuming that a signed payment
request is not always going to be all that useful in the case of
private individuals, even assuming the payee is willing to sign up for
one.)
> Likewise, I could attach a payment request to an email and send it to you,
> and now you can pay me whenever you want forever.
That certainly sounds like a plausible use case. You do still have
the problem that e-mail is an insecure channel, but it's no worse than
exchanging Bitcoin addreses over e-mail as things stand at the
moment.
roy

2023-06-07 15:10:28 UTC

- reply

📅 Original date posted:2013-12-08
📝 Original message:> > 5) Who controls DNS for it?
>
> I'm not sure we'll get any change on this level. I have no idea if the
> domain is in good hands, except for the fact that nothing bad happened
> thus far. If anything, moving it to core developers (as intended when
> the domain was registered) would make more sense IMO. But again, is it
> possible, I don't know.
That's an interesting question. The bitcoin.org domain is hiding
behind a WhoisGuard anonymous registration. Why are we not allowed to
know who this domain belongs to? Why are we being asked to trust some
unidentified party?
roy

2023-06-07 15:10:27 UTC

- reply

📅 Original date posted:2013-12-09
📝 Original message:> The bitcoin.org domain is controlled by me, Sirius, and an anonymous
> person. Control will not be lost if Sirius becomes unavailable.
I know this will be a controversial viewpoint in some quarters, but
I'm not a fan of anonymity, or of pseudonyms. As far as I know
(please correct me if I'm wrong) all the core devs go by their real
names with the exception of Satoshi (and I would hope he no longer has
commit access? - only because I would hope that no-one has
pseudonymous commit access these days). I don't see why this should
be different for the domain, the DNS and the rest of the
infrastructure...
Although that's separate from the question of who the registrant of
the domain should be (the registrant being the closest thing a domain
has to a recorded legal owner). Who currently purports to be the
current legal owner of the domain?
IMHO the registrant should obviously be real and not WhoisGuard -
anonymous stuff like this always looks shady. And surely the Bitcoin
Foundation is the obvious candidate to own the domain (just like
kernel.org is owned by the Linux Foundation). But this may all be
moot unless the current legal owners are willing to assign the
domain...
roy

2023-06-07 15:10:20 UTC

- reply

📅 Original date posted:2013-12-09
📝 Original message:On Mon, Dec 09, 2013 at 01:39:51PM +0000, Drak wrote:
> Someone needs to update the bitcoin.org website, it still points downloads
> to 0.8.5
Perhaps because 0.8.6 hasn't been released yet? Or did I miss the
announcement? I think it makes sense that release candidates are not
promoted on bitcoin.org.
> ------------------------------------------------------------------------------
> Sponsored by Intel(R) XDK
> Develop, test and display web and hybrid apps with a single code base.
> Download it for free now!
> http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

2023-06-07 15:05:37 UTC

- reply

📅 Original date posted:2013-08-07
📝 Original message:On Thu, Aug 08, 2013 at 07:10:05AM +1000, Gavin Andresen wrote:
> RE: should the customer's machine not broadcast the transaction:
If we're going to allow payments to fail without being broadcast (but
where the wallet can't in general prove that the receiver hasn't seen
the transaction) then I would argue that it becomes highly desirable
that the wallet invalidates the transaction at the earliest
opportunity by spending the outputs in a pay-to-self transaction.
Otherwise malicious receivers, or temporary failures, could result in
the user being told that the transfer didn't happen, but then the
coins actually leaving the wallet anyway a short time later.
roy

2023-06-07 15:05:36 UTC

- reply

📅 Original date posted:2013-08-07
📝 Original message:On Wed, Jul 31, 2013 at 05:30:46PM -0600, E willbefull wrote:
> I think it's important to expect PaymentRequest-only bitcoin URIs in the
> future. Some types of payments (exotic transactions) may not make sense to
> have a single fallback address. Or, a page with a bitcoin URI link may be
> relying on a separate service provider to assemble the transaction.
Also:
* There may be a desire to minimize the URL length when used in a QR code
* Some applications might specifically require some of the features of
the payment protocol - e.g. it may be a requirement that a print-media
QR code cannot be used after a cut-off date, or a vendor may have a
specific requirement not to accept payments without a refund address
There are pros and cons, but it's not clear to me that the benefits of
enforced backward compatibility outweigh the benefits of allowing
application designers to innovate as they see fit.
roy

2023-06-07 15:02:39 UTC

- reply

📅 Original date posted:2013-06-04
📝 Original message:> Sure they are paying themselves, but given bitcoin network
> difficulty is uso high, simply obtaining payments-go-myself-as-miner
> transactions is itself difficult.
Not for pool operators it isn't. Nor for people buying hashing power
from a GPUMAX-type service, if such services still exist (or should
they exist again in future).

2023-06-07 11:42:50 UTC

- reply

📅 Original date posted:2013-04-01
📝 Original message:And the moment I hit send I realised it's not necessarily true.
Conceivably, a collision attack might help you craft two commits (one
good, one bad) with the same hash.
But I still maintain what I just posted is true: if someone gets
malicious code into the repo, it's going to be by social engineering,
not by breaking the cyrpto.
roy
On Mon, Apr 01, 2013 at 11:51:07PM +0100, Roy Badami wrote:
> The attack Schneier is talking about is a collision attack (i.e. it
> creates two messages with the same hash, but you don't get to choose
> either of the messages). It's not a second preimage attack, which is
> what you would need to be able to create a message that hashes to the
> same value of an existing message.
>
> (And it neither have anything to do with the birthday paradox, BTW -
> which relates to the chance of eventually finding two messages that
> hash to the same value by pure change)
>
> If someone gets malicious code into the repo, it's going to be by
> social engineering, not by breaking the cyrpto.
>
> roy
>
> On Tue, Apr 02, 2013 at 12:27:51AM +0200, Melvin Carvalho wrote:
> > On 2 April 2013 00:10, Will <will at phase.net> wrote:
> >
> > > The threat of a SHA1 collision attack to insert a malicious pull request
> > > are tiny compared with the other threats - e.g. github being compromised,
> > > one of the core developers' passwords being compromised, one of the core
> > > developers going rogue, sourceforge (distribution site) being compromised
> > > etc etc... believe me there's a lot more to worry about than a SHA1
> > > attack...
> > >
> > > Not meaning to scare, just to put things in perspective - this is why we
> > > all need to peer review each others commits and keep an eye out for
> > > suspicious commits, leverage the benefits of this project being open source
> > > and easily peer reviewed.
> > >
> >
> > Very good points, and I think you're absolutely right.
> >
> > But just running the numbers, to get the picture, based of scheiner's
> > statistics:
> >
> > http://www.schneier.com/blog/archives/2012/10/when_will_we_se.html
> >
> > We're talking about a million terrahashes = 2^60 right?
> >
> > With the block chain, you only have a 10 minute window, but with source
> > code you have a longer time to prepare.
> >
> > Couldnt this be done with an ASIC in about a week?
> >
> >
> >
> > >
> > > Will
> > >
> > >
> > > On 1 April 2013 23:52, Melvin Carvalho <melvincarvalho at gmail.com> wrote:
> > >
> > >>
> > >>
> > >>
> > >> On 1 April 2013 20:28, Petr Praus <petr at praus.net> wrote:
> > >>
> > >>> An attacker would have to find a collision between two specific pieces
> > >>> of code - his malicious code and a useful innoculous code that would be
> > >>> accepted as pull request. This is the second, much harder case in the
> > >>> birthday problem. When people talk about SHA-1 being broken they actually
> > >>> mean the first case in the birthday problem - find any two arbitrary values
> > >>> that hash to the same value. So, no I don't think it's a feasible attack
> > >>> vector any time soon.
> > >>>
> > >>> Besides, with that kind of hashing power, it might be more feasible to
> > >>> cause problems in the chain by e.g. constantly splitting it.
> > >>>
> > >>
> > >> OK, maybe im being *way* too paranoid here ... but what if someone had
> > >> access to github, could they replace one file with one they had prepared at
> > >> some point?
> > >>
> > >>
> > >>>
> > >>>
> > >>> On 1 April 2013 03:26, Melvin Carvalho <melvincarvalho at gmail.com> wrote:
> > >>>
> > >>>> I was just looking at:
> > >>>>
> > >>>> https://bitcointalk.org/index.php?topic=4571.0
> > >>>>
> > >>>> I'm just curious if there is a possible attack vector here based on the
> > >>>> fact that git uses the relatively week SHA1
> > >>>>
> > >>>> Could a seemingly innocuous pull request generate another file with a
> > >>>> backdoor/nonce combination that slips under the radar?
> > >>>>
> > >>>> Apologies if this has come up before ...
> > >>>>
> > >>>>
> > >>>> ------------------------------------------------------------------------------
> > >>>> Own the Future-Intel® Level Up Game Demo Contest 2013
> > >>>> Rise to greatness in Intel's independent game demo contest.
> > >>>> Compete for recognition, cash, and the chance to get your game
> > >>>> on Steam. $5K grand prize plus 10 genre and skill prizes.
> > >>>> Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d
> > >>>> _______________________________________________
> > >>>> Bitcoin-development mailing list
> > >>>> Bitcoin-development at lists.sourceforge.net
> > >>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> > >>>>
> > >>>>
> > >>>
> > >>
> > >>
> > >> ------------------------------------------------------------------------------
> > >> Own the Future-Intel® Level Up Game Demo Contest 2013
> > >> Rise to greatness in Intel's independent game demo contest.
> > >> Compete for recognition, cash, and the chance to get your game
> > >> on Steam. $5K grand prize plus 10 genre and skill prizes.
> > >> Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d
> > >> _______________________________________________
> > >> Bitcoin-development mailing list
> > >> Bitcoin-development at lists.sourceforge.net
> > >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> > >>
> > >>
> > >
>
> > ------------------------------------------------------------------------------
> > Own the Future-Intel® Level Up Game Demo Contest 2013
> > Rise to greatness in Intel's independent game demo contest.
> > Compete for recognition, cash, and the chance to get your game
> > on Steam. $5K grand prize plus 10 genre and skill prizes.
> > Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d
>
> > _______________________________________________
> > Bitcoin-development mailing list
> > Bitcoin-development at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
> ------------------------------------------------------------------------------
> Own the Future-Intel® Level Up Game Demo Contest 2013
> Rise to greatness in Intel's independent game demo contest.
> Compete for recognition, cash, and the chance to get your game
> on Steam. $5K grand prize plus 10 genre and skill prizes.
> Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

2023-06-07 11:42:47 UTC

- reply

📅 Original date posted:2013-04-01
📝 Original message:The attack Schneier is talking about is a collision attack (i.e. it
creates two messages with the same hash, but you don't get to choose
either of the messages). It's not a second preimage attack, which is
what you would need to be able to create a message that hashes to the
same value of an existing message.
(And it neither have anything to do with the birthday paradox, BTW -
which relates to the chance of eventually finding two messages that
hash to the same value by pure change)
If someone gets malicious code into the repo, it's going to be by
social engineering, not by breaking the cyrpto.
roy
On Tue, Apr 02, 2013 at 12:27:51AM +0200, Melvin Carvalho wrote:
> On 2 April 2013 00:10, Will <will at phase.net> wrote:
>
> > The threat of a SHA1 collision attack to insert a malicious pull request
> > are tiny compared with the other threats - e.g. github being compromised,
> > one of the core developers' passwords being compromised, one of the core
> > developers going rogue, sourceforge (distribution site) being compromised
> > etc etc... believe me there's a lot more to worry about than a SHA1
> > attack...
> >
> > Not meaning to scare, just to put things in perspective - this is why we
> > all need to peer review each others commits and keep an eye out for
> > suspicious commits, leverage the benefits of this project being open source
> > and easily peer reviewed.
> >
>
> Very good points, and I think you're absolutely right.
>
> But just running the numbers, to get the picture, based of scheiner's
> statistics:
>
> http://www.schneier.com/blog/archives/2012/10/when_will_we_se.html
>
> We're talking about a million terrahashes = 2^60 right?
>
> With the block chain, you only have a 10 minute window, but with source
> code you have a longer time to prepare.
>
> Couldnt this be done with an ASIC in about a week?
>
>
>
> >
> > Will
> >
> >
> > On 1 April 2013 23:52, Melvin Carvalho <melvincarvalho at gmail.com> wrote:
> >
> >>
> >>
> >>
> >> On 1 April 2013 20:28, Petr Praus <petr at praus.net> wrote:
> >>
> >>> An attacker would have to find a collision between two specific pieces
> >>> of code - his malicious code and a useful innoculous code that would be
> >>> accepted as pull request. This is the second, much harder case in the
> >>> birthday problem. When people talk about SHA-1 being broken they actually
> >>> mean the first case in the birthday problem - find any two arbitrary values
> >>> that hash to the same value. So, no I don't think it's a feasible attack
> >>> vector any time soon.
> >>>
> >>> Besides, with that kind of hashing power, it might be more feasible to
> >>> cause problems in the chain by e.g. constantly splitting it.
> >>>
> >>
> >> OK, maybe im being *way* too paranoid here ... but what if someone had
> >> access to github, could they replace one file with one they had prepared at
> >> some point?
> >>
> >>
> >>>
> >>>
> >>> On 1 April 2013 03:26, Melvin Carvalho <melvincarvalho at gmail.com> wrote:
> >>>
> >>>> I was just looking at:
> >>>>
> >>>> https://bitcointalk.org/index.php?topic=4571.0
> >>>>
> >>>> I'm just curious if there is a possible attack vector here based on the
> >>>> fact that git uses the relatively week SHA1
> >>>>
> >>>> Could a seemingly innocuous pull request generate another file with a
> >>>> backdoor/nonce combination that slips under the radar?
> >>>>
> >>>> Apologies if this has come up before ...
> >>>>
> >>>>
> >>>> ------------------------------------------------------------------------------
> >>>> Own the Future-Intel® Level Up Game Demo Contest 2013
> >>>> Rise to greatness in Intel's independent game demo contest.
> >>>> Compete for recognition, cash, and the chance to get your game
> >>>> on Steam. $5K grand prize plus 10 genre and skill prizes.
> >>>> Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d
> >>>> _______________________________________________
> >>>> Bitcoin-development mailing list
> >>>> Bitcoin-development at lists.sourceforge.net
> >>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >>>>
> >>>>
> >>>
> >>
> >>
> >> ------------------------------------------------------------------------------
> >> Own the Future-Intel® Level Up Game Demo Contest 2013
> >> Rise to greatness in Intel's independent game demo contest.
> >> Compete for recognition, cash, and the chance to get your game
> >> on Steam. $5K grand prize plus 10 genre and skill prizes.
> >> Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d
> >> _______________________________________________
> >> Bitcoin-development mailing list
> >> Bitcoin-development at lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >>
> >>
> >
> ------------------------------------------------------------------------------
> Own the Future-Intel® Level Up Game Demo Contest 2013
> Rise to greatness in Intel's independent game demo contest.
> Compete for recognition, cash, and the chance to get your game
> on Steam. $5K grand prize plus 10 genre and skill prizes.
> Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

2023-06-07 11:39:11 UTC

- reply

📅 Original date posted:2013-03-13
📝 Original message:On Wed, Mar 13, 2013 at 02:27:01PM -0700, Gregory Maxwell wrote:
> On Wed, Mar 13, 2013 at 2:22 PM, Roy Badami <roy at gnomon.org.uk> wrote:
> > The idea of the client detecting/warning about not-trivial forking
> > seems worthwhile too, though, assuming it doesn't already (AIUI it
> > doesn't).
>
> It does warn??? if its heard the fork and its on the lower difficulty
> side. Extending that to also alert if its on the winning side and the
> fork is long enough might be wise, though I have a little concern that
> it'll be mistaken to be more dependable than it would be.
Still, it would have meant that all 0.8 users would have immediatley
been told that something was wrong. I don't know to what extent it
was luck that this was dealt with as promptly and efficiently as it
was, but to the extent that luck was involved, a slew of 0.8 users
shouting in various places "wtf is going on" couldn't but help in
reducing the element of luck if something similar were to happen again.
roy

2023-06-07 11:39:05 UTC

- reply

📅 Original date posted:2013-03-13
📝 Original message:On Wed, Mar 13, 2013 at 09:14:03PM +0000, Luke-Jr wrote:
> On Wednesday, March 13, 2013 9:06:44 PM Andy Parkins wrote:
> > On Wednesday 13 Mar 2013 12:56:29 Luke-Jr wrote:
> > > Here's a simple proposal to start discussion from...
> >
> > It seems to me that the biggest failure was not the development of two
> > chains, but the assurance to users (by the client) that their transactions
> > were confirmed.
>
> These are both the same thing.
The idea of the client detecting/warning about not-trivial forking
seems worthwhile too, though, assuming it doesn't already (AIUI it
doesn't).
I don't know if there's any automatic monitoring for forks, but if not
I would assume that the core devs and/or Bitcoin Foundation would be
planning to put some in place. But there's no reason I can see why
end users clients should't be warning of such situations, too, when
they can (obviously they won't always be aware of the fork).
roy

2023-06-07 11:37:06 UTC

- reply

📅 Original date posted:2013-03-12
📝 Original message:> clients are anyway keeping, and re-relaying, their own transactions
> and hence it would mean only little, and only little for clients.
Not all end-user clients are always-on though

2023-06-07 10:42:01 UTC

- reply

📅 Original date posted:2012-11-29
📝 Original message:I'd still like to understand the rationale for having the merchant
broadcast the transaction - it seems to add complexity and create edge
cases.
How about this as an alternative proposal:
The buyer's client prepares the transaction and computes its txid. It
then sends a ValidatePurchase message to the merchant containing the
proposed Outputs and a copy of the merchant_data along with the txid.
Assuming the proposed payment is accepted as valid by the merchant,
the buyer's client simply broadcasts the pre-prepared transaction in
the normal way, and it is the merchant's responsibility to watch for
this transaction to arrive over the p2p network/blockchain to complete
the purchase. (So if the merchant rejects the purchase at the
ValidatePurchase stage, they never get to see the transaction that the
buyer prepared, and there's therefore no need for a send-to-self to
cancel it.)
An optional RequestReceipt message (perhaps containing the
merchant_data and txid) can be sent by the client after the
transaction has been broadcast - but by making this explicitly
optional it forces the merchant to rely on seeing the bitcoin
transaction to 'commit' the payment and not on the RequestReceipt
message.
As far as I can see this proposal has no edge cases where the buyer
and merchant have differing ideas as to whether the transaction has
'comitted' - or at least, no more edge cases than the standard bitcoin
protocol has.
roy

2023-06-07 10:41:48 UTC

- reply

📅 Original date posted:2012-11-28
📝 Original message:> If a Receipt is not received for any reason (timeout, error) and
> Payment.transactions has not been broadcast by the merchant on the
> Bitcoin p2p network, then the Bitcoin client should assume that the
> payment failed, inform the customer that the payment failed, and
> return coins involved in the transaction to the customer's wallet.
I'm not sure I understand the rationale for this. In the above
scenario the buyer has no way to determine whether the merchant still
has a copy of the transaction that they could broadcast in future.
Maybe there is simply a systems problem at the merchant which has
temporarily delayed the transaction broadcast. Or maybe a dishonest
merchant deliberately engineered this situation in an attempt to
mislead the buyer as to the status of their payment.
Either way, having the buyer think the coins have been returned to
their wallet - only to disappear from their wallet again at some later
time - would seriously damage user confidence in Bitcoin IMHO.
It seems to me that the first thing the buyer should do given the
protocol as it stands is simply resend the Payment message - if there
was a temporary problem then resending the payment message (with the
same signed transation) might resolve the sitution.
If after several retries the status of the transaction is still
undefined then it's really not clear what to do, but it seems
desireable to have the client take steps so that it can return to a
state of certainly about its wallet balance as quickly as possible.
Two things I can imagine that the buyer might want their client to do
at this point are:
* broadcast the transaction itself, so they are sure the payment
transaction will make it into the blockchain without any further
action on their part, or
* invalidate the transaction by immediately broadcasting a
pay-to-self transaction that spends one or more of the same outputs
that the payment transaction spends (and treat the funds as part of
the unconfirmed balance until this pay-to-self transaction
confirms). This ensures the merchant can't subsequently use a
transaction which the buyer thinks has failed
It seems to me it would be simpler and cleaner if the buyer just
always broadcasted the transaction on the p2p network, regardless of
whether the Invoice includes a receiptURI. If a receiptURI is
included, the buyer's client would also include the transaction in the
Purchase message. The merchant then tries to broadcast the
transaction as well (unless their bitcoind has already seen it, which
may well be the common case). This approach seems to me to have fewer
nasty edge cases.s
roy