vv01f [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-03-14 to 2018-10-18
💬 Posted a total of 8 messages
📚 Participated in the following categories: Bitcoin-development, bitcoin-dev, Lightning-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-07 18:14:59

- reply

📅 Original date posted:2018-10-18
📝 Original message:I already pointed out a while ago that the separator could be the & and
the returning value is either an address or an array of addresses.
So no comma or other delimiter needed.
also I would suggest to call the parameter `address` and not a shortcut
for it as we are used to `message` and `amount` spelled out as well.
On 18.10.2018 16:20, Clark Moody via bitcoin-dev wrote:
> Since we don't know what sort of address changes will happen later on, you
> could make this future-proof by passing a list of addresses to `addr`.
>
> The syntax is
>
> bitcoin:<address>[?addr=<address>[,<address>[,<address>]]]
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 899 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20181018/088c2fc5/attachment.sig>

2023-06-07 18:13:51

- reply

📅 Original date posted:2018-07-24
📝 Original message:When I use the example of HTML forms …
```test.html
<!DOCTYPE html>
<html><head><title>test for URI schema</title>
<body><form method="get" action="./test.html">
<select multiple name="attr">
<option value="val1" selected>1</option>
<option value="val2" selected>2</option>
<option value="val3">3</option>
</select>
<input type="submit" value="send" />
</form></body></head></html>
```
The resulting URI is:
file:///tmp/test.html?attr=val1&attr=val2
That means that a URI attribute is not necessarily singular and can
indeed occur multiple times.
So as we do not have athority in our URI…
for URI = scheme:path[?query][#fragment]
where query=[key1=value1[&key2=value2]]
…under the circumstance that path has a newer standard we can implement
fallback with: query=[path=newerversion[&path=evennewerversion]]
…as our path is the address, resulting in e.g.:
bitcoin:p2pkh?[amount=value][&address=p2sh][&address=p2sh-p2wpkh][&address=bech32]
the effect should be
1. old clients ignore address attribute
2. supporting clients select the address attribute over the address
given in path *if* they support the format
3. future address formats do not need a new attribute
open to me would be:
* the order of the attributes and how this should be recognized/priorized
* is there any precedence for that multiple use of an attribute in URI
schemes?
I think order of attributes should remain irrelevant, thus supporting
clients should check all attributes of the same name and attributes
should be defined for repetitive (like address) or not (amount) in the
BIP. This will still not support sending different amounts to multiple
addresses and be consistent with the older version of the URI scheme.
On 24.07.2018 14:05, Federico Tenga via bitcoin-dev wrote:
> Hello everyone,
>
> With my team we are working on a walleting application which ideally will
> generate a bech32 address when receiving from a bech32 compatible wallet,
> and a P2WPKH-nested-in-P2SH address when receiving for a legacy wallet.
> However, it is of course impossible for the payee to know in advance the
> technological capabilities of the payer, so a solution could be to encode
> in a Bitcoin URI both bech32 and P2SH addresses in a way that legacy
> wallets only see the P2SH address, while new wallets can also see the
> bech32 address and use it to perform the transaction.
>
> In particular, to keep compatibility with BIP21, the <address> field of the
> URI can be used for the P2WPKH-nested-in-P2SH address and a new field (e.g.
> <segwitaddress> or <bech32address>), which will be ignored by legacy
> wallets, can be used to encode the bech32 address. The assumption here is
> that the wallets using such scheme will monitor incoming transaction both
> on the P2SH address and on the bech32 address.
>
> I did some research around and I did not find any proposal addressing the
> same issue, so my questions are (i) does anybody already proposed something
> going in the same direction and (ii) do you see any major drawback in the
> BIP21 compatible scheme proposed in this message?
>
> Thanks in advance,
>
> Federico
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 898 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180725/fdd0fc27/attachment.sig>

2023-06-07 18:13:37

- reply

📅 Original date posted:2018-07-11
📝 Original message:this is intended to fix the graphics
* as not scaleable bitmap/png
* with broken capitalization
* not easy editable plaintext for git
have a view[1] on the suggestion for an example[0].
[0]:
https://github.com/bitcoin/bips/blob/master/bip-0174/coinjoin-workflow.png
[1]: https://de.sharelatex.com/read/hrvvwcvhrbyz
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 898 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180711/960c3fc0/attachment.sig>

2023-06-07 18:13:26

- reply

📅 Original date posted:2018-07-05
📝 Original message:You can provide a reusable payment code (BIP-47) instead of an actual address. Unfortunately that not yet supported by the clients/apps most people use. Just that would be less a hurdle than providing a service that e.g. generates addresses from xpub.
Am July 4, 2018 6:08:43 PM UTC schrieb fred savage via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org>:
>you cannot specifically NOT support addrss reuse. on a blockchain where
>people can send you funds without your permission required to send you
>funds. so ALWAYS expect multiple payments to the same address
--
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

2023-06-07 15:29:25

- reply

📅 Original date posted:2015-02-02
📝 Original message:On 02.02.2015 15:17, Andreas Schildbach wrote:
>> Uff, I would expect YYYYMMDD there so it's human readable as well.
>
> Those strings are not meant to be read by humans. YYYYMMDD is more
> complicated than necessary, given that Bitcoin deals with seconds since
> epoch everywhere.
First that is a pitty .. as its simply a waste of storage.
but back to Pavol's point: IMHO no harm to anything, as Bitcoin never
has any valid timestamp below ~1230768000 (jan2009) and thus will always
have 10 digits.. you can easily identify 8 char long timestamp as the
proposed format.
And there never is anything wrong with having a transparent, human
readable option - especially when it saves 2 bytes in e.g. qr-codes.

2023-06-07 15:16:47

- reply

📅 Original date posted:2014-03-31
📝 Original message:Some users on bitcointalk[0] would like to have their vanity addresses
available for others easily to find and verify the ownership over a kind
of WoT. Right now they sign their own addresses and quote them in the
forums.
As I pointed out there already the centralized storage in the forums is
not secury anyhow and signed messages could be swapped easily with the
next hack of the forums.
Is that use case taken care of in any plans already?
I thought about abusing pgp keyservers but that would suit for single
vanity addresses only.
It seems webfinger could be part of a solution where servers of a
business can tell and proof you if a specific address is owned by them.
[0] https://bitcointalk.org/index.php?topic=502538
[1] https://bitcointalk.org/index.php?topic=505095
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 897 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140331/9ec544af/attachment.sig>

2023-06-07 15:15:40

- reply

📅 Original date posted:2014-03-14
📝 Original message:I think
* if we change to mBTC because your state currencys price for bitcoin
make this a valid option we will change again in future
* users do not like changes
* we should keep a good standard
A good standard should be
* built on standards (e.g. SI)
* backed by best practice: never force the user to take an option he
cannot change
* do not make changes without users permission
* take care of users at fault when entering 5.967 ot should be pointed
out before sending that e.g.
the sw understood 5967.000 000 00 BTC
instead of 5.967 000 00 BTC
because the user failed to use the correct delimiter.
For now a good standard is
* simply bitcoin as BTC with eight decimal places
or could be
* uBTC as SI prefix, probably using XBT as a symbol for compatibility
with other software
* satoshis (w. SI prefixes if numbers are to big) for regions where
decimal places in prices are uncommon
So I'd prefer:
Make the choice transparent to users and set a standard that the user
alway should be empowered to use all available decimal places.
And there should be a set of official test-cases for wallet software and
the desired behavior.

2023-06-07 15:14:26

- reply

📅 Original date posted:2014-03-27
📝 Original message:Companies can have a Cert with their name via CAcert. It requires some work though to get assured as an organisation.
Did you already think about what CA is to be trusted or do users need to do that. The least good decision in my POV would be to accept OS/browser built in CAs only.
Am 27.03.2014 um 11:08 schrieb Mike Hearn <mike at plan99.net>:
>> But these cases are the norm, rather than the exception.
>
> Well, you're lucky, you live in Berlin. Most of the payments I make with Bitcoin are online, to websites. So this will differ between people.
>
> I wonder how critical it is. Let's say you are paying for a meal. In your head the place you're at is just "the little Indian restaurant on the corner". In the companies register and therefore certificate it's something like "Singh Food GmbH". That's probably good enough to prevent shenanigans. Even if there's a virus on your phone, it can't really replace the cert with a random stolen one, otherwise your meal could show up like "IronCore Steel Inc" or something that's obviously bogus. It'd have to be an incredibly smart virus that knew how to substitute one name for a different one, from a large library of stolen identities, such that the swap seemed plausible. That sounds very hard, certainly too hard to bother with for stealing restaurant fees.
>
> And if a waiter at the restaurant is corrupt and they replace the cert with one that's for their own 1-man business "BP-Gupta" or something, OK, you might pay the wrong person by mistake. But eventually the corrupt waiter will be discovered and then someone will have proof of what they did. It's FAR more likely they'd just strip the signature entirely and try to convince you the restaurant doesn't use BIP70 at all.
>
> Still, if we want to fix this, one approach I was thinking about is to have a super-cheesy CA just for us that issues certs with addresses in them, for any name you ask for. That is, if you say you want a cert for "Shamrock Irish Pub, Wollishofen, Zurich, CH" then it either sends a postcard to that address with a code to check ownership of the address, or it checks ownership of the place on Google Maps (which does the same postcard trick but for free!).
>
> That doesn't work for vending machines, but perhaps we just don't care about those. If a MITM steals your lunch money, boo hoo.
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140327/5d27c649/attachment.html>