Gmail [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-04-20 to 2014-06-25
💬 Posted a total of 7 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:19

- reply

📅 Original date posted:2014-06-25
📝 Original message:> On Jun 25, 2014, at 10:15, slush <slush at centrum.cz> wrote:
> Good standard must be explicit as much as possible. Having million optional fields with ambiguous meaning is even worse than not having these fields.
+1. BIP70 is important. We want to keep it very simple and generalized, or there is a very real risk that implementers will either not bother with it or implement it in buggy, poorly standardized ways.
Any information not required by the machine should only exist in human-oriented fields (namely, the memo field).
Let's try to avoid ending up with another horrendously complicated, edge-case-oriented protocol like we programmers frequently complain about.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1593 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140625/a3be5f65/attachment.p7s>

2023-06-07 15:23:18

- reply

📅 Original date posted:2014-06-24
📝 Original message:> On Jun 24, 2014, at 16:12, Gavin Andresen <gavinandresen at gmail.com> wrote:
>
> It would be silly to add a "generic stuff" field inside a container format that ALREADY has all the mechanisms necessary for forwards and backwards extensibility.
I agree. It would be even sillier to start specifying container formats for random one-off "that would be kind of nice, I guess" features.
How about exchange rate? Sharing links? Referral information? Any of these things are just as deserving of specification (and just as arbitrary).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1593 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140624/d2ebb0cc/attachment.p7s>

2023-06-07 15:23:17

- reply

📅 Original date posted:2014-06-24
📝 Original message: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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140624/27e30be9/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1593 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140624/27e30be9/attachment.p7s>

2023-06-07 15:23:16

- reply

📅 Original date posted:2014-06-24
📝 Original message:> On Jun 24, 2014, at 10:32, slush <slush at centrum.cz> wrote:
>
> Sounds like marketing bullshit to me. It does not have even statistical meaning; well, you can "save" a lot of satoshis, but nobody tell you that the merchant cut you on BTC/USD exchange rate in tens of %.
People would also abuse this feature in the same way amazon (and other sales sites) abuse the definition of "save". For example, Amazon will indicate that you're getting x% off by shopping at amazon, but all that number really means is x% off MSRP. In reality, every website has the same price. I have no doubt that merchants would put similarly meaningless and/or misleading data in this field.
I agree, the memo field is appropriate for this data.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1593 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140624/bbd4c63a/attachment.p7s>

2023-06-07 15:21:49

- reply

📅 Original date posted:2014-05-20
📝 Original message: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?
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1593 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140520/b680ca83/attachment.p7s>

2023-06-07 15:21:18

- reply

📅 Original date posted:2014-05-12
📝 Original message:What about 0 confirmation inputs?
Mightn't this make tiny "spam" transactions unsafely inexpensive?
> On May 12, 2014, at 20:21, Peter Grigor <peter at grigor.ws> wrote:
>
>
> I propose the transaction fee should be calculated from a percentage of the input amount divided by the confirmations of the input multiplied by the number of inputs.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140512/58f4b564/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1593 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140512/58f4b564/attachment.p7s>

2023-06-07 15:21:18

- reply

2023-06-07 15:19:02

- reply

📅 Original date posted:2014-04-20
📝 Original message:People in the Bitcoin community are sometimes resistant to the idea of using the word "credit" as a unit of Bitcoin, because Bitcoin is not a credit-based system.
However, given that the average person has close to no understanding of what "credit" means, and probably no concern for the distinction even if they do know, it may be wise to use the futuristic and easily understandable "credit" as our human-friendly unit.
Do others agree that "credits" as a unit of account has a desirable futuristic connotation?
Will
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1593 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140420/b90be90b/attachment.p7s>