š
Original date posted:2013-05-21
š Original message:Not at all - ACK from me, fwiw. Any attempt at a double spend should be
shouted from the housetops.
What Miners should do with that is still up for debate, it seems. My
opinion is that they should hold on and attempt to confirm the first,
letting it go only if a conflicting transaction is mined elsewhere. (Let
your Yes mean Yes...) But I understand the contrary arguments.
On 21 May 2013 17:04, Gregory Maxwell <gmaxwell at gmail.com> wrote:
> On Mon, May 20, 2013 at 9:39 PM, Gavin Andresen <gavinandresen at gmail.com>
> wrote:
> > I'm very much in favor of double-spend propagation across the network.
>
> Absolutely.
>
> (to the list:) Is there anyone who is not? (assuming that it doesn't
> allow arbitrary traffic multiplication, which is easily solved)
>
>
> ------------------------------------------------------------------------------
> Try New Relic Now & We'll Send You this Cool Shirt
> New Relic is the only SaaS-based application performance monitoring service
> that delivers powerful full stack analytics. Optimize and monitor your
> browser, app, & servers with just a few lines of code. Try New Relic
> and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
> _______________________________________________
> 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/20130521/bf2601af/attachment.html>;
Robert Backhaus [ARCHIVE] /
npub1l2ā¦4hapw
2023-06-07 17:02:19
in reply to nevent1qā¦z9f3
Author Public Key
npub1l2n4ksu6cjucm97ffzss5xtrqew80wgqr3tmfr5sxcm2lhmxx6nqp4hapwPublished at
2023-06-07 17:02:19Event JSON
{
"id": "c20224e37cb72052674137573c3560e59e4b49ab603ea832a587f4f8a90a3158",
"pubkey": "faa75b439ac4b98d97c948a10a1963065c77b9001c57b48e903636afdf6636a6",
"created_at": 1686150139,
"kind": 1,
"tags": [
[
"e",
"e2b0d4c9e9ef91bcdbcf2583000e9ebb8fa15ef27e8a01c38f0772dbda8190a9",
"",
"root"
],
[
"e",
"32c1aa9233cd1c9be52db1ba9b0b6e2bbd11463917f40aa9ef2382e7ac3456b8",
"",
"reply"
],
[
"p",
"4aa6cf9aa5c8e98f401dac603c6a10207509b6a07317676e9d6615f3d7103d73"
]
],
"content": "š
Original date posted:2013-05-21\nš Original message:Not at all - ACK from me, fwiw. Any attempt at a double spend should be\nshouted from the housetops.\n\nWhat Miners should do with that is still up for debate, it seems. My\nopinion is that they should hold on and attempt to confirm the first,\nletting it go only if a conflicting transaction is mined elsewhere. (Let\nyour Yes mean Yes...) But I understand the contrary arguments.\n\n\nOn 21 May 2013 17:04, Gregory Maxwell \u003cgmaxwell at gmail.com\u003e wrote:\n\n\u003e On Mon, May 20, 2013 at 9:39 PM, Gavin Andresen \u003cgavinandresen at gmail.com\u003e\n\u003e wrote:\n\u003e \u003e I'm very much in favor of double-spend propagation across the network.\n\u003e\n\u003e Absolutely.\n\u003e\n\u003e (to the list:) Is there anyone who is not? (assuming that it doesn't\n\u003e allow arbitrary traffic multiplication, which is easily solved)\n\u003e\n\u003e\n\u003e ------------------------------------------------------------------------------\n\u003e Try New Relic Now \u0026 We'll Send You this Cool Shirt\n\u003e New Relic is the only SaaS-based application performance monitoring service\n\u003e that delivers powerful full stack analytics. Optimize and monitor your\n\u003e browser, app, \u0026 servers with just a few lines of code. Try New Relic\n\u003e and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may\n\u003e _______________________________________________\n\u003e Bitcoin-development mailing list\n\u003e Bitcoin-development at lists.sourceforge.net\n\u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130521/bf2601af/attachment.html\u003e",
"sig": "047c2c123c5d002d2932c430efcc6243ead42c1a02d631c315435e17da0fbce5b37025d71c2d26e1c959fb0bfae09a13d58d1e86a1925e3d4202f882610e2432"
}