Andy Alness [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-05-12 to 2014-06-24
💬 Posted a total of 5 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:23:17

- reply

📅 Original date posted:2014-06-24
📝 Original message:I somewhat agree with Will (but also with Mike, Jeff, and Charlie.) I
think the idea of letting consumers know advanced details about the
transaction is good and defining these with strong types is also good.
Maybe an arbitrary set of accounting line items would be more
palatable. You could have a line item for state sales tax for example,
or a cash back reward, or a merchant discount like the proposed,
whatever is applicable. It would be a list of amount / label tuples
maybe.
On Tue, Jun 24, 2014 at 12:00 PM, Gmail <will.yager at gmail.com> wrote:
> Ok, wanting structured data is a decent argument, but why this random
> arbitrary case in particular? There are hundreds of fields like this that
> people might want to use.
>
> If we're going to support one random cosmetic field, we might as well
> support them all with a generic structured data format.
>
> I'd rather we just didn't have this essentially pointless "feature" at all.
> Let's try and keep as much cruft as possible out of the payment protocol.
> The textual memo field is already more than sufficient.
>
> On Jun 24, 2014, at 11:48, Jeff Garzik <jgarzik at bitpay.com> wrote:
>
> I think there is nothing wrong with having a numeric memo field, which
> is effectively what this is. Structured rather than unstructured
> data.
>
>
> ------------------------------------------------------------------------------
> Open source business process management suite built on Java and Eclipse
> Turn processes into business applications with Bonita BPM Community Edition
> Quickly connect people, data, and systems into organized workflows
> Winner of BOSSIE, CODIE, OW2 and Gartner awards
> http://p.sf.net/sfu/Bonitasoft
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--
Andy Alness
Software Engineer
Coinbase
San Francisco, CA

2023-06-07 15:21:50

- reply

📅 Original date posted:2014-05-20
📝 Original message:Awesome! I'm assuming this is it:
https://bitcointalk.org/index.php?topic=156769.0
It would be interesting (at least to me) to take this a step further
and offer UDP as a full TCP replacement capable of STUN-assisted NAT
traversal and possibly swarmed blockchain syncs. It would require open
TCP nodes to facilitate "connection" establishment. It is obviously a
non-trivial amount of work but would be an interesting experiment.
Maybe BitTorrent's µTP protocol could be leveraged.
On Tue, May 20, 2014 at 12:17 PM, Jeff Garzik <jgarzik at bitpay.com> wrote:
> Yes, i spec'd out the UDP traversal of the P2P protocol. It seems
> reasonable especially for "inv" messages.
>
> On Tue, May 20, 2014 at 2:46 PM, Andy Alness <andy at coinbase.com> wrote:
>> Has there ever been serious discussion on extending the protocol to
>> support UDP transport? That would allow for NAT traversal and for many
>> more people to run effective nodes. I'm also curious if it could be
>> made improve block propagation time.
>>
>> On Tue, May 20, 2014 at 7:52 AM, Gmail <will.yager at gmail.com> wrote:
>>> Unlikely. I doubt any significant portion of miners in china will continue to mine on a china-specific chain, since it will certainly be outmined by non-Chinese miners, and will be orphaned eventually.
>>>
>>> More likely is that mining interests in china will make special arrangements to circumvent the GFwOC.
>>>
>>> Users who can't access the worldwide blockchain will notice horrendously slow confirmation times and other side effects.
>>>
>>>> On May 20, 2014, at 10:37, Eugen Leitl <eugen at leitl.org>
>>>>
>>>> Could a blockchain fork due to network split happen?
>>>>
>>>
>>> ------------------------------------------------------------------------------
>>> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
>>> Instantly run your Selenium tests across 300+ browser/OS combos.
>>> Get unparalleled scalability from the best Selenium testing platform available
>>> Simple to use. Nothing to install. Get started now for free."
>>> http://p.sf.net/sfu/SauceLabs
>>> _______________________________________________
>>> Bitcoin-development mailing list
>>> Bitcoin-development at lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>>
>>
>>
>>
>> --
>> Andy Alness
>> Software Engineer
>> Coinbase
>> San Francisco, CA
>>
>> ------------------------------------------------------------------------------
>> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
>> Instantly run your Selenium tests across 300+ browser/OS combos.
>> Get unparalleled scalability from the best Selenium testing platform available
>> Simple to use. Nothing to install. Get started now for free."
>> http://p.sf.net/sfu/SauceLabs
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>
> --
> Jeff Garzik
> Bitcoin core developer and open source evangelist
> BitPay, Inc. https://bitpay.com/
--
Andy Alness
Software Engineer
Coinbase
San Francisco, CA

2023-06-07 15:21:49

- reply

📅 Original date posted:2014-05-20
📝 Original message:Has there ever been serious discussion on extending the protocol to
support UDP transport? That would allow for NAT traversal and for many
more people to run effective nodes. I'm also curious if it could be
made improve block propagation time.
On Tue, May 20, 2014 at 7:52 AM, Gmail <will.yager at gmail.com> wrote:
> Unlikely. I doubt any significant portion of miners in china will continue to mine on a china-specific chain, since it will certainly be outmined by non-Chinese miners, and will be orphaned eventually.
>
> More likely is that mining interests in china will make special arrangements to circumvent the GFwOC.
>
> Users who can't access the worldwide blockchain will notice horrendously slow confirmation times and other side effects.
>
>> On May 20, 2014, at 10:37, Eugen Leitl <eugen at leitl.org>
>>
>> Could a blockchain fork due to network split happen?
>>
>
> ------------------------------------------------------------------------------
> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> Instantly run your Selenium tests across 300+ browser/OS combos.
> Get unparalleled scalability from the best Selenium testing platform available
> Simple to use. Nothing to install. Get started now for free."
> http://p.sf.net/sfu/SauceLabs
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--
Andy Alness
Software Engineer
Coinbase
San Francisco, CA

2023-06-07 15:21:16

- reply

📅 Original date posted:2014-05-12
📝 Original message:>
> It sounds OK to me, although we should all sleep on it for a bit. The
> reason this header exists is exactly because mobile code fetching random
> web resources can result in surprising security holes.
>
That's fair. From the server perspective, I'd argue that payment requests /
payments already need to be publicly accessible endpoints. Current
practical use requires support for cross-app/cross-device requests for
them. It seems like a reasonable logical extension to explicitly allow for
them to be accessed cross-site as well.
For this to be useful, someone would have to actually want to fully
> implement the payment protocol (with its own root cert store, ASN.1
> parsing, RSA etc) in browser-sandboxed Javascript rather than just
> providing a real app for people to download.
>
I think there is still value in fetching the payment request cross-site
even if the request payload is validated by a 3rd party using a more
conventional TLS/crypto suite. Exposing x.509/RSA/ASN.1/chain verification
functionality strikes me as a useful thing browsers could easily offer but
that's another discussion entirely but sure it could be done all in JS. In
certain environments downloading a "real app" isn't possible/practical.
> Is that really going to be popular, though? I think it's unclear.
>
It certainly won't be if there is no ability :)
-Andy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140512/1e519cbe/attachment.html>

2023-06-07 15:21:16

- reply

📅 Original date posted:2014-05-11
📝 Original message:Would it be a terrible idea to amend BIP 70 to suggest implementors include
a "Access-Control-Allow-Origin: *" response header for their payment
request responses? I don't think this opens up any useful attack vectors.
I ask because this would make it practical for pure HTML5 web wallets to
use the payment protocol entirely in-browser. Without this I think it would
be necessary for the server hosting the wallet's HTML to fetch payment
requests on the browser's behalf. This is somewhat inelegant and has
security/resource implications for the back-end.
-Andy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140511/0ad12a9d/attachment.html>