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

nprofile1qqs93utqurduvctq2uztry8rdagen7ypeps72dmrcuzhu67qcylxj5qv30ard

Author Public Key

npub1trckpcxmceskq4cykxgwxm63n8ugrjrpu5mk83c90e4upsf7d9gqf0f95j

Show more details

Last Notes

2023-06-07 15:39:58

- reply

📅 Original date posted:2015-06-24
📝 Original message:60% of the hashrate can easily agree to force a softfork which reduces
the block size. As soon as the fork occurs, there is a very strong
incentive for all the remaining 40% to go along with it: if they
don't, they're mining worthless blocks.
They can use a BIP-34 style mechanism to trigger the fork so there's
negligible risk to the miners.
On Wed, Jun 24, 2015 at 10:23:18AM -0700, Raystonn wrote:
> You really believe they would risk getting orphaned by skipping the longer chain, just to attempt to reduce average block size? No, that doesn't happen today. Laziness in leaving the default size is common. But that is not collusion, nor an attempt to manipulate the block sizes of other miners. 
> 
> <div class="gmail_quote">On 24 Jun 2015 10:05 am, Mark Friedenbach wrote: <blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">They do so by not building on larger blocks
> <div class="elided-text">On Jun 23, 2015 9:31 PM, "Raystonn" <<a href="mailto:raystonn@hotmail.com">raystonn@hotmail.com</a>> wrote: <blockquote style="margin:0 0 0 0.8ex;border-left:1px #ccc solid;padding-left:1ex">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.
> <div class="elided-text">On 23 Jun 2015 8:50 pm, Jeff Garzik <<a href="mailto:jgarzik@gmail.com">jgarzik@gmail.com</a>> wrote: <blockquote style="margin:0 0 0 0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Miners can collude today to lower the block size limit.<div> </div><div>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:??<a href="http://hashingit.com/analysis/39-the-myth-of-the-megabyte-bitcoin-block">http://hashingit.com/analysis/39-the-myth-of-the-megabyte-bitcoin-block</a></div><div> </div><div> </div></div><div> <div>On Tue, Jun 23, 2015 at 8:05 PM, William Madden <<a href="mailto:will.madden@novauri.com">will.madden@novauri.com</a>> wrote: <blockquote style="margin:0 0 0 0.8ex;border-left:1px #ccc solid;padding-left:1ex">Here are refutations of the approach in BIP-100 here: 
> <a href="http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf">http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf</a> 
> 
> 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? 
> <div><div> 
> 
> 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: 
> > <a href="http://gavinandresen.ninja/time-to-roll-out-bigger-blocks">http://gavinandresen.ninja/time-to-roll-out-bigger-blocks</a> 
> > 
> > contained the following link: 
> > 
> > <a href="http://gavinandresen.ninja/bigger-blocks-another-way">http://gavinandresen.ninja/bigger-blocks-another-way</a> 
> > 
> > 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: 
> >> <a href="https://github.com/gavinandresen/bips/blob/blocksize/bip-8MB.mediawiki">https://github.com/gavinandresen/bips/blob/blocksize/bip-8MB.mediawiki</a> 
> >> 
> >>?? 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 
> >> <<a href="mailto:gavinandresen@gmail.com">gavinandresen@gmail.com</a> <mailto:<a href="mailto:gavinandresen@gmail.com">gavinandresen@gmail.com</a>>> 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 
> >> <a href="http://gavinandresen.ninja/time-to-roll-out-bigger-blocks">http://gavinandresen.ninja/time-to-roll-out-bigger-blocks</a>. 
> >> 
> >> 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== 
> >> 
> >> <a href="https://github.com/gavinandresen/bitcoinxt/tree/blocksize_fork">https://github.com/gavinandresen/bitcoinxt/tree/blocksize_fork</a> 
> >> 
> >> 
> >> 
> >> _______________________________________________ bitcoin-dev mailing 
> >> list <a href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a> 
> >> <a href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a> 
> >> 
> > 
> > - -- 
> > <a href="http://abis.io">http://abis.io</a> ~ 
> > "a protocol concept to enable decentralization 
> > and expansion of a giving economy, and a new social good" 
> > <a href="https://keybase.io/odinn">https://keybase.io/odinn</a> 
> > -----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 
> > <a href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a> 
> > <a href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a> 
> > 
> _______________________________________________ 
> bitcoin-dev mailing list 
> <a href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a> 
> <a href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a> 
> </div></div></blockquote></div> </div>
> </blockquote></div> _______________________________________________ 
> bitcoin-dev mailing list 
> <a href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a> 
> <a href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a> 
> </blockquote></div>
> </blockquote></div>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 15: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 15: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 15:39:26

- reply

📅 Original date posted:2015-06-20
📝 Original message:> I just wish that half as much energy had gone into discussing
> whether we want a 100% supermajority or a 99% supermajority or an
> 80% supermajority, as has gone into discussing whether we want 1MB
> blocks or 8MB blocks or 20MB blocks.
And I understand that Gavin is now proposing that a 75% supermajority
should be enough. This constantly reducing threshold worries me
greatly.
There is a risk that we get a situation where a stable amount of
hashing power somewhat over 75% (say 80%) accepts the fork - and
therefore triggers it - but both a significant minority (say 20%) of
hashrate rejects it *and* the economic majority rejects it.
I'm not saying this is a likely outcome - indeed I hope it's not - but
it is a _possible_ outcome. Ok, the chain that the economic marjority
is using will have a bit of a temporary crisis due to 50 minute block
times, but it will recover in a few weeks as difficulty adjusts. And,
in the worst case, you end up with two competing semi-stable
ecosystems both claiming to be 'the real Bitcoin'.
My fear is that in that situation it could take an extended period -
perhaps many months - for one fork to clearly win and the other fork
to lose support (or at least lose sufficient support to be relegated
to altcoin status). I think such an extended period of uncertainty
would be the ultimate worst case scenario for Bitcoin. It _probably_
wouldn't be fatal to Bitcoin, but it would certainly be far worse for
Bitcoin than getting the blocksize wrong even by an order of magnitude
(in either direction). Therefore if we can design the hardfork
mechanism to make such an outcome impossible, I believe we really need
to.
roy

2023-06-07 15:39:26

- reply

📅 Original date posted:2015-06-20
📝 Original message:As I've observed before, Gavin originally advocated either a 99% or
100% buy in by miners for a hard fork to trigger.
https://gist.github.com/gavinandresen/2355445
I don't understand why people (Gavin included) now seem to favour a
much more modest supermajority except perhaps that they believe that
that level of consensus is unachievable.
FWIW I'm in favour of a block size increase. I just wish that half as
much energy had gone into discussing whether we want a 100%
supermajority or a 99% supermajority or an 80% supermajority, as has
gone into discussing whether we want 1MB blocks or 8MB blocks or 20MB
blocks. (So thank you, Pieter, for raising this.)
roy
On Sat, Jun 20, 2015 at 07:13:06PM +0200, Pieter Wuille wrote:
> Hello all,
>
> I've seen ideas around hard fork proposals that involve a block version
> vote (a la BIP34, BIP66, or my more recent versionbits BIP draft). I
> believe this is a bad idea, independent of what the hard fork itself is.
>
> Ultimately, the purpose of a hard fork is asking the whole community to
> change their full nodes to new code. The purpose of the trigger mechanism
> is to establish when that has happened.
>
> Using a 95% threshold, implies the fork can happen when at least 5% of
> miners have not upgraded, which implies some full nodes have not (as miners
> are nodes), and in addition, means the old chain can keep growing too,
> confusing old non-miner nodes as well.
>
> Ideally, the fork should be scheduled when one is certain nodes will have
> upgraded, and the risk for a fork will be gone. If everyone has upgraded,
> no vote is necessary, and if nodes have not, it remains risky to fork them
> off.
>
> I understand that, in order to keep humans in the loop, you want an
> observable trigger mechanism, and a hashrate vote is an easy way to do
> this. But at least, use a minimum timestamp you believe to be reasonable
> for upgrade, and a 100% threshold afterwards. Anything else guarantees that
> your forking change happens *knowingly* before the risk is gone.
>
> You may argue that miners would be asked to - and have it in their best
> interest - to not actually make blocks that violate the changed rule before
> they are reasonably sure that everyone has upgraded. That is possible, but
> it does not gain you anything over just using a 100% threshold, as how
> would they be reasonably sure everyone has upgraded, while blocks creater
> by non-upgraded miners are still being created?
>
> TL;DR: use a timestamp switchover for a hard fork, or add a block voting
> threshold as a means to keep humans in the loop, but if you do, use 100% as
> threshold.
>
> --
> Pieter
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

2023-06-07 15: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 15:36:06

- reply

📅 Original date posted:2015-06-01
📝 Original message:> 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.
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 15: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 15: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 15: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 15: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 15: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 15:29:43

- reply

📅 Original date posted:2015-02-05
📝 Original message:Personally I like the simplicity of tapping two phones together to
make payment - it should be quicker and easier than scanning QR codes
and it's a trust model that's hard to misunderstand.
Is NFC good enough for that? I fear even with NFC it is possible to
produce a device with longer range than one would expect. What
happened to the idea of tapping two devices together and then
comparing the timing of the tap (as detected by the phones'
accelerometers) to make spoofing a transaction harder? I remember
hearing about that years ago - is that still a thing?
roy
On Thu, Feb 05, 2015 at 02:10:51PM -0800, Eric Voskuil wrote:
> A MITM can receive the initial broadcast and then spoof it by jamming the original. You then only see one.
>
> e
>
> > On Feb 5, 2015, at 2:07 PM, Paul Puey <paul at airbitz.co> wrote:
> >
> > So if you picked up the BLE broadcast request. All you know is that *someone* within 100m is requesting bitcoin at a certain address. Not necessarily who. The *name* is both optional, and possibly just a *handle* of the user. If I'm sitting 5 ft away from someone at dinner and wanted to pay them via BLE, I might see "Monkey Dude" on my list and simply ask him "is that you?" If so, I send it. If there are two "Monkey Dude's" Then I have to bother with the address prefix, but not otherwise.
> >
> >> On Thu, Feb 5, 2015 at 1:46 PM, Eric Voskuil <eric at voskuil.org> wrote:
> >> BLE has an advertised range of over 100m.
> >>
> >> http://www.bluetooth.com/Pages/low-energy-tech-info.aspx
> >>
> >> In the case of mass surveillance that range could most likely be extended dramatically by the reviewer. I've seen WiFi ranges of over a mile with a strong (not FCC approved) receiver.
> >>
> >> WiFi hotspots don't have strong identity or a guaranteed position, so they can't be trusted for location.
> >>
> >> e
> >>
> >> On Feb 5, 2015, at 1:36 PM, Mike Hearn <mike at plan99.net> wrote:
> >>
> >>>> This sounds horrible. You could basically monitor anyone with a wallet in a highly populated area and track them super easily by doing facial recognition.
> >>>
> >>> We're talking about BLE, still? The radio tech that runs in the so called "junk bands" because propagation is so poor?
> >>>
> >>> My watch loses its connection to my phone if I just put it down and walk around my apartment. I'm all for reasonable paranoia, but Bluetooth isn't going to be enabling mass surveillance any time soon. It barely goes through air, let alone walls.
> >>>
> >>> Anyway, whatever. I'm just bouncing around ideas for faster user interfaces. You could always switch it off or set it to be triggered by the presence of particular wifi hotspots, if you don't mind an initial bit of setup.
> >>>
> >>> Back on topic - the debate is interesting, but I think to get this to the stage of being a BIP we'd need at least another wallet to implement it? Then I guess a BIP would be useful regardless of the design issues. The prefix matching still feels flaky to me but it's hard to know if you could really swipe payments out of the air in practice, without actually trying it.
> >
> ------------------------------------------------------------------------------
> 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 15:28:50

- reply

📅 Original date posted:2015-01-20
📝 Original message:> Why is this? Well, in most jurisdictions financial laws a custodial
> relationship is defined as having the ability, but not the right, to
> dispose of an asset.
So if I leave my window open while I'm out and there's some cash on my
desk, visible from the street, then every passer by now has a
custodial relationship with me?
Your example of a malicious software update seems more akin to a theft
like that (which is clearly not a custodial relationship) rather than
a true custodial relationship.
roy

2023-06-07 15: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 15: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 15:20:51

- reply

📅 Original date posted:2014-05-02
📝 Original message:> *Extended validation certs*
>
> When a business is accepting payment, showing the name of the business is
> usually better than showing just the domain name, for a few reasons:
>
> 1. Unless your domain name *is* your business name like blockchain.info,
> it looks better and gives more info.
>
> 2. Domain names are more phishable than EV names, e.g. is the right name
> bitpay.com or bit-pay.com or bitpay.co.uk?
>
> 3. More important: Someone who hacks your web server or DNS provider can
> silently get themselves a domain name SSL cert issued, probably without you
> noticing. Certificate transparency will eventually fix that but it's years
> away from full deployment. It's much harder for a hacker to get a bogus EV
> cert issued to them because there's a lot more checking involved.
>
> EV certs still have the domain name in the CN field, but they also have the
> business name in the OU field.
Well, many certs have something in the O field. That has nothing to
do with EV - EV just mandates a particular set of validation
requirements.
>
> In theory we are supposed to have extra code to check that a certificate
> really was subject to extended validation before showing the contents of
> this field. In practice either bitcoinj nor Bitcoin Core actually do, they
> just always trust it. It'd be nice to fix that in future.
I agree that blindly showing the O field may not be ideal - there
*may* conceivably be some CAs that include it without validation on
their cheap certs (although most cheap certs simply don't include it).
But it's not clear that EV or not is the right criterion here - there
are certainly non-EV certs out there that are organisation validated.
> You should show the organisation data instead of the domain name if you
> find it, for EV certs.
I have really mixed feelings about giving this privileged treatment
exclusively to EV certs, for the simple reason that the rules around
EV certs are iniquitous and some businesses are excluded.
e.g. in the UK sole traders (that is, unincorporated businesses) can't
get EV certs because the UK doesn't maintain a trade register of such
businesses and therefore such businesses are incapable of satisfying
the EV rules.
That said, EV certs are here, now, and (sadly) supporting them is
better than doing nothing...
roy

2023-06-07 15:20:49

- reply

📅 Original date posted:2014-05-03
📝 Original message:> the SI prefixes. People *do* use 63k USD, $63k, and $3M. I'll be the first one
As a counter argument, many sources (including the BBC) abbreviate
million to 'm' (and billion to 'bn'), e.g. $3m, $3bn.
I think any similarity with SI units here is coincidental.
roy

2023-06-07 15: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 15:16:49

- reply

📅 Original date posted:2014-03-31
📝 Original message:On Mon, Mar 31, 2014 at 01:07:46PM -0400, Jeff Garzik wrote:
> namecoin + SIN[1] or namecoin + PGP identity.
Is namecoin actively maintained these days?
roy

2023-06-07 15: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 15: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 15:16:27

- reply

📅 Original date posted:2014-03-29
📝 Original message:On Fri, Mar 28, 2014 at 09:56:57PM +0100, Andreas Schildbach wrote:
> On 03/28/2014 07:19 PM, Mike Hearn wrote:
>
> >> Ok, why don't fix this in the spec for now, by defining a fixed expiry
> >> time. In the EU, most products are covered by a 2 years warranty, so it
> >> seems appropriate to pick 2.5 years (30 months) -- allowing for some
> >> time to ship the product back and forth.
> >
> > Yeah I was thinking something like that on the walk home. But 2 years is
> > a long time. Do we have enough RAM for that?
>
> It depends on usage stats, script size, etc...
>
> > Plus warranties usually
> > result in the defective goods being replaced rather than a monetary
> > refund, right?
>
> Usually yes. The next smaller "unit of time" in Germany would be two
> weeks, the so-called "Fernabsatzgesetz". It allows you to send back
> mail-orders and usually you want the money back. Don't know if that made
> it into EU law or how it applies to other countries.
It's EU law, but the Distance Selling Directive only says "at least
seven days", so the exact period probably varies by country (in the UK
it is 7 days).
But the clock only starts ticking when you receive the goods, and the
Distance Selling Directive allows the supplier 30 days "to execute the
order" (I *think* the 30 days always has to include shipping, because
for consumer contracts title doesn't pass until the goods are
delivered, so the order wouldn't be considered complete until then).
So I think latest possible deadline for returning the goods for refund
could be up to 30 days to execute the order plus "at least 7 days"
(with some countries allowing more). Plus, conceivably, shipping
time, if some member states have chosen to interpret the 30 day
execution differently.
So I think this adds up to "a couple of months, give or take". In
practice, though, even a couple of months is a bit on the short time.
What if the goods are delayed. How many people have had miner orders
outstanding for the best part of a year?
roy

2023-06-07 15: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 15:14:25

- reply

📅 Original date posted:2014-03-20
📝 Original message:On Thu, Mar 20, 2014 at 07:31:27PM +0100, Mike Hearn wrote:
> Yes, this overlaps somewhat with the PKI signing in BIP70, but not
> entirely - you might want to serve unsigned payment requests, but
> still have confidentiality and authenticity for a local face to face
> transaction. The signing and encryption does different things
I'm not sure if this what you're getting at, but in a common
face-to-face scenario, it really doesn't overlap so much (in that the
PKI in BIP70 isn't really helpful).
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, nor any electronic identifier (domain name,
email address) that might be presented to you in an X.509 certificate,
even if such a certificate is presented in the PaymentRequest.
In many cases I want/need to simply be assured that I am paying "the
person/organisation which operates that machine behind the counter,
right there".
In many ways I'll miss the simplicity of BIP21 QR codes for
face-to-face transactions - because in this use case the payment
protocol complicates (and in many cases weakens) the assurance that
you really are paying the entity that prepared the QR code.
roy

2023-06-07 15: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 15:12:52

- reply

📅 Original date posted:2014-01-30
📝 Original message:On Thu, Jan 30, 2014 at 07:03:57PM +0700, Chuck wrote:
> On 1/30/2014 7:02 PM, Pieter Wuille wrote:
> > On Thu, Jan 30, 2014 at 12:59 PM, Mike Hearn <mike at plan99.net> wrote:
> >> With the way it works in bitcoinj, the tx is only committed to the wallet if
> >> the server accepts the Payment message and ACKs it. So the tx would not be
> >> retried if there's a failure submitting or some kind of internal server
> >> error, and the UI would show that the payment failed. That seems
> >> straightforward and how I'd expect things to work as a user.
> > That's one right way to do it imho, but not what is suggested or
> > required by the specification, and not what bitcoin core master
> > currently implements.
> >
> If you sent the Payment message and the server goes silent after
> receiving it, you retry to delivery. However, the merchant can
> broadcast the transactions and force them into your wallet anyway. You
> could, quite likely, pay and never get an ACK.
I think in that case, you absolultely have to invalidate all the
transactions in the Payment message by broadcasting a send-to-self
transaction as soon as possible; until that point your wallet balance
is indeterminate. Otherwise what will happen if the merchant did in
fact receive the Payment message, and then processes it (and
broadcasts the transaction) after some delay?
Then what the user will see is: an apparently failed attempt to pay,
leaving their wallet balance unchanged. Then, perhaps many hours
later, their wallet balance will appear to spontaneously decrement.
roy

2023-06-07 15:12:43

- reply

📅 Original date posted:2014-01-27
📝 Original message:On Mon, Jan 27, 2014 at 09:11:08AM -0800, Jeremy Spilman wrote:
> On Mon, 27 Jan 2014 03:59:25 -0800, Andreas Schildbach
> <andreas at schildbach.de> wrote:
>
> > SCAN TO PAY
> > For scan-to-pay, the current landscape looks different. I assume at
> > least 50% of Bitcoin transactions are initiated by a BIP21 URL encoded
> > into a QR-code. Nevertheless, I tried to encode a payment request into
> > the bitcoin URL. I used my existing work on encoding transactions into
> > QR-codes. Steps to encode:
>
> Really interesting work. When using scan-to-pay, after the payer scans the
> QR code with the protobuf PaymentRequest (not a URL to download the
> PaymentRequest) are they using their own connectivity to submit the
> Payment response?
>
> If we assume connectivity on the phone, might as well just get a URL from
> the QR code and re-use existing infrastructure for serving that?
My first thought was likewise. In the case where the phone needs
Internet connectivity anyway, why not include an HTTPS URL in a BIP 72 URL?
I'm assuming that every client will have to support this is any case,
since it's effectively mandated by the BIP, so why add another mode of
operation?
However, PaymentRequest-over-QR-code does seem to me to have one
rather attractive advantage: the authentication model is orders of
magnitude simpler and more intuitive for a face-to-face transaction
than anything else. You're saying "pay the coins to that thing over
there displaying that QR code". Which, most of the time, is exactly
what you want.
In the web case, it's fine to ignore the case where the URL domain has
been subverted (and an cert obtained by the attacker) because in that
case you've lost before you even get to payments (MitM attacker shows
you a modified web page with different payment details). But the
face-to-face case isn't intrinsically dependent on SSL security, and
it's nice not to introduce that attack vector...
roy

2023-06-07 15:11:55

- reply

📅 Original date posted:2014-01-13
📝 Original message:> It's not public. When I say "please pay me" I also say "use this
> multiplier".
Sending a "please pay me" message is really great for business
transactions.
But I think the use case that Peter Todd mentions is actually *the*
most important currently under-addresesd use case:
> With stealth addresses the user experience can be as simple as you
> telling me on the phone "hey! send me that 0.234 BTC you owe me!",
> me clicking on "Send to Alan Reiner (verified by PGP)" (perhaps
> again on my off-line second factor device for a multi-sig wallet)
> and tellling you "OK, sent".
Lots of work is being done on handling consumer-to-merchant
transactions. BIP 70 does a good job of tackling the online purchase
case, and the work that Andreas Schildbach is doing with Bluetooth and
NFC will improve the options for a payer in a physical PoS transaction
who might not have Internet connectivity on their smartphone.
But relatively little work (that I know of) is being done on
non-transactional personal payments - that is, being able to pay money
to friends and other people that you have a face-to-face relationship
with.
What I want... no need... is to be able to open my wallet, select a
friend from my address book, and transfer the $10 I owe them from the
bar last night.
I don't care - within reason - what process is involved in getting my
friend set up in my address book. That may well requires two way
communication (e.g. over NFC). But once it's set up, I should be able
to just select the payee from the address book and send them some
funds. Anything else is just too complciated.
I don't know if stealth addresses are the best solution to address
this use case, but AFAIK the only current solution to this use case is
to store a long-lived Bitcoin address in the addresss book.
roy

2023-06-07 15:11:51

- reply

📅 Original date posted:2014-01-13
📝 Original message:On Mon, Jan 13, 2014 at 01:52:25AM -0800, Gregory Maxwell wrote:
> On Sun, Jan 12, 2014 at 1:18 PM, Gavin Andresen <gavinandresen at gmail.com> wrote:
> > No, please. Make it easy for non-geeks, extend the payment protocol, or
> > we'll spend the next two years writing code that tries to ignore linebreaks
> > and spaces and changing <input> elements in HTML forms to <textarea> ....
>
> However, if you're able to use the payment protocol then you probably
> don't need stealth addresses to prevent reuse.
I definitely think this is a case that should be addressed better than
at present.
To consider a concrete use case, imagine I wish to be able to give my
friends and acquaintances a paper business card with a QR code on it,
that they can use to make payments to me. I don't own a domain or any
kind of X.509 certificate and I don't run an HTTP server. I don't
feel comfortable with a solution that requires me to trust a third
party to complete the payments.
At the moment, I can give them a business card with a Bitcoin address.
Being able to give out a business card with a stealth address would be
a major advance.
roy

2023-06-07 15:11:51

- reply

📅 Original date posted:2014-01-13
📝 Original message:> > Likewise, I could attach a payment request to an email and send it to you,
> > and now you can pay me whenever you want forever.
>
> That certainly sounds like a plausible use case. You do still have
> the problem that e-mail is an insecure channel, but it's no worse than
> exchanging Bitcoin addreses over e-mail as things stand at the
> moment.
On further reflection, I'm not sure I understand this use case of the
payment protocol. Since a PaymentRequest currently contains the
Outputs that specify the addresses to send to, reusing a
PaymentRequest like this without using stealth addresses implies
address reuse.
(Granted there are alternative solutions to stealth addresses, such as
a BIP32-style derivation.)
roy

2023-06-07 15:11:51

- reply

📅 Original date posted:2014-01-13
📝 Original message:rOn Mon, Jan 13, 2014 at 08:57:33PM +0100, Mike Hearn wrote:
> >
> > On further reflection, I'm not sure I understand this use case of the
> > payment protocol. Since a PaymentRequest currently contains the
> > Outputs that specify the addresses to send to, reusing a
> > PaymentRequest like this without using stealth addresses implies
> > address reuse.
>
>
> Yes indeed ...... which is why we're talking about extending the protocol
> (in a future version! the first version isn't even out yet!).
Yes, sorry, I miscontrued the thread here and now see that your
message was exactly talking about using stealth addresses within the
payment protocol.
Sorry for the confusion.
roy

2023-06-07 15:11:42

- reply

📅 Original date posted:2014-01-15
📝 Original message:On Wed, Jan 15, 2014 at 03:44:17PM -0500, Jeff Garzik wrote:
> "static address" seems like a reasonable attempt at describing intended
> use/direction.
...as opposed to an address configured by DHCP?
More seriously, I don't think a typical user will understand anything from
the phrase "static address". But it is a neutral name, and it is shorter
than "address-of-a-type-for-which-reuse-is-not-deprecated". :-)
-roy

2023-06-07 15:11:42

- reply

📅 Original date posted:2014-01-15
📝 Original message:How about just calling them 'type S addresses'?
Not sure any other name will in reality convey much more meaning than
that.
On Wed, Jan 15, 2014 at 06:07:28PM -0500, Jeff Garzik wrote:
> "Routing address" is pretty good too. Unsure whether the synergy and
> familiarity with bank routing numbers improves the situation, or
> not...
>
>
> On Wed, Jan 15, 2014 at 6:04 PM, Roy Badami <roy at gnomon.org.uk> wrote:
> > On Wed, Jan 15, 2014 at 03:44:17PM -0500, Jeff Garzik wrote:
> >> "static address" seems like a reasonable attempt at describing intended
> >> use/direction.
> >
> > ...as opposed to an address configured by DHCP?
> >
> > More seriously, I don't think a typical user will understand anything from
> > the phrase "static address". But it is a neutral name, and it is shorter
> > than "address-of-a-type-for-which-reuse-is-not-deprecated". :-)
> >
> > -roy
>
>
>
> --
> Jeff Garzik
> Bitcoin core developer and open source evangelist
> BitPay, Inc. https://bitpay.com/
>

2023-06-07 15:11:42

- reply

📅 Original date posted:2014-01-15
📝 Original message:On Wed, Jan 15, 2014 at 11:17:33PM +0000, I wrote:
> How about just calling them 'type S addresses'?
(Assuming they're encoded in such as way that they actually start with 's'.
Otherwise whatever prefix is actually used, obviously.)

2023-06-07 15:11:40

- reply

📅 Original date posted:2014-01-14
📝 Original message:On Mon, Jan 13, 2014 at 04:58:01PM +0100, Mike Hearn wrote:
>
> Signing a payment request for an individual is easy, anyway, depending on
> the kind of ID you want. If you want to sign with an email address, just go
> here with a browser like Chrome/Safari/IE that uses the system keystore:
>
> http://www.comodo.com/home/email-security/free-email-certificate.php
Having now read that page, I'll just leave you with the first bullet
point from it:
* Digital signature ensures confidentiality
(I'm not trying to make any particular point here - I just couldn't resist)
roy

2023-06-07 15:11:40

- reply

📅 Original date posted:2014-01-13
📝 Original message:On Mon, Jan 13, 2014 at 04:58:01PM +0100, Mike Hearn wrote:
> Signing a payment request for an individual is easy, anyway, depending on
> the kind of ID you want. If you want to sign with an email address, just go
> here with a browser like Chrome/Safari/IE that uses the system keystore:
>
> http://www.comodo.com/home/email-security/free-email-certificate.php
>
Ok, cool, I wasn't aware of such services, and I can certainly see
they could be useful. But it's not that great for the business card
scenario.
As far as I can see, using it in that scenario would have to rely on
the payer scanning the QR code on the business card, and then check
that the email address displayed by their wallet matched the email
address printed on the business card.
roy

2023-06-07 15:11:39

- reply

📅 Original date posted:2014-01-13
📝 Original message:> I was thinking that people could upload a payment protocol file somewhere
> once (like to their personal web page, or shared via dropbox or google
> drive or some custom new pastebin style service), and then just encode a
> regular bitcoin URI into the qrcode on the billboard.
That does require trusting the third party not to later tamper with
the payment request, though. (I'm assuming that a signed payment
request is not always going to be all that useful in the case of
private individuals, even assuming the payee is willing to sign up for
one.)
> Likewise, I could attach a payment request to an email and send it to you,
> and now you can pay me whenever you want forever.
That certainly sounds like a plausible use case. You do still have
the problem that e-mail is an insecure channel, but it's no worse than
exchanging Bitcoin addreses over e-mail as things stand at the
moment.
roy

2023-06-07 15: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 15: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 15:10:22

- reply

📅 Original date posted:2013-12-10
📝 Original message:On Mon, Dec 09, 2013 at 02:55:02PM +0000, Drak wrote:
> On 9 December 2013 13:52, Roy Badami <roy at gnomon.org.uk> wrote:
> >
> > On Mon, Dec 09, 2013 at 01:39:51PM +0000, Drak wrote:
> > > Someone needs to update the bitcoin.org website, it still points
> > downloads
> > > to 0.8.5
> >
> > Perhaps because 0.8.6 hasn't been released yet? Or did I miss the
> > announcement? I think it makes sense that release candidates are not
> > promoted on bitcoin.org.
>
>
> It was released and it's all over bitcointalk/reddit
Oh, I see - so it was. It wasn't announced here though - is there
some other list I need to be on, too? It would be nice if
announcements like this were posted to a mailing list as well as
bitcointalk.org (is there a bitcoin-announce list that I missed? If
not, maybe there should be)
roy

2023-06-07 15:10:20

- reply

📅 Original date posted:2013-12-09
📝 Original message:On Mon, Dec 09, 2013 at 01:39:51PM +0000, Drak wrote:
> Someone needs to update the bitcoin.org website, it still points downloads
> to 0.8.5
Perhaps because 0.8.6 hasn't been released yet? Or did I miss the
announcement? I think it makes sense that release candidates are not
promoted on bitcoin.org.
> ------------------------------------------------------------------------------
> Sponsored by Intel(R) XDK
> Develop, test and display web and hybrid apps with a single code base.
> Download it for free now!
> http://pubads.g.doubleclick.net/gampad/clk?id=111408631&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 15: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 15:05:38

- reply

📅 Original date posted:2013-08-07
📝 Original message: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

2023-06-07 15: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 15:05:36

- reply

📅 Original date posted:2013-08-07
📝 Original message:On Wed, Jul 31, 2013 at 05:30:46PM -0600, E willbefull wrote:
> I think it's important to expect PaymentRequest-only bitcoin URIs in the
> future. Some types of payments (exotic transactions) may not make sense to
> have a single fallback address. Or, a page with a bitcoin URI link may be
> relying on a separate service provider to assemble the transaction.
Also:
* There may be a desire to minimize the URL length when used in a QR code
* Some applications might specifically require some of the features of
the payment protocol - e.g. it may be a requirement that a print-media
QR code cannot be used after a cut-off date, or a vendor may have a
specific requirement not to accept payments without a refund address
There are pros and cons, but it's not clear to me that the benefits of
enforced backward compatibility outweigh the benefits of allowing
application designers to innovate as they see fit.
roy

2023-06-07 15: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 15: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 11:42:50

- reply

📅 Original date posted:2013-04-01
📝 Original message:And the moment I hit send I realised it's not necessarily true.
Conceivably, a collision attack might help you craft two commits (one
good, one bad) with the same hash.
But I still maintain what I just posted is true: if someone gets
malicious code into the repo, it's going to be by social engineering,
not by breaking the cyrpto.
roy
On Mon, Apr 01, 2013 at 11:51:07PM +0100, Roy Badami wrote:
> The attack Schneier is talking about is a collision attack (i.e. it
> creates two messages with the same hash, but you don't get to choose
> either of the messages). It's not a second preimage attack, which is
> what you would need to be able to create a message that hashes to the
> same value of an existing message.
>
> (And it neither have anything to do with the birthday paradox, BTW -
> which relates to the chance of eventually finding two messages that
> hash to the same value by pure change)
>
> If someone gets malicious code into the repo, it's going to be by
> social engineering, not by breaking the cyrpto.
>
> roy
>
> On Tue, Apr 02, 2013 at 12:27:51AM +0200, Melvin Carvalho wrote:
> > On 2 April 2013 00:10, Will <will at phase.net> wrote:
> >
> > > The threat of a SHA1 collision attack to insert a malicious pull request
> > > are tiny compared with the other threats - e.g. github being compromised,
> > > one of the core developers' passwords being compromised, one of the core
> > > developers going rogue, sourceforge (distribution site) being compromised
> > > etc etc... believe me there's a lot more to worry about than a SHA1
> > > attack...
> > >
> > > Not meaning to scare, just to put things in perspective - this is why we
> > > all need to peer review each others commits and keep an eye out for
> > > suspicious commits, leverage the benefits of this project being open source
> > > and easily peer reviewed.
> > >
> >
> > Very good points, and I think you're absolutely right.
> >
> > But just running the numbers, to get the picture, based of scheiner's
> > statistics:
> >
> > http://www.schneier.com/blog/archives/2012/10/when_will_we_se.html
> >
> > We're talking about a million terrahashes = 2^60 right?
> >
> > With the block chain, you only have a 10 minute window, but with source
> > code you have a longer time to prepare.
> >
> > Couldnt this be done with an ASIC in about a week?
> >
> >
> >
> > >
> > > Will
> > >
> > >
> > > On 1 April 2013 23:52, Melvin Carvalho <melvincarvalho at gmail.com> wrote:
> > >
> > >>
> > >>
> > >>
> > >> On 1 April 2013 20:28, Petr Praus <petr at praus.net> wrote:
> > >>
> > >>> An attacker would have to find a collision between two specific pieces
> > >>> of code - his malicious code and a useful innoculous code that would be
> > >>> accepted as pull request. This is the second, much harder case in the
> > >>> birthday problem. When people talk about SHA-1 being broken they actually
> > >>> mean the first case in the birthday problem - find any two arbitrary values
> > >>> that hash to the same value. So, no I don't think it's a feasible attack
> > >>> vector any time soon.
> > >>>
> > >>> Besides, with that kind of hashing power, it might be more feasible to
> > >>> cause problems in the chain by e.g. constantly splitting it.
> > >>>
> > >>
> > >> OK, maybe im being *way* too paranoid here ... but what if someone had
> > >> access to github, could they replace one file with one they had prepared at
> > >> some point?
> > >>
> > >>
> > >>>
> > >>>
> > >>> On 1 April 2013 03:26, Melvin Carvalho <melvincarvalho at gmail.com> wrote:
> > >>>
> > >>>> I was just looking at:
> > >>>>
> > >>>> https://bitcointalk.org/index.php?topic=4571.0
> > >>>>
> > >>>> I'm just curious if there is a possible attack vector here based on the
> > >>>> fact that git uses the relatively week SHA1
> > >>>>
> > >>>> Could a seemingly innocuous pull request generate another file with a
> > >>>> backdoor/nonce combination that slips under the radar?
> > >>>>
> > >>>> Apologies if this has come up before ...
> > >>>>
> > >>>>
> > >>>> ------------------------------------------------------------------------------
> > >>>> Own the Future-Intel® Level Up Game Demo Contest 2013
> > >>>> Rise to greatness in Intel's independent game demo contest.
> > >>>> Compete for recognition, cash, and the chance to get your game
> > >>>> on Steam. $5K grand prize plus 10 genre and skill prizes.
> > >>>> Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d
> > >>>> _______________________________________________
> > >>>> Bitcoin-development mailing list
> > >>>> Bitcoin-development at lists.sourceforge.net
> > >>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> > >>>>
> > >>>>
> > >>>
> > >>
> > >>
> > >> ------------------------------------------------------------------------------
> > >> Own the Future-Intel® Level Up Game Demo Contest 2013
> > >> Rise to greatness in Intel's independent game demo contest.
> > >> Compete for recognition, cash, and the chance to get your game
> > >> on Steam. $5K grand prize plus 10 genre and skill prizes.
> > >> Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d
> > >> _______________________________________________
> > >> Bitcoin-development mailing list
> > >> Bitcoin-development at lists.sourceforge.net
> > >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> > >>
> > >>
> > >
>
> > ------------------------------------------------------------------------------
> > Own the Future-Intel® Level Up Game Demo Contest 2013
> > Rise to greatness in Intel's independent game demo contest.
> > Compete for recognition, cash, and the chance to get your game
> > on Steam. $5K grand prize plus 10 genre and skill prizes.
> > Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d
>
> > _______________________________________________
> > Bitcoin-development mailing list
> > Bitcoin-development at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
> ------------------------------------------------------------------------------
> Own the Future-Intel® Level Up Game Demo Contest 2013
> Rise to greatness in Intel's independent game demo contest.
> Compete for recognition, cash, and the chance to get your game
> on Steam. $5K grand prize plus 10 genre and skill prizes.
> Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

2023-06-07 11:42:47

- reply

📅 Original date posted:2013-04-01
📝 Original message:The attack Schneier is talking about is a collision attack (i.e. it
creates two messages with the same hash, but you don't get to choose
either of the messages). It's not a second preimage attack, which is
what you would need to be able to create a message that hashes to the
same value of an existing message.
(And it neither have anything to do with the birthday paradox, BTW -
which relates to the chance of eventually finding two messages that
hash to the same value by pure change)
If someone gets malicious code into the repo, it's going to be by
social engineering, not by breaking the cyrpto.
roy
On Tue, Apr 02, 2013 at 12:27:51AM +0200, Melvin Carvalho wrote:
> On 2 April 2013 00:10, Will <will at phase.net> wrote:
>
> > The threat of a SHA1 collision attack to insert a malicious pull request
> > are tiny compared with the other threats - e.g. github being compromised,
> > one of the core developers' passwords being compromised, one of the core
> > developers going rogue, sourceforge (distribution site) being compromised
> > etc etc... believe me there's a lot more to worry about than a SHA1
> > attack...
> >
> > Not meaning to scare, just to put things in perspective - this is why we
> > all need to peer review each others commits and keep an eye out for
> > suspicious commits, leverage the benefits of this project being open source
> > and easily peer reviewed.
> >
>
> Very good points, and I think you're absolutely right.
>
> But just running the numbers, to get the picture, based of scheiner's
> statistics:
>
> http://www.schneier.com/blog/archives/2012/10/when_will_we_se.html
>
> We're talking about a million terrahashes = 2^60 right?
>
> With the block chain, you only have a 10 minute window, but with source
> code you have a longer time to prepare.
>
> Couldnt this be done with an ASIC in about a week?
>
>
>
> >
> > Will
> >
> >
> > On 1 April 2013 23:52, Melvin Carvalho <melvincarvalho at gmail.com> wrote:
> >
> >>
> >>
> >>
> >> On 1 April 2013 20:28, Petr Praus <petr at praus.net> wrote:
> >>
> >>> An attacker would have to find a collision between two specific pieces
> >>> of code - his malicious code and a useful innoculous code that would be
> >>> accepted as pull request. This is the second, much harder case in the
> >>> birthday problem. When people talk about SHA-1 being broken they actually
> >>> mean the first case in the birthday problem - find any two arbitrary values
> >>> that hash to the same value. So, no I don't think it's a feasible attack
> >>> vector any time soon.
> >>>
> >>> Besides, with that kind of hashing power, it might be more feasible to
> >>> cause problems in the chain by e.g. constantly splitting it.
> >>>
> >>
> >> OK, maybe im being *way* too paranoid here ... but what if someone had
> >> access to github, could they replace one file with one they had prepared at
> >> some point?
> >>
> >>
> >>>
> >>>
> >>> On 1 April 2013 03:26, Melvin Carvalho <melvincarvalho at gmail.com> wrote:
> >>>
> >>>> I was just looking at:
> >>>>
> >>>> https://bitcointalk.org/index.php?topic=4571.0
> >>>>
> >>>> I'm just curious if there is a possible attack vector here based on the
> >>>> fact that git uses the relatively week SHA1
> >>>>
> >>>> Could a seemingly innocuous pull request generate another file with a
> >>>> backdoor/nonce combination that slips under the radar?
> >>>>
> >>>> Apologies if this has come up before ...
> >>>>
> >>>>
> >>>> ------------------------------------------------------------------------------
> >>>> Own the Future-Intel® Level Up Game Demo Contest 2013
> >>>> Rise to greatness in Intel's independent game demo contest.
> >>>> Compete for recognition, cash, and the chance to get your game
> >>>> on Steam. $5K grand prize plus 10 genre and skill prizes.
> >>>> Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d
> >>>> _______________________________________________
> >>>> Bitcoin-development mailing list
> >>>> Bitcoin-development at lists.sourceforge.net
> >>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >>>>
> >>>>
> >>>
> >>
> >>
> >> ------------------------------------------------------------------------------
> >> Own the Future-Intel® Level Up Game Demo Contest 2013
> >> Rise to greatness in Intel's independent game demo contest.
> >> Compete for recognition, cash, and the chance to get your game
> >> on Steam. $5K grand prize plus 10 genre and skill prizes.
> >> Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d
> >> _______________________________________________
> >> Bitcoin-development mailing list
> >> Bitcoin-development at lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >>
> >>
> >
> ------------------------------------------------------------------------------
> Own the Future-Intel® Level Up Game Demo Contest 2013
> Rise to greatness in Intel's independent game demo contest.
> Compete for recognition, cash, and the chance to get your game
> on Steam. $5K grand prize plus 10 genre and skill prizes.
> Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

2023-06-07 11:42:10

- reply

📅 Original date posted:2013-03-25
📝 Original message:On Mon, Mar 25, 2013 at 02:10:53PM -0700, Gregory Maxwell wrote:
> On Mon, Mar 25, 2013 at 1:49 PM, Roy Badami <roy at gnomon.org.uk> wrote:
> > I'm not envisaging something as drastic as changing the rules to make
> > transactions to revoked addresses invalid - just an overlay protocol.
> > Although to be useful such a protocol would have to be pretty much
> > universally implemented by clients.
>
> That is quite drastic enough, as it requires adding more perpetual
> data that must remain in fast lookup for all validating nodes (the set
> of revoked 'addresses').
Maybe it should be possible for addresses to contain expiry dates, so
that revocation lists don't need to hang around forever.
> Keep in mind that this is only improvement for what is a usually
> inadvisable usage of Bitcoin to begin with... you should not be
> reusing addresses.
It may be inadvisable but in many cases it is pretty much unavoidable
as Bitcoin stands today. Granted, the payment protocol will help with
that in many use cases...
roy

2023-06-07 11:42:04

- reply

📅 Original date posted:2013-03-25
📝 Original message:On Fri, Feb 22, 2013 at 11:08:51PM +0000, I wrote:
> What would be really nice is for bitcoin to have a big key compromise
> button, which would automatically transfer all coins to newly
> generated addresses (optionally with a pause between generation and
> transaction - to allow for a new wallet backup). Optionally, too, the
> compromised/retired addresses could be marked with a flag such that if
> someone sends coins to that address bitcoind immediately generates a
> transaction to transfer the coins to address(es) which are good.
On Mon, Feb 25, 2013 at 09:23:53AM -0800, Andrew Poelstra wrote:
> The problem with automatic transactions would be: by repeatedly sending
> money to an address and seeing if it always moves quickly, an attacker
> can identify (a) that an address is in use, (b) which public key it has
> (if this isn't already public), and (c) that the key is believed to be
> compromised.
I realise on reflection that what I really want is not automatic
transmissions, but a means to revoke an address.
The problem is that after transfering the coins from the compromised
addresses to a new, hopefully safe address, what to do about the fact
that third parties might still try to send me coins to an old,
compromised address. So what I think I'm suggesting is that there
should be an address revocation protocol, such that clients will give
an error if their user tries to send coins to a revoked address.
Unless we think that direct payments to addresses will become
completely obsolete once the payment protocol is in use, in which case
(maybe) this functionality belongs in the payment protocol instead -
but I remain unconvinced of that.
I'm not envisaging something as drastic as changing the rules to make
transactions to revoked addresses invalid - just an overlay protocol.
Although to be useful such a protocol would have to be pretty much
universally implemented by clients.
Thoughts?
roy

2023-06-07 11: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 11: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 11: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 11: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 11:34:11

- reply

📅 Original date posted:2013-03-05
📝 Original message:> Would be nice to have a secure page at bitcoin.org, though, rathar
> than having to go to github - certs from somewhere like Namecheap
> should cost you next to nothing.
And Namecheap now accept Bitcoin :-)
(Complete coincidence - I didn't know that when I posted)
roy

2023-06-07 11:34:08

- reply

📅 Original date posted:2013-03-03
📝 Original message:> (The reason for this is that (many? most? all?) CAs verify authority
> by having you place a file at some HTTP path on the domain in
> question.
IME most CAs verify by emailing hostmaster/webaster@ or one of the
contacts in the WHOIS. But you're right, still subject to a MitM.
Still better than nothing though.
I would have suggested an EV cert, but that's more expensive (and
still far from foolproof)
> Basically only helps with the evil hotspot/tor_exit problem.
Also helps protect against DNS spoofing attacks, but yes, you're
right. I should be checking GPG sigs but I'm lazy :-)
roy

2023-06-07 11:34:02

- reply

📅 Original date posted:2013-03-03
📝 Original message:On Sat, Mar 02, 2013 at 04:09:38PM -0500, Gavin Andresen wrote:
> My gpg key is on the bitcoin.org homepage: http://bitcoin.org/gavinandresen.asc
> .... which you can access securely (and see the history of) at:
> https://github.com/bitcoin/bitcoin.org/blob/master/gavinandresen.asc
Would be nice to have a secure page at bitcoin.org, though, rathar
than having to go to github - certs from somewhere like Namecheap
should cost you next to nothing. For those of us too lazy (not
paranoid enough) to bother with GPG, a (secure) page on bitoin.org
with the MD5 hashes of the binaries would be awesome...
roy

2023-06-07 11:33:26

- reply

📅 Original date posted:2013-02-22
📝 Original message:Has anyone been thinking about providing tools to allow users to cope
with key compromise - or more generally, to manage key retirement etc?
atm, if you suspect that your keys may be liable to compromise then
what would you have to do? You'd have to create a new wallet (on a
new computer? or is it easy to have two coexisting installs on one
computer?) And then you'd have to make one or more payments from the
old wallet to the new wallet, to transfer the coins. It's a pain, and
you've lost your address book, your transaction history, etc. And
unless you keep the old wallet about, too, you're a bit stuck if
someone makes a payment to one of the old addresses. It's something
that most users would baulk at unless they're really sure they're at
significant risk.
Of course, there are a spectrum of scenarios, ranging from having an
unencrypted wallet stolen by someone who knows what it is, through to
deciding that the passphrase you used to use when you only had a few
dollars worth of BTC maybe isn't good enough now you've got tens of
thousands of dollars worth of coins. Or maybe you have no reason to
suspect there is a risk of compromise, but just have a corporate key
management policy that recommends retiring keys after a period of
time.
What would be really nice is for bitcoin to have a big key compromise
button, which would automatically transfer all coins to newly
generated addresses (optionally with a pause between generation and
transaction - to allow for a new wallet backup). Optionally, too, the
compromised/retired addresses could be marked with a flag such that if
someone sends coins to that address bitcoind immediately generates a
transaction to transfer the coins to address(es) which are good.
I know deterministic wallets have many proponents - but personally I
like having a bag of keys - with the idea that over a period of time,
old keys will routinely be retired and their balances automatically
transfered to newly generated keys. If someone really manages to
crack the passphrase on that 10-year-old wallet backup they got hold
of, then if would be nice to minimise the damage they could do...
And, of course, I want a big panic button that allows me to
automatically transfer all my coins to new addresses ASAP if I
suddenly do something stupid, like accidentally type my passphrase
into my IRC window :-)
Thoughts? Is this functionality that there is any interest in
developing within the official client? If there is any interest in
this then obviously the first step would be to specify exactly what
functionality is wanted...
roy

2023-06-07 10:44:17

- reply

📅 Original date posted:2012-12-03
📝 Original message:On Mon, Dec 03, 2012 at 05:34:12PM -0500, Jeff Garzik wrote:
> You shouldn't need to escape and unescape data that is not being
> interpreted in any way.
Funilly enough pretty much all low-level links that make up the
Internet use either bit-stuffing or byte-stuffing to escape a
particular bit sequence or byte that terminates an HDLC frame.
I'm not particularly agreeing or disagreeing with you on the
suitability for the case at hand, but as an absolute your statement
doesn't hold water. The use of a terminator for a variable-length
data structure rather than a length prefix is a design desicion that
has little-to-nothing to do with the debate of text-versus-binary.
Anyone remember Holerith constants?
roy

2023-06-07 10:42:50

- reply

📅 Original date posted:2012-12-03
📝 Original message:On Mon, Dec 03, 2012 at 10:28:13PM +0100, Mike Hearn wrote:
> Witness the absurd design of SMTP that means you can't
> start a paragraph with the word From because that's a new-message
> marker!
Actually that has absolutely nothing to do with SMTP. It's down to
the file format of the standard BSD UNIX mailbox (which uses lines
beginning with 'From ' to delimit messages).
roy

2023-06-07 10:42:10

- reply

📅 Original date posted:2012-11-29
📝 Original message:On Thu, Nov 29, 2012 at 06:31:24PM +0100, Mike Hearn wrote:
> > I'd still like to understand the rationale for having the merchant
> > broadcast the transaction
>
> There are several reasons for this:
[snip]
All good reasons, thanks for the explanation.
Though I still like my idea of a ValidatePurchase message that allows
a buyer to ask a merchant "would you accept this payment?" without
actually supplying a signed transaction. Make it optional if you care
about minimising the number of round trips, e.g. for fast NFC
payments.
Having such a message reduces the extent to which you need to trust
the merchant not to spend a transaction that they've rejected. (And
in the non-Internet connected case this is particularly useful since
the client won't have the ability to broadcast a pay-to-self
transaction.)
roy

2023-06-07 10:42:01

- reply

📅 Original date posted:2012-11-29
📝 Original message:I'd still like to understand the rationale for having the merchant
broadcast the transaction - it seems to add complexity and create edge
cases.
How about this as an alternative proposal:
The buyer's client prepares the transaction and computes its txid. It
then sends a ValidatePurchase message to the merchant containing the
proposed Outputs and a copy of the merchant_data along with the txid.
Assuming the proposed payment is accepted as valid by the merchant,
the buyer's client simply broadcasts the pre-prepared transaction in
the normal way, and it is the merchant's responsibility to watch for
this transaction to arrive over the p2p network/blockchain to complete
the purchase. (So if the merchant rejects the purchase at the
ValidatePurchase stage, they never get to see the transaction that the
buyer prepared, and there's therefore no need for a send-to-self to
cancel it.)
An optional RequestReceipt message (perhaps containing the
merchant_data and txid) can be sent by the client after the
transaction has been broadcast - but by making this explicitly
optional it forces the merchant to rely on seeing the bitcoin
transaction to 'commit' the payment and not on the RequestReceipt
message.
As far as I can see this proposal has no edge cases where the buyer
and merchant have differing ideas as to whether the transaction has
'comitted' - or at least, no more edge cases than the standard bitcoin
protocol has.
roy

2023-06-07 10: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