Michael Gronager [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2012-01-28 to 2014-02-20
💬 Posted a total of 47 messages
📚 Participated in the following categories: Bitcoin-development, RFC, BIP proposal
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-07 15:13:28

- reply

📅 Original date posted:2014-02-20
📝 Original message:As I see the BIP it is basically stressing that ver 1 transactions are malleable.
It then addresses the need for unmalleable transactions for e.g. spending unconfirmed outputs in a deterministic way (i.e. no 3rd party can sabotage) - this transaction type is defined as ver 3.
A lot of clients today spend unconfirmed outputs (even bitcoin-qt) and as such make an implicit assumption that this is kind of safe, which it is not - it can be intervened and sabotaged through tx malleability.
What I suggested was to ensure that a subclass of version 1 transactions become unmalleable - namely those with sighash=all. Note that only the sender can modify the sighash as it is part of the hash signed. So instead of defining a version 3, we could constrain version 1 txes with sighash=all to have a unmalleable hash. If you e.g. would like to still have a sighash=all type of transaction with malleable features you can simply use that sighash=all today is checked for using sighash&0x1f=sighash_all, so just OR'ing with 0x20 or 0x40 will get you the 'old' feature.
I do however buy the argument of Peter and Gregory that there might exist unpublished transactions out there that does not even conform to the DER rules etc, and as such we cannot forbid them from being mined, nor can we timestamp them and include 'only the old ones'. Hence we cannot change the consensus rule for version 1 transactions - and only changing the relay rules will not provide a certain guarantee.
So, I think the two line argument for the BIP is as follows:
1. We cannot change the consensus rules for version 1 transactions as that might invalidate unpublished non-standard transactions (= voiding peoples money, which is a line we don't want to cross)
2. The prime usecase for unmalleable transactions is being able to spend unconfirmed outputs - this is done today by almost all clients, but it is really broken. Hence a need for a fix asap.
I am all in favor for the BIP, but I expect the realistic timeline for enforced version 3 transactions is roughly one year, which is better than two, but it would have been nice to get it faster...
/M
On Feb 19, 2014, at 10:11 PM, Pieter Wuille <pieter.wuille at gmail.com> wrote:
> On Wed, Feb 19, 2014 at 9:28 PM, Michael Gronager <gronager at mac.com> wrote:
>> I think that we could guarantee fewer incidents by making version 1 transactions unmalleable and then optionally introduce a version 3 that supported the malleability feature. That way most existing problematic implementations would be fixed and no doors were closed for people experimenting with other stuff - tx v 3 would probably then be called experimental transactions.
>
> Just to be clear: this change is not directly intended to avoid
> "incidents". It will take way too long to deploy this. Software should
> deal with malleability. This is a longer-term solution intended to
> provide non-malleability guarantees for clients that a) are upgraded
> to use them b) willing to restrict their functionality. As there are
> several intended use cases for malleable transactions (the sighash
> flags pretty directly are a way to signify what malleabilities are
> *wanted*), this is not about outlawing malleability.
>
> While we could right now make all these rules non-standard, and
> schedule a soft fork in a year or so to make them illegal, it would
> mean removing potential functionality that can only be re-enabled
> through a hard fork. This is significantly harder, so we should think
> about it very well in advance.
>
> About new transaction and block versions: this allows implementing and
> automatically scheduling a softfork without waiting for wallets to
> upgrade. The non-DER signature change was discussed for over two
> years, and implemented almost a year ago, and we still notice wallets
> that don't support it. We can't expect every wallet to be instantly
> modified (what about hardware wallets like the Trezor, for example?
> they may not just be able to be upgraded). Nor is it necessary: if
> your software only spends confirmed change, and tracks all debits
> correctly, there is no need.
>
> --
> Pieter
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140220/d16136fe/attachment.sig>

2023-06-07 15:09:58

- reply

📅 Original date posted:2013-11-25
📝 Original message:Hi Christian,
Cool - thanks for posting - agree, that it would be nice to normalize
the results with block size - so divide by size and:
1. see if there is a correlation (we all presume there still is)
2. plot the delay graph as e.g. normalized to the averaged blocksize or
lets define a "standard block size" of 200kb or what ever so we can
compare the plot btw days.
Also, does the correlation of propagation times hold for transaction
sizes as well (would be ice to find the logical t0 and the constant - I
guess the interesting measure is not kb but signatures, so number of
inputs - some correlation with size though).
Best,
Michael
On 24/11/13, 17:37 , Christian Decker wrote:
> Sure thing, I'm looking for a good way to publish these measurements,
> but I haven't found a good option yet. They are rather large in size,
> so I'd rather not serve them along with the website as it hasn't got
> the capacity. Any suggestions? If the demand is not huge I could
> provide them on a per user basis.
> --
> Christian Decker
>
>
> On Sun, Nov 24, 2013 at 5:26 PM, Gregory Maxwell <gmaxwell at gmail.com> wrote:
>> On Sun, Nov 24, 2013 at 8:20 AM, Christian Decker
>> <decker.christian at gmail.com> wrote:
>>> Since this came up again during the discussion of the Cornell paper I
>>> thought I'd dig up my measurement code from the Information
>>> Propagation paper and automate it as much as possible.
>>
>> Could you publish the block ids and timestamp sets for each block?
>>
>> It would be useful in correlating propagation information against
>> block characteristics.
>
> ------------------------------------------------------------------------------
> Shape the Mobile Experience: Free Subscription
> Software experts and developers: Be at the forefront of tech innovation.
> Intel(R) Software Adrenaline delivers strategic insight and game-changing
> conversations that shape the rapidly evolving mobile landscape. Sign up now.
> http://pubads.g.doubleclick.net/gampad/clk?id=63431311&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 10:41:07

- reply

📅 Original date posted:2012-11-27
📝 Original message:> No, the point of using X509 certs is to get a verified identity (a
> domain name) on the receipt, this is needed for multi-factor
> authentication. You can't do that without some kind of third party
> asserting to an identity.
Agree that you need a third party to verify identity. But the verification policy of sites is the job for a payment provider not a payment technology. So if you would like verification of the site you could just sign the memo using standard S/MIME - why mix it with the payment protocol?
Further, it is controversial use of the host key to use it for digital signing of documents, and not even within the policy of a host certificate as far as I recall.
The problem you are trying to tackle is that we don't have an ID solution on the internet today for this purpose. Certificates for signing messages are distributed freely and insecurely only based on temporarily having an email from within an organization, and the host certificates are meant for SSL handshakes. Funnily, any CA can issue digital certificates for email signing for any domain, even though they don't own them, and without notifying the owner. DANE actually solves this, but until then using the host certificates is unintended use, it is cryptographically a nice solution, but legally and standard-wise a hack.
/M