Roy Badami [ARCHIVE]

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2012-11-28 to 2015-06-24
💬 Posted a total of 65 messages
📚 Participated in the following categories: Bitcoin-development, bitcoin-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Public Key

npub1trckpcxmceskq4cykxgwxm63n8ugrjrpu5mk83c90e4upsf7d9gqf0f95j

Profile Code

nprofile1qqs93utqurduvctq2uztry8rdagen7ypeps72dmrcuzhu67qcylxj5qpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0ds50sdvu

Publishing to

relay.damus.io

nos.lol

Author Public Key

npub1trckpcxmceskq4cykxgwxm63n8ugrjrpu5mk83c90e4upsf7d9gqf0f95j

Show more details

Last Notes

2023-06-07 17:39:56

- reply

📅 Original date posted:2015-06-24
📝 Original message:Or put another way, lowering the block size limit (or cancelling an
increase) is a soft fork. Like all soft forks, a majority of the hash
power can force the soft fork to take place.
On Wed, Jun 24, 2015 at 10:05:42AM -0700, Mark Friedenbach wrote:
> They do so by not building on larger blocks
> On Jun 23, 2015 9:31 PM, "Raystonn" <raystonn at hotmail.com> wrote:
>
> > No, they can lower their own block sizes. But they cannot currently lower
> > the sizes of blocks mined by others. That is not the same thing by any
> > stretch of the imagination.
> > On 23 Jun 2015 8:50 pm, Jeff Garzik <jgarzik at gmail.com> wrote:
> >
> > Miners can collude today to lower the block size limit.
> >
> > In fact, this largely happens already out of laziness - miners often
> > follow the "soft" default limit set by Bitcoin Core, to the point where you
> > can chart when miners upgrade to new software:
> > http://hashingit.com/analysis/39-the-myth-of-the-megabyte-bitcoin-block
> >
> >
> >
> > On Tue, Jun 23, 2015 at 8:05 PM, William Madden <will.madden at novauri.com>
> > wrote:
> >
> > Here are refutations of the approach in BIP-100 here:
> > http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf
> >
> > To recap BIP-100:
> >
> > 1) Hard form to remove static 1MB block size limit
> > 2) Add new floating block size limit set to 1MB
> > 3) Historical 32MB message limit remains
> > 4) Hard form on testnet 9/1/2015
> > 5) Hard form on main 1/11/2016
> > 6) 1MB limit changed via one-way lock in upgrade with a 12,000 block
> > threshold by 90% of blocks
> > 7) Limit increase or decrease may not exceed 2x in any one step
> > 8) Miners vote by encoding 'BV'+BlockSizeRequestValue into coinbase
> > scriptSig, e.g. "/BV8000000/" to vote for 8M.
> > 9) Votes are evaluated by dropping bottom 20% and top 20%, and then the
> > most common floor (minimum) is chosen.
> >
> > 8MB limits doubling just under every 2 years makes a static value grow
> > in a predictable manner.
> >
> > BIP-100 makes a static value grow (or more importantly potentially
> > shrink) in an unpredictable manner based on voting mechanics that are
> > untested in this capacity in the bitcoin network. Introducing a highly
> > variable and untested dynamic into an already complex system is
> > unnecessarily risky.
> >
> > For example, the largely arbitrary voting rules listed in 9 above can be
> > gamed. If I control pools or have affiliates involved in pools that
> > mine slightly more than 20% of blocks, I could wait until block sizes
> > are 10MB, and then suddenly vote "/BV5000000/" for 20% of blocks and
> > "/BV5000001/" for the remaining 10%. If others don't consistently vote
> > for the same "/BV#/" value, vote too consistently and have their value
> > thrown out as the top 20%, I could win the resize to half capacity
> > "/BV5000001/" because it was the lowest repeated value not in the bottom
> > 20%.
> >
> > I could use this to force an exodus to my sidechain/alt coin, or to
> > choke out the bitcoin network. A first improvement would be to only let
> > BIP-100 raise the cap and not lower it, but if I can think of a
> > vulnerability off the top of my head, there will be others on the other
> > side of the equation that have not been thought of. Why bother
> > introducing a rube goldberg machine like voting when a simple 8mb cap
> > with predictable growth gets the job done, potentially permanently?
> >
> >
> > On 6/23/2015 9:43 PM, odinn wrote:
> > > -----BEGIN PGP SIGNED MESSAGE-----
> > > Hash: SHA1
> > >
> > > 1) Hard fork not (necessarily) needed
> > > 2) See Garzik's BIP 100, better (this is not meant to say "superior to
> > > your stuff," but rather simply to say, "Better you should work with
> > > Garzik to implement BIP-100, that would be good")
> > > 3) See points 1 and 2 above
> > > 4) If still reading... changes should be (as you seem to have been
> > > trying to lean towards)... lean towards gradual change; hence, changes
> > > that would flow from this BIP would be better off oriented in a
> > > process that dies not require the "way you have done it."
> > >
> > > You did address that, to be fair - in your TODO, this link:
> > > http://gavinandresen.ninja/time-to-roll-out-bigger-blocks
> > >
> > > contained the following link:
> > >
> > > http://gavinandresen.ninja/bigger-blocks-another-way
> > >
> > > However, in reading that, I didn't see any meaningful statements that
> > > would refute the approach in Garzik's BIP-100.
> > >
> > > Maybe a better way to say this is,
> > >
> > > Work with Jeff Garzik (which I am sure you are already having such
> > > discussions in private) as well as the list discussions,
> > > Move forward on BIP-100 with Garzik and other developers (not such a
> > > bad plan really) and don't get caught up in XT. (If you feel you can
> > > develop XT further, that is your thing but it would perhaps make you
> > > lose focus, work together with other developers.)
> > >
> > > Relax into the process. Things will be ok.
> > >
> > > Respectfully,
> > >
> > > - -O
> > >
> > > On 06/22/2015 11:18 AM, Gavin Andresen wrote:
> > >> I promised to write a BIP after I'd implemented
> > >> increase-the-maximum-block-size code, so here it is. It also lives
> > >> at:
> > >> https://github.com/gavinandresen/bips/blob/blocksize/bip-8MB.mediawiki
> > >>
> > >> I don't expect any proposal to please everybody; there are
> > >> unavoidable tradeoffs to increasing the maximum block size. I
> > >> prioritize implementation simplicity -- it is hard to write
> > >> consensus-critical code, so simpler is better.
> > >>
> > >>
> > >>
> > >>
> > >> BIP: ?? Title: Increase Maximum Block Size Author: Gavin Andresen
> > >> <gavinandresen at gmail.com <mailto:gavinandresen at gmail.com>> Status:
> > >> Draft Type: Standards Track Created: 2015-06-22
> > >>
> > >> ==Abstract==
> > >>
> > >> This BIP proposes replacing the fixed one megabyte maximum block
> > >> size with a maximum size that grows over time at a predictable
> > >> rate.
> > >>
> > >> ==Motivation==
> > >>
> > >> Transaction volume on the Bitcoin network has been growing, and
> > >> will soon reach the one-megabyte-every-ten-minutes limit imposed by
> > >> the one megabyte maximum block size. Increasing the maximum size
> > >> reduces the impact of that limit on Bitcoin adoption and growth.
> > >>
> > >> ==Specification==
> > >>
> > >> After deployment on the network (see the Deployment section for
> > >> details), the maximum allowed size of a block on the main network
> > >> shall be calculated based on the timestamp in the block header.
> > >>
> > >> The maximum size shall be 8,000,000 bytes at a timestamp of
> > >> 2016-01-11 00:00:00 UTC (timestamp 1452470400), and shall double
> > >> every 63,072,000 seconds (two years, ignoring leap years), until
> > >> 2036-01-06 00:00:00 UTC (timestamp 2083190400). The maximum size of
> > >> blocks in between doublings will increase linearly based on the
> > >> block's timestamp. The maximum size of blocks after 2036-01-06
> > >> 00:00:00 UTC shall be 8,192,000,000 bytes.
> > >>
> > >> Expressed in pseudo-code, using integer math:
> > >>
> > >> function max_block_size(block_timestamp):
> > >>
> > >> time_start = 1452470400 time_double = 60*60*24*365*2 size_start =
> > >> 8000000 if block_timestamp >= time_start+time_double*10 return
> > >> size_start * 2^10
> > >>
> > >> // Piecewise-linear-between-doublings growth: time_delta =
> > >> block_timestamp - t_start doublings = time_delta / time_double
> > >> remainder = time_delta % time_double interpolate = (size_start *
> > >> 2^doublings * remainder) / time_double max_size = size_start *
> > >> 2^doublings + interpolate
> > >>
> > >> return max_size
> > >>
> > >> ==Deployment==
> > >>
> > >> Deployment shall be controlled by hash-power supermajority vote
> > >> (similar to the technique used in BIP34), but the earliest possible
> > >> activation time is 2016-01-11 00:00:00 UTC.
> > >>
> > >> Activation is achieved when 750 of 1,000 consecutive blocks in the
> > >> best chain have a version number with bits 3 and 14 set (0x20000004
> > >> in hex). The activation time will be the timestamp of the 750'th
> > >> block plus a two week (1,209,600 second) grace period to give any
> > >> remaining miners or services time to upgrade to support larger
> > >> blocks. If a supermajority is achieved more than two weeks before
> > >> 2016-01-11 00:00:00 UTC, the activation time will be 2016-01-11
> > >> 00:00:00 UTC.
> > >>
> > >> Block version numbers are used only for activation; once activation
> > >> is achieved, the maximum block size shall be as described in the
> > >> specification section, regardless of the version number of the
> > >> block.
> > >>
> > >>
> > >> ==Rationale==
> > >>
> > >> The initial size of 8,000,000 bytes was chosen after testing the
> > >> current reference implementation code with larger block sizes and
> > >> receiving feedback from miners stuck behind bandwidth-constrained
> > >> networks (in particular, Chinese miners behind the Great Firewall
> > >> of China).
> > >>
> > >> The doubling interval was chosen based on long-term growth trends
> > >> for CPU power, storage, and Internet bandwidth. The 20-year limit
> > >> was chosen because exponential growth cannot continue forever.
> > >>
> > >> Calculations are based on timestamps and not blockchain height
> > >> because a timestamp is part of every block's header. This allows
> > >> implementations to know a block's maximum size after they have
> > >> downloaded it's header, but before downloading any transactions.
> > >>
> > >> The deployment plan is taken from Jeff Garzik's proposed BIP100
> > >> block size increase, and is designed to give miners, merchants,
> > >> and full-node-running-end-users sufficient time to upgrade to
> > >> software that supports bigger blocks. A 75% supermajority was
> > >> chosen so that one large mining pool does not have effective veto
> > >> power over a blocksize increase. The version number scheme is
> > >> designed to be compatible with Pieter's Wuille's proposed "Version
> > >> bits" BIP.
> > >>
> > >> TODO: summarize objections/arguments from
> > >> http://gavinandresen.ninja/time-to-roll-out-bigger-blocks.
> > >>
> > >> TODO: describe other proposals and their advantages/disadvantages
> > >> over this proposal.
> > >>
> > >>
> > >> ==Compatibility==
> > >>
> > >> This is a hard-forking change to the Bitcoin protocol; anybody
> > >> running code that fully validates blocks must upgrade before the
> > >> activation time or they will risk rejecting a chain containing
> > >> larger-than-one-megabyte blocks.
> > >>
> > >> Simplified Payment Verification software is not affected, unless
> > >> it makes assumptions about the maximum depth of a transaction's
> > >> merkle branch based on the minimum size of a transaction and the
> > >> maximum block size.
> > >>
> > >> ==Implementation==
> > >>
> > >> https://github.com/gavinandresen/bitcoinxt/tree/blocksize_fork
> > >>
> > >>
> > >>
> > >> _______________________________________________ bitcoin-dev mailing
> > >> list bitcoin-dev at lists.linuxfoundation.org
> > >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> > >>
> > >
> > > - --
> > > http://abis.io ~
> > > "a protocol concept to enable decentralization
> > > and expansion of a giving economy, and a new social good"
> > > https://keybase.io/odinn
> > > -----BEGIN PGP SIGNATURE-----
> > > Version: GnuPG v1
> > >
> > > iQEcBAEBAgAGBQJVigtJAAoJEGxwq/inSG8CqZwIAIG3ZQzekfccPxBOMqtim175
> > > Crov6hrO9FaIzbLljECpUi60RKuDM/fs09ZJsKKIaJPkB5dlJjs4huc206veAIO+
> > > K2h3DmAcA6W/Thk0C2cV3ewv+OiELDOhpeoddBBLPadAfaBGr4l9ltqWLdBtMCmw
> > > OtmiWstEuXTao9ApgoFOmybdmCjbfrfhejOOHs/pMiSn5xVE60RK4x2HFTFsHfAN
> > > fZAeLCuwuN2qWMrVrr+cbpCXjEuE1xZG3WEj7ppYoGR+AgF/Y5/U1j7S4PVpk85s
> > > CgMkpcWvLnBMmSCrllnRZy1Gfrwk36Pg0rXD/l/NNd0/KTpmPSvkX/bCyzFwbzo=
> > > =ft62
> > > -----END PGP SIGNATURE-----
> > > _______________________________________________
> > > bitcoin-dev mailing list
> > > bitcoin-dev at lists.linuxfoundation.org
> > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> > >
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
> >
> >
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
> >
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 17:39:48

- reply

📅 Original date posted:2015-06-23
📝 Original message:> Consensus is that this process is too painful to go through once a year. I
> agree.
>
> If you disagree and would like to see a Blocksize Council meet once a year
> to issue a decree on what the maximum block size shall be for the next
> year, then propose a process for who gets to sit on the Council and how
> their decrees are enforced.....
We could just as well say that the increases continue for 20 years, or
until there is concensus to schedule a soft-fork to prevent further
increase - whichever comes first. That is the case already, of
course, since there is no way to prevent a modest supermajority of
miners from pushing through a soft-fork. But explicitly accepting the
possibility that the community might choose to cut the process short
might make the BIP more palatable to some.
It is also the reality: halting the blocksize increase before it hits
the final 8GB limit is relatively easy, compared to the task of
setting it in motion, so it does no real harm to set the "20 years"
figure at the upper range of what we think is reasonable - even though
under other circumstances one would probably say that extrapolating
exponentials that far out would be foolhardy...
roy

2023-06-07 17:36:07

- reply

📅 Original date posted:2015-06-01
📝 Original message:On Mon, Jun 01, 2015 at 09:01:49PM +0100, Roy Badami wrote:
> > What do other people think? Would starting at a max of 8 or 4 get
> > consensus? Scaling up a little less than Nielsen's Law of Internet
> > Bandwidth predicts for the next 20 years? (I think predictability is
> > REALLY important).
>
> TL;DR: Personally I'm in favour of doing something relatively
> uncontroversial (say, a simple increase in the block size to something
> in the 4-8GB range) with no further increases without a further hard
> fork.
And the other bit I should have added to my TL;DR:
If we end up spending a significant proportion of the next 20 years
discussing the then _next_ hard fork, that's a *good* thing, not a
*bad* thing. Hard forks need to become, if not entirely routine, then
certainly less scary. A sequence of (relatively) uncontroversial hard
forks over time is way more likely to gain consensus than a single
hard fork that attempts to set a schedule for block size increases out
to 2035. IMHO.
>
> I'm not sure how relevent Nielsen's Law really is. The only relevent
> data points Nielsen has really boil down to a law about how the speed
> of his cable modem connection has changed during the period 1998-2014.
>
> Interesting though that is, it's not hugely relevent to
> bandwidth-intensive operations like running a full node. The problem
> is he's only looking at the actual speed of his connection in Mbps,
> not the amount of data usage in GB/month that his provider permits -
> and there's no particular reason to expect that both of those two
> figures follow the same curve. In particular, we're more interested
> in the cost of backhaul and IP transit (which is what drives the
> GB/month figure) than we are in improvements in DOCSIS technology,
> which have little relevence to node operators even on cable modem, and
> none to any other kind of full node operator, be it on DSL or in a
> datacentre.
>
> More importantly, I also think a scheduled ramp up is an unnecessary
> complication. Why do we need to commit now to future block size
> increases perhaps years into the future? I'd rather schedule an
> uncontroversial hard fork now (if such thing is possible) even if
> there's a very real expectation - even an assumption - that by the
> time the fork has taken place, it's already time to start discussing
> the next one. Any curve or schedule of increases that stretches years
> into the future is inevitably going to be controversial - and more so
> the further into the future it stretches - simply because the
> uncertainties around the Bitcoin landscape are going to be greater the
> further ahead we look.
>
> If a simple increase from 1GB to 4GB or 8GB will solve the problem for
> now, why not do that? Yes, it's quite likely we'll have to do it
> again, but we'll be able to make that decision in the light of the
> 2016 or 2017 landscape and can again make a simple, hopefully
> uncontroversial, increase in the limit at that time.
>
> So, with the proviso that I think this is all bike shedding, if I had
> to pick my favourite colour for the bike shed, it would be to schedule
> a hard fork that increases the 1GB limit (to something in the 4-8GB
> range) but with no further increases without a further hard fork.
>
> Personally I think trying to pick the best value of the 2035 block
> size now is about as foolish as trying to understand now the economics
> of Bitcoin mining many halvings hence.
>
> NB: this is not saying that I think we shouldn't go above 8GB in the
> relatively foreseeable future; quite the contrary, I strongly expect
> that we will. I just don't see the need to pick the 2020 block size
> now when we can easily make a far better informed decision as to the
> 2020 block size in 2018 or even 2019.
>
> As to knowing what the block size is going to be for the next 20 years
> being "REALLY important"? 100% disagree. I also think it's
> impossible, because even if you manage to get consensus on a block
> size increase schedule that stretches out to 2035 (and my prediction
> is you won't) the reality is that that block size schedule will have
> been modified by a future hard fork long before we get to 2035.
>
> What I personally think is REALLY important is that the Bitcoin
> community demonstrates an ability to react appropriately to changing
> requirements and conditions - and we'll only be able to react to those
> conditions when we know what they are! My expectation is that there
> will be several (hopefully _relatively_ uncontroversial) scheduled
> hard forks between now and 2035, and each of those will be discussed
> in suitable detail before being agreed. And that's as it should be.
>
> roy

2023-06-07 17:33:37

- reply

📅 Original date posted:2015-05-07
📝 Original message:On Thu, May 07, 2015 at 11:49:28PM +0200, Pieter Wuille wrote:
> I would not modify my node if the change introduced a perpetual 100 BTC
> subsidy per block, even if 99% of miners went along with it.
Surely, in that scenario Bitcoin is dead. If the fork you prefer has
only 1% of the hash power it is trivially vulnerably not just to a 51%
attack but to a 501% attack, not to mention the fact that you'd only
be getting one block every 16 hours.
>
> A hardfork is safe when 100% of (economically relevant) users upgrade. If
> miners don't upgrade at that point, they just lose money.
>
> This is why a hashrate-triggered hardfork does not make sense. Either you
> believe everyone will upgrade anyway, and the hashrate doesn't matter. Or
> you are not certain, and the fork is risky, independent of what hashrate
> upgrades.
Beliefs are all very well, but they can be wrong. Of course we should
not go ahead with a fork that we believe to be dangerous, but
requiring a supermajority of miners is surely a wise precaution. I
fail to see any realistic scenario where 99% of miners vote for the
hard fork to go ahead, and the econonomic majority votes to stay on
the blockchain whose hashrate has just dropped two orders of magnitude
- so low that the mean time between blocks is now over 16 hours.
>
> And the march 2013 fork showed that miners upgrade at a different schedule
> than the rest of the network.
> On May 7, 2015 5:44 PM, "Roy Badami" <roy at gnomon.org.uk> wrote:
>
> >
> > > On the other hand, if 99.99% of the miners updated and only 75% of
> > > merchants and 75% of users updated, then that would be a serioud split of
> > > the network.
> >
> > But is that a plausible scenario? Certainly *if* the concensus rules
> > required a 99% supermajority of miners for the hard fork to go ahead,
> > then there would be absoltely no rational reason for merchants and
> > users to refuse to upgrade, even if they don't support the changes
> > introduces by the hard fork. Their only choice, if the fork succeeds,
> > is between the active chain and the one that is effectively stalled -
> > and, of course, they can make that choice ahead of time.
> >
> > roy
> >
> >
> > ------------------------------------------------------------------------------
> > One dashboard for servers and applications across Physical-Virtual-Cloud
> > Widest out-of-the-box monitoring support with 50+ applications
> > Performance metrics, stats and reports that give you Actionable Insights
> > Deep dive visibility with transaction tracing using APM Insight.
> > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> > _______________________________________________
> > Bitcoin-development mailing list
> > Bitcoin-development at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >

2023-06-07 17:33:36

- reply

📅 Original date posted:2015-05-07
📝 Original message:I'd love to have more discussion of exactly how a hard fork should be
implemented. I think it might actually be of some value to have rough
consensus on that before we get too bogged down with exactly what the
proposed hard fork should do. After all, how can we debate whether a
particular hard fork proposal has consensus if we haven't even decided
what level of supermajority is needed to establish consensus?
For instance, back in 2012 Gavin was proposing, effectively, that a
hard fork should require a supermajority of 99% of miners in order to
succeed:
https://gist.github.com/gavinandresen/2355445
More recently, Gavin has proposed that a supermoajority of only 80% of
miners should be needed in order to trigger the hard fork.
http://www.gavintech.blogspot.co.uk/2015/01/twenty-megabytes-testing-results.html
Just now, on this list (see attached message) Gavin seems to be
aluding to some mechanism for a hard fork which involves consensus of
full nodes, and then a soft fork preceeding the hard fork, which I'd
love to see a full explanation of.
FWIW, I think 80% is far too low to establish consensus for a hard
fork. I think the supermajority of miners should be sufficiently
large that the rump doesn't constitute a viable coin. If you don't
have that very strong level of consensus then you risk forking Bitcoin
into two competing coins (and I believe we already have one exchange
promissing to trade both forks as long as the blockchains are alive).
As a starting point, I think 35/36th of miners (approximately 97.2%)
is the minimum I would be comfortable with. It means that the rump
coin will initially have an average confirmation time of 6 hours
(until difficulty, very slowly, adjusts) which is probably far enough
from viable that the majority of holdouts will quickly desert it too.
Thoughs?
roy
-------------- next part --------------
An embedded message was scrubbed...
From: Gavin Andresen <gavinandresen at gmail.com>
Subject: Re: [Bitcoin-development] Block Size Increase
Date: Thu, 7 May 2015 10:52:54 -0400
Size: 9909
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150507/ed0c3179/attachment.eml>

2023-06-07 17:33:36

- reply

📅 Original date posted:2015-05-07
📝 Original message:> On the other hand, if 99.99% of the miners updated and only 75% of
> merchants and 75% of users updated, then that would be a serioud split of
> the network.
But is that a plausible scenario? Certainly *if* the concensus rules
required a 99% supermajority of miners for the hard fork to go ahead,
then there would be absoltely no rational reason for merchants and
users to refuse to upgrade, even if they don't support the changes
introduces by the hard fork. Their only choice, if the fork succeeds,
is between the active chain and the one that is effectively stalled -
and, of course, they can make that choice ahead of time.
roy

2023-06-07 17:29:44

- reply

📅 Original date posted:2015-02-06
📝 Original message:> In this case there is no need for P2P communication, just pay to an
> address you already have for the other party. If you want to avoid
> address reuse, use stealth addressing.
>
> But yes, if you don't have a stealth address for the other party you can
> certainly communicate in private as peers where you trust that you share
> a public key. The core issue here is really bootstrapping of that trust
> in an ad hoc manner.
Something interactive might still be nicer, though, to avoid the risk
of paying to an address that the payee no longer has the private key
for. "Nooo!! Don't pay to that address. I lost my old phone so I
generated a new wallet."
roy

2023-06-07 17:29:44

- reply

📅 Original date posted:2015-02-05
📝 Original message:For peer-to-peer payments, how common do we think that the payment is
of an ad hoc nature rather than to a known contact?
If I want to pay my friends/colleagues/etc over a restaurant table
there's no reason why I couldn't already have their public keys in my
contact list - then it would be pretty straightforward to have a
watertight mechanism where I would know who I was paying. You could
probably even relatively securely bootstrap a key exchange over SMS,
relying only on the contacts already having each other in their
phonebooks.
As for comsumer-to-merchant transactions where the merchant is a
bricks and mortar merchant, IMHO it absolutely has to be "pay that
terminal over there". It's the trust model we all currently use -
whether paying cash or card - and it's the only trust model that works
IMHO (and customers and businesses alike are well aware of the risks
of a fraudster standing behind the counter pretending to be an
employee accepting payment - and by and large are pretty good at
mitigating it). OTOH as we've discussed here before there are many
use cases where the custoemr doesn't actually know or care about the
name of the shop or bar they walked into but is pretty damn sure that
they need to make payment to the person over there behind the counter.
Granted, there are cases taht dont' fall into either of the above -
but they're the cases that are (a) harder to figure out how to
authenticate and consequently (b) the use cases that are going to be
most subject to attempted fraud.
roy
On Thu, Feb 05, 2015 at 03:02:56PM -0800, William Swanson wrote:
> On Thu, Feb 5, 2015 at 2:10 PM, Eric Voskuil <eric at voskuil.org> wrote:
> > A MITM can receive the initial broadcast and then spoof it by jamming the
> > original. You then only see one.
>
> You are right, of course. There is no way to make Bluetooth 100%
> secure, since it is an over-the-air technology. You could try securing
> it using a CA or other identity server, but now you've excluded ad-hoc
> person-to-person payments. Plus, you need an active internet
> connection to reach the CA.
>
> You can try using proximity as a substitute for identity, like
> requiring NFC to kick-start the connection, but at that point you
> might as well use QR codes.
>
> This BIP is not trying to provide absolute bullet-proof security,
> since that's impossible given the physical limitations of the
> Bluetooth technology. Instead, it's trying to provide the
> best-possible security given those constraints. In exchange for this,
> we get greatly enhanced usability in common scenarios.
>
> There are plenty of usable, real-world technologies with big security
> holes. Anybody with lock-picking experience will tell you this, but
> nobody is welding their front door shut. The ability to go in and out
> is worth the security risk.
>
> Bluetooth payments add a whole new dimension to real-world Bitcoin
> usability. Do we shut that down because it can't be made perfect, or
> do we do the best we can and move forward?
>
> -William
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming. The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

2023-06-07 17:28:10

- reply

📅 Original date posted:2014-12-20
📝 Original message:Why would we want to have anything to do with people who are hosting
malware? Or do I misunderstand?
On Sat, Dec 20, 2014 at 08:57:53AM +0000, Matt Corallo wrote:
> There was recently some discussion around dnsseeds. Currently some
> dnsseeds are getting blocked by ISPs because the hosts they pick up
> (which run bitcoin core nodes) often run rather web servers alongside
> which serve malware or whatever else and thus end up on IP-based malware
> blacklists.
>
> Of course we really dont want to move off of DNS because it has this big
> built-in anonymity network where the DNS seed servers only get
> information about your ISP, not you, and its cached so you dont get as
> much information about how many users are making those requests.
>
> A potential solution might be supporting some subdomain which has
> results XORed with some constant mask to tweak the real IP.
>
> Additionally, it might be cool to stuff a TXT/AAAA/whatever record with
> a signature of the results provided by the DNSseed operator.
>
> Matt
>
> On 12/20/14 07:42, Will Bickford wrote:
> > Hi all, I'm looking to help with Bitcoin core development in my spare
> > time (a few hours per week).
> >
> > A little bit about me:
> > * I use C++ and Qt daily
> > * I love to automate and enhance software systems
> > * I enjoy root causing and fixing issues
> >
> > I saw Gavin say we needed help with testing in a Reddit AMA a while ago.
> > I'm curious where I can make the best impact. Any feedback would be
> > appreciated. Thanks!
> >
> > Will Bickford
> > "In Google We Trust"
> >
> >
> > ------------------------------------------------------------------------------
> > Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> > from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> > with Interactivity, Sharing, Native Excel Exports, App Integration & more
> > Get technology previously reserved for billion-dollar corporations, FREE
> > http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
> >
> >
> >
> > _______________________________________________
> > Bitcoin-development mailing list
> > Bitcoin-development at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >
>
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&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:23:19

- reply

📅 Original date posted:2014-06-24
📝 Original message:On Tue, Jun 24, 2014 at 10:21:46AM -0400, Jeff Garzik wrote:
> On Tue, Jun 24, 2014 at 9:27 AM, Mike Hearn <mike at plan99.net> wrote:
> > Wallets would then be able to persist this data to disk and compete on cool visualisations for how much money you saved over time.
>
> heh, this is a cool idea.
>
> It also seems like it would be subject to instant inflation, as it's
> unprovable, and a rational economic actor may choose to exaggerate
> such numbers. It also seems collectively rational by some points of
> view for all bitcoin actors to inflate this number.
Rather than offering discounts, how about offering automatic cashback?
I know they're kinda stupid, but I gather cashback deals are very
commonplace in the US and (probably as a result) not unheard of elsewhere.
So you add an optional cashback_to field to the Payment message,
distinct from but conceptually similar to the refund_to field. The
wallet can tally up how much cashback is received, without having to
trust the merchants.
Much harder to game, AFAICS.
roy

2023-06-07 17:18:43

- reply

📅 Original date posted:2014-04-16
📝 Original message:On Wed, Apr 16, 2014 at 05:20:41PM +0200, Pieter Wuille wrote:
> On Wed, Apr 16, 2014 at 5:12 PM, Kevin <kevinsisco61784 at gmail.com> wrote:
> > I think we should get to the bottom of this. Should we assume that xp is
> > not secure enough?
>
> Yes.
Do we need a similar warning for OS X 10.6? The EOL of that one is
*far* less well known than XP (because of Apple's failure to
communicate product lifecycles).
roy
>
> > What is this warning?
>
> Windows XP is no longer maintained. Don't use such a system for
> protecting your money.
>
> > Who is issuing this warning?
>
> Microsoft: http://windows.microsoft.com/en-us/windows/end-support-help
>
> The suggestion here is to make Bitcoin Core detect when it's running
> on Windows XP, and warn the user (they are likely unaware of the
> risks).
>
> --
> Pieter
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/NeoTech
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

2023-06-07 17:16:42

- reply

📅 Original date posted:2014-03-29
📝 Original message:Right now there are also people simply taking base58-encoded private
keys and running them through ssss-split.
It has a lot going for it, since it can easily be reassembled on any
Linux machine without special software (B Poettering's Linux command
line SSSS implementation[1] seems to be included in most Linux distros).
roy
[1] http://point-at-infinity.org/ssss/
On Sat, Mar 29, 2014 at 12:59:19PM -0400, Alan Reiner wrote:
>
> Armory has had "Fragmented Backups" for over a year, now. Advanced
> users love it. Though, I would say it's kind of difficult to
> standardize the way I did it since I was able to implement all the
> finite field math with recursion, list comprehensions and python
> arbitrary-big-integers in about 100 lines. I'm not sure how "portable"
> it is to other languages. There's obviously better ways to do it, but I
> didn't need a better way, because I don't need to support fragmentation
> above M=8 and this was 100% sufficient for it. And I was the only one
> doing it, so there was no one to be compatible with.
>
> I won't lie, there's a lot of work that goes into making an interface
> that makes this feature "usable." The user needs clear ways to identify
> which fragments are associated with which wallet, and which fragments
> are compatible with each other. They need a way to save some fragments
> to file, print them, or simply write them down. They need a way to
> re-enter fragment, reject duplicates, identify errors, etc. Without it,
> the math fails silently, and you end up restoring a different wallet.
> And they need a way to test that it all works. Armory did all this,
> but it was no trivial task. Including an interface that will test up to
> 50 subsets of make sure the math produces the same values every time
> (which still is not sufficient for some users, who won't be satisified
> til they see they're wallet actually restored from fragments.
>
> Also I put the secret in the highest-order coefficient of the
> polynomial, and made sure that the other coefficients were
> deterministic. This meant that if print out an M-of-N wallet, I can
> later print out an M-of-(N+1) wallet and the first N fragments will be
> the same. I'm not sure how many users would trust this, but we felt it
> was important in case a user needs to export some fragments, even if
> they don't increase N.
>
> You might consider loading Armory in offline mode, create a wallet, and
> then do a fragmented backup to see how we did it. I am extremely
> satisfied with the interface, but it's most definitely an "advanced"
> tool. But so is Armory ... which made it a good fit. But it might not
> be for everyone.
>
> -Alan
>
>
>
> On 03/29/2014 11:44 AM, Matt Whitlock wrote:
> > On Saturday, 29 March 2014, at 11:08 am, Watson Ladd wrote:
> >> https://freedom-to-tinker.com/blog/stevenag/new-research-better-wallet-security-for-bitcoin/
> > Thanks. This is great, although it makes some critical references to an ACM paper for which no URL is provided, and thus I cannot implement it.
> >
> > A distributed ECDSA notwithstanding, we still need a way to decompose a BIP32 master seed into shares. I am envisioning a scenario in which I might meet my sudden and untimely demise, and I wish to allow my beneficiaries to reconstruct my wallet's master seed after my death. I would like to distribute seed shares to each of my beneficiaries and some close friends, such that some subset of the shares must be joined together to reconstitute my master seed. Shamir's Secret Sharing Scheme is perfect for this use case. I am presently working on extending my draft BIP so that it also applies to BIP32 master seeds of various sizes.
> >
> > ------------------------------------------------------------------------------
> > _______________________________________________
> > Bitcoin-development mailing list
> > Bitcoin-development at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

2023-06-07 17:16:42

- reply

📅 Original date posted:2014-03-29
📝 Original message:On Sat, Mar 29, 2014 at 01:42:01PM -0400, Matt Whitlock wrote:
> On Saturday, 29 March 2014, at 5:28 pm, Roy Badami wrote:
> > Right now there are also people simply taking base58-encoded private
> > keys and running them through ssss-split.
> >
> > It has a lot going for it, since it can easily be reassembled on any
> > Linux machine without special software (B Poettering's Linux command
> > line SSSS implementation[1] seems to be included in most Linux distros).
> >
> > roy
> >
> > [1] http://point-at-infinity.org/ssss/
>
> Respectfully, it's also possible to take a base58-encoded private key and run it through GPG, which is included in most Linux distros. But yet we have BIP38.
And yet, how many wallets can import BIP38 keys? If someone gave me
one I would have no idea what software (if any) can understand it (nor
would I have any idea how to generate one in the first place).
Anyway, I'm not arguing against standardising these things - if people
are going to implement this then of course it's beneficial that they
implement it compatibly. It was just a simple observation - make of
it what you will.
roy

2023-06-07 17:15:31

- reply

📅 Original date posted:2014-03-14
📝 Original message:On Fri, Mar 14, 2014 at 03:05:25PM +0100, Andreas Schildbach wrote:
> btw. None of Bitcoin Wallet's users complained about confusion because
> of the mBTC switch. In contrast, I get many mails and questions if
> exchange rates happen to differ by >10%.
At the moment, I imagine the vast majority of Bitcoin users are
familliar with SI units and know what milli- and micro- mean.
I doubt that is true of the general population, though.
roy

2023-06-07 17:14:25

- reply

📅 Original date posted:2014-03-26
📝 Original message:On Fri, Mar 21, 2014 at 12:02:44AM +0100, Mike Hearn wrote:
> >
> > It's not unusual, in a face-to-face transaction at a bricks-and-mortar
> > establishment, that you know neither the legal name of the entity
> > running the establishment
>
>
> I'd hope that people can get certs for their actual business name, but
> sometimes it does differ yes.
The actual example I was thinking of is that of traditional British
pubs. Often a company will own several pubs - however the pubs
themselves will typically have individual traditional pub names. The
name of the company might not be at all prominently advertised in the
pubs.
Traders at music festivals are another example that comes to mind (they
often accept credit cards if they sell higher value items so why not
Bitcoin?) In this example there often are no clearly advertised
business names - at least, that the customer will be aware of.
roy

2023-06-07 17:10:28

- reply

📅 Original date posted:2013-12-08
📝 Original message:> > 5) Who controls DNS for it?
>
> I'm not sure we'll get any change on this level. I have no idea if the
> domain is in good hands, except for the fact that nothing bad happened
> thus far. If anything, moving it to core developers (as intended when
> the domain was registered) would make more sense IMO. But again, is it
> possible, I don't know.
That's an interesting question. The bitcoin.org domain is hiding
behind a WhoisGuard anonymous registration. Why are we not allowed to
know who this domain belongs to? Why are we being asked to trust some
unidentified party?
roy

2023-06-07 17:10:27

- reply

📅 Original date posted:2013-12-09
📝 Original message:> The bitcoin.org domain is controlled by me, Sirius, and an anonymous
> person. Control will not be lost if Sirius becomes unavailable.
I know this will be a controversial viewpoint in some quarters, but
I'm not a fan of anonymity, or of pseudonyms. As far as I know
(please correct me if I'm wrong) all the core devs go by their real
names with the exception of Satoshi (and I would hope he no longer has
commit access? - only because I would hope that no-one has
pseudonymous commit access these days). I don't see why this should
be different for the domain, the DNS and the rest of the
infrastructure...
Although that's separate from the question of who the registrant of
the domain should be (the registrant being the closest thing a domain
has to a recorded legal owner). Who currently purports to be the
current legal owner of the domain?
IMHO the registrant should obviously be real and not WhoisGuard -
anonymous stuff like this always looks shady. And surely the Bitcoin
Foundation is the obvious candidate to own the domain (just like
kernel.org is owned by the Linux Foundation). But this may all be
moot unless the current legal owners are willing to assign the
domain...
roy

2023-06-07 17:05:39

- reply

📅 Original date posted:2013-08-07
📝 Original message:But the reality is that in many applications you need to provide a
single URL.
Consider existing point-of-sale systems that display QR codes for the
user to scan. They live within the limitations of existing bitcoin
URLs, but would no doubt benefit from the payments protocol.
It's not realistic for the terminal operator in a retail establishment
to have to select which protocol will be used before generating the QR
code - so the effect of your proposal is to require lowest common
denominator and effectively prevent such systems from using the
payments protocol (at least until it is sufficiently ubiquitous that
they feel happy to simply require its use).
roy
On Wed, Aug 07, 2013 at 11:54:44PM +0200, Pieter Wuille wrote:
> I see payment URIs rather as a replacement for bitcoin: URI rather
> than an extension. It solves everything they did in a much cleaner
> way, Given that bitcoin: have gotten some traction, we probably want
> to reuse the moniker, but replace the rest entirely. In other words,
> if a request is specified, nothing else should be.
>
> There is just no useful way to combine them either - payments
> generalize destinations to arbitrary scripts, messages are handled
> inline, amounts are defined inline. And if you want to rely on the
> payment infrastructure to work, you cannot risk people using the
> old-style static address in the URI.
>
>
>
> On Wed, Aug 7, 2013 at 11:47 PM, Roy Badami <roy at gnomon.org.uk> wrote:
> > Very brief comment on BIP 72:
> >
> > I wonder if there should be some discussion included in the
> > specification as to how the BIP 21 amount, message and label
> > parameters should be processed when the payment protocol is used.
> >
> > Presumably amount should be completely ignored? But is the total
> > amount requestd by the PaymentRequest required to match the amount
> > parameter (when present)? Is the client permitted to complain if they
> > don't?
> >
> > And what about message? Presumably the memo from PaymentDetails
> > should take precedence, but if it's not present, and message is?
> >
> > I think this is an area perhaps more suited to SHOULDs and MAYs rather
> > than MUSTs, but it is probably worthy of mention...
> >
> > roy
> >
> > ------------------------------------------------------------------------------
> > Get 100% visibility into Java/.NET code with AppDynamics Lite!
> > It's a free troubleshooting tool designed for production.
> > Get down to code-level detail for bottlenecks, with <2% overhead.
> > Download for free and get started troubleshooting in minutes.
> > http://pubads.g.doubleclick.net/gampad/clk?id=48897031&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:05:37

- reply

📅 Original date posted:2013-08-07
📝 Original message:On Thu, Aug 08, 2013 at 07:10:05AM +1000, Gavin Andresen wrote:
> RE: should the customer's machine not broadcast the transaction:
If we're going to allow payments to fail without being broadcast (but
where the wallet can't in general prove that the receiver hasn't seen
the transaction) then I would argue that it becomes highly desirable
that the wallet invalidates the transaction at the earliest
opportunity by spending the outputs in a pay-to-self transaction.
Otherwise malicious receivers, or temporary failures, could result in
the user being told that the transfer didn't happen, but then the
coins actually leaving the wallet anyway a short time later.
roy

2023-06-07 17:05:24

- reply

📅 Original date posted:2013-07-31
📝 Original message:On Wed, Jul 31, 2013 at 04:28:25PM +1000, Gavin Andresen wrote:
> I've turned the preliminary payment protocol spec into three BIPs:
>
> https://en.bitcoin.it/wiki/BIP_0070 : Network protocol / messages
> https://en.bitcoin.it/wiki/BIP_0071 : MIME types for the messages
> https://en.bitcoin.it/wiki/BIP_0072 : bitcoin: URI extension
Is it envisaged to be possible/sensible to have a URI that is *only* a
payment request? i.e. something like the following (although I'm not
sure this is a valid URI):
bitcoin:?request=https%3A%2F%2Fmerchant.com%2Fpay.php%3Fh%3D2a8628fc2fbe
roy

2023-06-07 17:02:39

- reply

📅 Original date posted:2013-06-04
📝 Original message:> Sure they are paying themselves, but given bitcoin network
> difficulty is uso high, simply obtaining payments-go-myself-as-miner
> transactions is itself difficult.
Not for pool operators it isn't. Nor for people buying hashing power
from a GPUMAX-type service, if such services still exist (or should
they exist again in future).

2023-06-07 13:39:47

- reply

📅 Original date posted:2013-03-13
📝 Original message:On Wed, Mar 13, 2013 at 07:28:06PM +0100, Pieter Wuille wrote:
> IMHO, the way to go is first get a 0.8.1 out that mimics the old
> behaviour - just as a stopgap solution.
Presumably not emulate too precisely, at least if your initial report
that the block caused 0.7 to 'get stuck' was correct. A network that
has a mix of 0.8.1 nodes (which will reject the block) and 0.7 nodes
(which will hang when receiving the block?) would appear to remove the
fork risk. Is it obvious that no other serious problems remain in
such a network?
(Although I note your proposal to patch 0.7 too, so hopefully the
network wouldn't remain in that state for very long)
roy

2023-06-07 13:39:11

- reply

📅 Original date posted:2013-03-13
📝 Original message:On Wed, Mar 13, 2013 at 02:27:01PM -0700, Gregory Maxwell wrote:
> On Wed, Mar 13, 2013 at 2:22 PM, Roy Badami <roy at gnomon.org.uk> wrote:
> > The idea of the client detecting/warning about not-trivial forking
> > seems worthwhile too, though, assuming it doesn't already (AIUI it
> > doesn't).
>
> It does warn??? if its heard the fork and its on the lower difficulty
> side. Extending that to also alert if its on the winning side and the
> fork is long enough might be wise, though I have a little concern that
> it'll be mistaken to be more dependable than it would be.
Still, it would have meant that all 0.8 users would have immediatley
been told that something was wrong. I don't know to what extent it
was luck that this was dealt with as promptly and efficiently as it
was, but to the extent that luck was involved, a slew of 0.8 users
shouting in various places "wtf is going on" couldn't but help in
reducing the element of luck if something similar were to happen again.
roy

2023-06-07 13:39:05

- reply

📅 Original date posted:2013-03-13
📝 Original message:On Wed, Mar 13, 2013 at 09:14:03PM +0000, Luke-Jr wrote:
> On Wednesday, March 13, 2013 9:06:44 PM Andy Parkins wrote:
> > On Wednesday 13 Mar 2013 12:56:29 Luke-Jr wrote:
> > > Here's a simple proposal to start discussion from...
> >
> > It seems to me that the biggest failure was not the development of two
> > chains, but the assurance to users (by the client) that their transactions
> > were confirmed.
>
> These are both the same thing.
The idea of the client detecting/warning about not-trivial forking
seems worthwhile too, though, assuming it doesn't already (AIUI it
doesn't).
I don't know if there's any automatic monitoring for forks, but if not
I would assume that the core devs and/or Bitcoin Foundation would be
planning to put some in place. But there's no reason I can see why
end users clients should't be warning of such situations, too, when
they can (obviously they won't always be aware of the fork).
roy

2023-06-07 13:37:06

- reply

📅 Original date posted:2013-03-12
📝 Original message:> clients are anyway keeping, and re-relaying, their own transactions
> and hence it would mean only little, and only little for clients.
Not all end-user clients are always-on though

2023-06-07 12:41:48

- reply

📅 Original date posted:2012-11-28
📝 Original message:> If a Receipt is not received for any reason (timeout, error) and
> Payment.transactions has not been broadcast by the merchant on the
> Bitcoin p2p network, then the Bitcoin client should assume that the
> payment failed, inform the customer that the payment failed, and
> return coins involved in the transaction to the customer's wallet.
I'm not sure I understand the rationale for this. In the above
scenario the buyer has no way to determine whether the merchant still
has a copy of the transaction that they could broadcast in future.
Maybe there is simply a systems problem at the merchant which has
temporarily delayed the transaction broadcast. Or maybe a dishonest
merchant deliberately engineered this situation in an attempt to
mislead the buyer as to the status of their payment.
Either way, having the buyer think the coins have been returned to
their wallet - only to disappear from their wallet again at some later
time - would seriously damage user confidence in Bitcoin IMHO.
It seems to me that the first thing the buyer should do given the
protocol as it stands is simply resend the Payment message - if there
was a temporary problem then resending the payment message (with the
same signed transation) might resolve the sitution.
If after several retries the status of the transaction is still
undefined then it's really not clear what to do, but it seems
desireable to have the client take steps so that it can return to a
state of certainly about its wallet balance as quickly as possible.
Two things I can imagine that the buyer might want their client to do
at this point are:
* broadcast the transaction itself, so they are sure the payment
transaction will make it into the blockchain without any further
action on their part, or
* invalidate the transaction by immediately broadcasting a
pay-to-self transaction that spends one or more of the same outputs
that the payment transaction spends (and treat the funds as part of
the unconfirmed balance until this pay-to-self transaction
confirms). This ensures the merchant can't subsequently use a
transaction which the buyer thinks has failed
It seems to me it would be simpler and cleaner if the buyer just
always broadcasted the transaction on the p2p network, regardless of
whether the Invoice includes a receiptURI. If a receiptURI is
included, the buyer's client would also include the transaction in the
Purchase message. The merchant then tries to broadcast the
transaction as well (unless their bitcoind has already seen it, which
may well be the common case). This approach seems to me to have fewer
nasty edge cases.s
roy