<unnamed>

Public Key

npub1nc78dlt7hp3v5dl32qu3m678h2j0ss374glcjnz8df75xcx7ngpq4gw452

Profile Code

nprofile1qqsfu0rkl4ltsck2xlc4qwgaa0rm4f8cggl250uff3rk5l2rvr0f5qspzpmhxue69uhkummnw3ezuamfdejs8z9pdq

Publishing to

nostr.wine

Last Notes

2023-06-07 17:13:28 CEST

- 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 17:13:24 CEST

- reply

📅 Original date posted:2014-02-19
📝 Original message:Why introduce a new transaction version for this purpose ? Wouldn't it be more elegant to simply let:
1. the next bitcoin version "prettify" all relayed transactions as deterministic transactions fulfilling the scheme 1-6 effectively blocking any malleability attack? If miners would upgrade then all transactions in blocks would have a deterministic hash.
2. In a version later one could block relay of non deterministic transactions, as well as the acceptance of blocks with non-confirming transactions.
To non-standard conforming clients this "prettify" change of hash would be seen as a constant malleability attack, but given the "prettify" code it is to fix any client into producing only conforming transactions, just by running the transaction through it before broadcast.
There is a possible fork risk in step 2. above - if a majority of miners still havn't upgraded to 1 when 2 is introduced. We could monitor % non conforming transaction in a block and only introduce 2. once that number is sufficiently small for a certain duration - criteria:
* Switch on forcing of unmalleable transactions in blocks when there has been only conforming transactions for 1000 blocks.
On Feb 13, 2014, at 1:47 AM, Gregory Maxwell <gmaxwell at gmail.com> wrote:
> On Wed, Feb 12, 2014 at 4:39 PM, Alex Morcos <morcos at gmail.com> wrote:
>> I apologize if this has been discussed many times before.
>
> It has been, but there are probably many people like you who have not
> bothered researching who may also be curious.
>
>> As a long term solution to malleable transactions, wouldn't it be possible
>> to modify the signatures to be of the entire transaction. Why do you have
>> to zero out the inputs? I can see that this would be a hard fork, and maybe
>> it would be somewhat tricky to extract signatures first (since you can sign
>> everything except the signatures), but it would seem to me that this is an
>> important enough change to consider making.
>
> Because doing so would be both unnecessary and ineffective.
>
> Unnecessary because we can very likely eliminate malleability without
> changing what is signed. It will take time, but we have been
> incrementally moving towards that, e.g. v0.8 made many kinds of
> non-canonical encoding non-standard.
>
> Ineffective— at least as you describe it— because the signatures
> _themselves_ are malleable.
>
> ------------------------------------------------------------------------------
> Android apps run on BlackBerry 10
> Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
> Now with support for Jelly Bean, Bluetooth, Mapview and more.
> Get your Android app in front of a whole new audience. Start now.
> http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
-------------- 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/20140219/95dc03a4/attachment.sig>

2023-06-07 17:09:23 CEST

- reply

📅 Original date posted:2013-11-13
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi John,
Thanks for the feedback - comments below:
>> However, it occurred to me that things can in fact be calculated even
>> simpler: The measured fork rate will mean out all the different pool
>> sizes and network latencies and will as such provide a simple number we
>> can use to estimate the minimum fee.
>
> Are you sure about that? You are assuming linearity where none may exist.
Well, my work from last week and now is a model. A model enabling you to
easily calculate the minimum fee and as a miner which transaction to
include to not shoot yourselves in the foot risking to create an
orphaned block.
The assumption that there is a linearity between block size and latency
is shown pretty well in the paper by Decker et. al (see last weeks
post). What I add this week is mainly more up to date numbers and a
formula dependent only of data that is easy to measure. (fork rate and
block size).
>
> Are those stats accurate? Have any pool operators at least confirmed that the
> orphaned blocks that blockchain.info reports match their own records?
Probably not - but the are at least a minimum - in case they are higher,
the fee should go up further.
>
> My gut feeling is to relay all orphaned blocks. We know that with a high
> investment and sybil attack as blockchain.info has done you can have better
> awareness of orphaned blocks than someone without those resources. If having
> that awareness is ever a profitable thing we have both created an incentive to
> sybil attack the network and we have linked profitability to high up-front
> capital investments.
Another way to measure latency is to setup a node that only listens but
do not relay data. By measuring the propagation of blocks of different
size as well as transactions, you can get a propagation distribution and
from that an average. However, the relevant propagation time is the one
between the pools/(single miners). Which you cannot assess using this
scheme - however, it would be nice to compare it to the orphan block scheme.
>
> With relayed orphans you could even have P2Pool enforce an optimal tx inclusion
> policy based on a statistical model by including proof of those orphans into
> the P2Pool share chain. P2Pool needs to take fees into account soon, but simply
> asking for blocks with the highest total fees or even highest fee/kb appears to
> be incomplete according to what your and Peter's analysis is suggesting.
Indeed, and nice... But note that it is never of benefit for the miner
to include a transaction with a fee of less than ~0.0004BTC - unless it
is linked to another transaction that pay an extra fee.
There have been a lot of assumptions on the fee size and generally it
has been linked to the bitcoin exchange rate. This analysis shows that
this is wrong. Also it shows that the scalability of bitcoin is directly
linked to the network and node latency (with the current latency it will
never beneficial for miners to include more than ~30k transactions in a
block or ~70 pr second resulting in ~10MB blocks).
However, halving the latency will double the capacity, down to the
minimum which is governed by the speed of light.
>
>
> ------------------------------------------------------------------------------
> DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps
> OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access
> Free app hosting. Or install the open source package on any LAMP server.
> Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native!
> http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBAgAGBQJSg+H7AAoJEKpww0VFxdGRn+gIAIgju90DED5r//USqKvkQsYI
JDj0tLBLMg9BPXOOt3eJ+NX4YE4lW+QkwqDd/swuJxLmj0l9BQKgt1lTb/f0P/cY
GdE14gh5EYlvNzY1h0TGKcMe8NTWXU0/tC+Clpy4sqBHPXW/eF/77sLQUnFRrLKi
sT48aHOOFUdBLdlyylUzzevh/FFVLidkKqV031tv52+BFHcTFd4kRPwZXgBSs9YH
U66MkJ4ytAqeOfJue9n7Qn4kJF9kNIhRpqTrtapqu8jglLfuYlJ3s5fwaw9FxQdR
+On4IWeXzURQ6tcVRCovCq/2lxRKIbYGlW7HGVASjRmm68/+8YUAfFsYFl6DIgA=
=9tbL
-----END PGP SIGNATURE-----

2023-06-07 17:09:15 CEST

- reply

📅 Original date posted:2013-11-07
📝 Original message:Mike, Pieter,
My writeup outlines a framework for good approximation to a minimal fee
as well as the optimal block size. The model has basically just one
parameter, the propagation time - if that goes down, so can the fee.
(Well there is another parameter too, the time btw blocks, which
currently with the current hash acceleration is more like 400 than 600).
Also seconding Mike, that, yes, it would be tremendously useful to track
propagation times and other things on the network to help us all decide
the proper settings.
Finally, it would be great if someone from academia would grab the ball
and do the full probabilistic analysis based on my outline.
Michael
On 7/11/13, 16:22 , Mike Hearn wrote:
> I think trying to help miners figure out the propagation/fees tradeoff
> at the moment is a non-starter until we understand it better ourselves.
> A server that tracks and records block propagation times, how many fees
> per passed up per block, orphan stats per size bucket etc would be
> tremendously helpful.
>
>
> On Thu, Nov 7, 2013 at 4:19 PM, Pieter Wuille <pieter.wuille at gmail.com
> <mailto:pieter.wuille at gmail.com>> wrote:
>
> Correcting myself:
>
> On Thu, Nov 7, 2013 at 4:00 PM, Pieter Wuille
> <pieter.wuille at gmail.com <mailto:pieter.wuille at gmail.com>> wrote:
> > I believe that C. Decker's paper used measurements for propagation
> > delays for blocks 180000-190000, which happened between may and juli
> > 2012. The latest bitcoind/bitcoin-qt release at the time was 0.6.3.
>
> They did use data from blocks 20000-210000, september-november 2012.
> That was still before the 0.8 release, however.
>
> --
> Pieter
>
> ------------------------------------------------------------------------------
> November Webinars for C, C++, Fortran Developers
> Accelerate application performance with scalable programming models.
> Explore
> techniques for threading, error checking, porting, and tuning. Get
> the most
> from the latest Intel processors and coprocessors. See abstracts and
> register
> http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> <mailto:Bitcoin-development at lists.sourceforge.net>
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>
>
> ------------------------------------------------------------------------------
> November Webinars for C, C++, Fortran Developers
> Accelerate application performance with scalable programming models. Explore
> techniques for threading, error checking, porting, and tuning. Get the most
> from the latest Intel processors and coprocessors. See abstracts and register
> http://pubads.g.doubleclick.net/gampad/clk?id=60136231&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 17:04:56 CEST

- reply

📅 Original date posted:2013-07-23
📝 Original message:>
> The only way to do this safely at an SPV security assumption, is by
> having an address-indexed committed merkle UTXO-set tree, like the
> one proposed by Alan Reiner, and being implemented by Mark
> Friedenback. I know Michael Gronager has something similar implemented,
> but I don't know whether it is script-indexed.
The MerkleTrie I have in libcoin is indexed on UTXOs only. However, adding
an extra index for scripts would be pretty easy (half day of coding), or even having the two merged into one index.
The burden imposed on validating nodes for keeping such an index is really minimal. When using the UTXO MerkleTrie I switch off the sqlite index of these and vise versa, so there are hardly any measurable timing difference.
However, the MerkleTrie index is currently re-build on startup (which takes ~30 sec on my laptop), keeping it synced with disk would be optimal and in the long run necessary as even the UTXO set will grow over time.
> To be actually useful,
> it likely needs to be enforced by miners - putting a significant
> burden on validation nodes. Still, if it can be done efficiently,
> I think this would be worth it, but more research is needed first in
> any case.
>

2023-06-07 17:04:45 CEST

- reply

📅 Original date posted:2013-07-17
📝 Original message:Hi Wendell,
What Peter describes (a hash of the current set of UTXOs as part of the coinbase) is already implemented in libcoin, on which you can easily build both a bitcoind and any client. Libcoin is a library originally based on the satoshi client, and as such it is compatible/replacable with "master".
Have a look at github.com/libcoin/libcoin and look in the BlockChain.h/cpp and the MerkleTrie classes then you can see how it works.
What is missing from libcoin is a scheme to bootstrap the hash of UTXOs, there is some stub code for a p2pool like mining scheme ensuring several UTXO hashes every 10 minutes, but I will not have time to finalize it the first few months - anyone are of course welcome to help out ;)
Michael
On 17/07/2013, at 09:37, Wendell <w at grabhive.com> wrote:
> Peter,
>
> This sounds like a _very_ good idea for a desktop client, and probably acceptable to users so long as we take available disk space into consideration, and only ever use a fraction of it.
>
> Will you implement this?
>
> -wendell
>
> grabhive.com | twitter.com/grabhive
>
> On Jul 17, 2013, at 12:58 PM, Peter Todd wrote:
>
>> So what's useful about that? Basically it means your node starts with
>> the same security level, and usefulness to the network, as a SPV node.
>> But over time you keep downloading blocks as they are created, and with
>> whatever bandwidth you have left (out of some user-configurable
>> allocation) you download additional blocks going further and further
>> back in time. Gradually your UTXO set becomes more complete, and over
>> time you can verify a higher and higher % of all valid transactions.
>> Eventually your node becomes a full node, but in the meantime it was
>> still useful for the user, and still contributed to the network by
>> relaying blocks and an increasingly large subset of all transactions.
>> (optionally you can store a subset of the chain history too for other
>> nodes to bootstrap from) You've also got better security because you
>> *are* validating blocks, starting off incompletely, and increasingly
>> completely until your finally validating fully. Privacy is improved, for
>> both you and others, by mixing your transactions with others and adding
>> to the overall anonymity set.
>>
>> In the future we'll have miners commit a hash of the UTXO set, and that
>> gives us even more options to, for instance, have relayed transactions
>> include proof that their inputs were valid, allowing all nodes to relay
>> them safely.
>
> ------------------------------------------------------------------------------
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk_______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130717/d6c0fe64/attachment.sig>

2023-06-07 13:37:15 CEST

- reply

📅 Original date posted:2013-03-12
📝 Original message:Well a reversed upgrade is an upgrade that went wrong ;)
Anyway, the incident makes it even more important for people to upgrade, well except, perhaps, for miners...
Forks are caused by rejection criteria, hence:
1. If you introduce new rejection criteria in an upgrade miners should upgrade _first_.
2. If you loosen some rejection criteria miners should upgrade _last_.
3. If you keep the same criteria assume 2.
/M
On 12/03/2013, at 13:11, Mike Hearn <mike at plan99.net> wrote:
> I'm not even sure I'd say the upgrade "went wrong". The problem if
> anything is the upgrade didn't happen fast enough. If we had run out
> of block space a few months from now, or if miners/merchants/exchanges
> had upgraded faster, it'd have made more sense to just roll forward
> and tolerate the loss of the older clients.
>
> This really reinforces the importance of keeping nodes up to date.
>
> On Tue, Mar 12, 2013 at 12:44 PM, Pieter Wuille <pieter.wuille at gmail.com> wrote:
>> On Tue, Mar 12, 2013 at 11:13:09AM +0100, Michael Gronager wrote:
>>> Yes, 0.7 (yes 0.7!) was not sufficiently tested it had an undocumented and unknown criteria for block rejection, hence the upgrade went wrong.
>>
>> We're using "0.7" as a short moniker for all clients, but this was a limitation that all
>> BDB-based bitcoins ever had. The bug is simply a limit in the number of lock objects
>> that was reached.
>>
>> It's ironic that 0.8 was supposed to solve all problems we had due to BDB (except the
>> wallet...), but now it seems it's still coming back to haunt us. I really hated telling
>> miners to go back to 0.7, given all efforts to make 0.8 signficantly more tolerable...
>>
>>> More space in the block is needed indeed, but the real problem you are describing is actually not missing space in the block, but proper handling of mem-pool transactions. They should be pruned on two criteria:
>>>
>>> 1. if they gets to old >24hr
>>> 2. if the client is running out of space, then the oldest should probably be pruned
>>>
>>> clients are anyway keeping, and re-relaying, their own transactions and hence it would mean only little, and only little for clients. Dropping free / old transaction is a much a better behavior than dying... Even a scheme where the client dropped all or random mempool txes would be a tolerable way of handling things (dropping all is similar to a restart, except for no user intervention).
>>
>> Right now, mempools are relatively small in memory usage, but with small block sizes,
>> it indeed risks going up. In 0.8, conflicting (=double spending) transactions in the
>> chain cause clearing the mempool of conflicts, so at least the mempool is bounded by
>> the size of the UTXO subset being spent. Dropping transactions from the memory pool
>> when they run out of space seems a correct solution. I'm less convinced about a
>> deterministic time-based rule, as that creates a double spending incentive at that
>> time, and a counter incentive to spam the network with your risking-to-be-cleared
>> transaction as well.
>>
>> Regarding the block space, we've seen the pct% of one single block chain space consumer
>> grow simultaneously with the introduction of larger blocks, so I'm not actually convinced
>> there is right now a big need for larger blocks (note: right now). The competition for
>> block chain space is mostly an issue for client software which doesn't deal correctly
>> with non-confirming transactions, and misleading users. It's mostly a usability problem
>> now, but increasing block sizes isn't guaranteed to fix that; it may just make more
>> space for spam.
>>
>> However, the presence of this bug, and the fact that a full solution is available (0.8),
>> probably helps achieving consensus fixing it (=a hardfork) is needed, and we should take
>> advantage of that. But please, let's not rush things...
>>
>> --
>> Piter
>
> ------------------------------------------------------------------------------
> Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester
> Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the
> endpoint security space. For insight on selecting the right partner to
> tackle endpoint security challenges, access the full report.
> http://p.sf.net/sfu/symantec-dev2dev
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

2023-06-07 12:44:26 CEST

- reply

📅 Original date posted:2012-12-03
📝 Original message:(Also posted on the forum: https://bitcointalk.org/index.php?topic=128900.0)
The amount of "dust" in the block chain is getting large and it is growing all the time. Currently 11% of unspent tx outputs (UTXO) are of 1Satoshi (0.00000001BTC), 32% is less than 0.0001BTC and 60% is less than 0.001BTC. (Thanks to Jan for digging out these numbers!)
This means that a huge part of the block chain is used for essentially nothing - e.g. the sum of the 11% is worth roughly 2 US cents !
The main source for these 1 Satoshi payouts is Sahtoshi Dice. And nothing wrong with that, however, we should work on ensuring that too many too small payments will not kill the size of the blockchain in the end - further, they are essentially too small to be included in other transaction as the added fee will often make it more expensive to remove them. Hence, there is no incentive to get rid of them.
I have an idea for a possible mitigation of this problem - introduction of demurrage - not as in it normal meaning as a percentage over time (see:http://en.wikipedia.org/wiki/Demurrage_(currency) btw, this has also been tried in freicoin), but as a mean to recycle pennies over time. The proposal is simple - UTXOs age out if not re-transacted - the smaller the coin the faster the aging:
1-99 Satoshi: lives for 210 blocks
100-9999 Satoshi: lives for 2100 blocks
10000-999999 Satoshi: lives for 21000 blocks
1000000-99999999 Satoshi: lives for 210000 blocks
Only amounts above 1BTC lives forever - (or we could even impose aging on those too..)
The aged coins are simply included in the block mining reward, creating another incentive for miners. Further, if we include all coins in this recycle scheme coins will never be lost forever.
This scheme will impose some lifetimes also on e.g. colored coins (hence you need to use a certain amount to borrow space on the blockchain for the time needed, or simply transact them).
If you like this I would be happy to write it into a BIP.
Thoughts ?

2023-06-07 12:41:07 CEST

- 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

2023-06-07 12:41:00 CEST

- reply

📅 Original date posted:2012-11-27
📝 Original message:>
> If a merchant/payment processor is willing to take the risk of zero or
> low confirmation transactions (because they are insured against it,
> for example), they were allowed to reply "accepted" immediately, and
> this would be a permanent proof of payment, even if the actual Bitcoin
> transaction that backs it gets reverted.
I guess that moves the discussion from developers to lawyers ;) Even though you send a signed receipt, if you can proof you didn't get the money, you will never be expected to deliver the goods. (and you can even write that in the the receipt ...)
So the SignedReceipt is legally not worth the bits it is composed of, hence I don't see the point in supporting it.
If you are selling atoms you can usually wait for N confirmations (even though you start shipping I guess you can recall a parcel within 144 blocks). If you are selling bits (like access to a site), you can revoke that access once you discover the transaction did not go through. So I can't find a use case where a Signed Receipt in the proposed form is advantageous.
/M

2023-06-07 12:40:54 CEST

- reply

📅 Original date posted:2012-11-27
📝 Original message:>
> The SignedReceipt message is useful in the sense that it shows
> confirmation by the merchant, but if you don't get one, you can still
> prove you paid the invoice. So from this perspective perhaps
> SignedReceipt should be renamed to Acceptance or something like that,
> and then the spec should call out that a signed invoice plus accepted
> Bitcoin transactions is mathematically a proof of purchase.
Which is why I find the "SignedReceipt" somewhat superfluous. If you implement a payment system, like bit-pay/wallet you are likely to double that through some sort of e-mail receipt anyway.
Further, the inclusion of x509 is not really needed in the spec - you don't need to sign the invoice with an x509, you can use the payment key. The proof would still be equally binding, and valid also for non holders of x509 (server) certificates (like normal people).
Finally, host certificates does not normally keep in their "purpose" S/MIME Signing. So you are bending the intended use of the x509 certificate anyway.
/M
>
> ------------------------------------------------------------------------------
> Monitor your physical, virtual and cloud infrastructure from a single
> web console. Get in-depth insight into apps, servers, databases, vmware,
> SAP, cloud infrastructure, etc. Download 30-day Free Trial.
> Pricing starts from $795 for 25 servers or applications!
> http://p.sf.net/sfu/zoho_dev2dev_nov
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development