<unnamed>

Public Key

npub18gjvug29c4yg46lmplq38e75gg6wn5mn8taytckcsr4jt8p74h3s5knkzl

Profile Code

nprofile1qqsr5fxwy9zu2jy2a0aslsgnul2yyd8f6den47j9utvgp6e9nsl2mccpzpmhxue69uhkummnw3ezuamfdejsuefr7n

Publishing to

nostr.wine

Last Notes

2023-06-07 19:55:07 CEST

- reply

📅 Original date posted:2017-01-04
📝 Original message:It's easy enough to mark a transaction as "pending". People with bank
accounts are familiar with the concept.
Although the risk of accepting gossip information from multiple random
peers, in the case where the sender does not control the receivers network
is still minimal. Random node operators have no incentive to send fake
transactions, and would need to control all the nodes a client connects to,
and find a non-false-positive address belonging to the victims wallet.
It's not impossible, but it's non trivial, would only temporarily show a
pending transaction, and provide no benefit to the node operator. There are
much juicier targets for an attacker with the ability to sybil attack the
entire bitcoin p2p network.
Aaron
On Tue, Jan 3, 2017 at 11:47 PM Jonas Schnelli <dev at jonasschnelli.ch> wrote:
> Hi
>
>
>
> > Unconfirmed transactions are incredibly important for real world use.
>
> > Merchants for instance are willing to accept credit card payments of
>
> > thousands of dollars and ship the goods despite the fact that the
>
> > transaction can be reversed up to 60 days later. There is a very large
>
> > cost to losing the ability to have instant transactions in many or
>
> > even most situations. This cost is typically well above the fraud risk.
>
> >
>
> > It's important to recognize that bitcoin serves a wide variety of use
>
> > cases with different profiles for time sensitivity and fraud risk.
>
> >
>
> I agree that unconfirmed transactions are incredibly important, but not
>
> over SPV against random peers.
>
>
>
> If you offer users/merchants a feature (SPV 0-conf against random
>
> peers), that is fundamentally insecure, it will – sooner or later – lead
>
> to some large scale fiasco, hurting Bitcoins reputation and trust from
>
> merchants.
>
>
>
> Merchants using and trusting 0-conf SPV transactions (retrieved from
>
> random peers) is something we should **really eliminate** through
>
> education and by offering different solution.
>
>
>
> There are plenty, more sane options. If you can't run your own full-node
>
> as a merchant (trivial), maybe co-use a wallet-service with centralized
>
> verification (maybe use two of them), I guess Copay would be one of
>
> those wallets (as an example). Use them in watch-only mode.
>
>
>
> For end-users SPV software, I think it would be recommended to...
>
> ... disable unconfirmed transactions during SPV against random peers
>
> ... enable unconfirmed transactions when using SPV against a trusted
>
> peer with preshared keys after BIP150
>
> ... if unconfirmed transactions are disabled, show how it can be enabled
>
> (how to run a full-node [in a box, etc.])
>
> ... educate, inform users that a transaction with no confirmation can be
>
> "stopped" or "redirected" any time, also inform about the risks during
>
> low-conf phase (1-5).
>
>
>
> I though see the point that it's nice to make use of the "incoming
>
> funds..." feature in SPV wallets. But – for the sake of stability and
>
> (risk-)scaling – we may want to recommend to scarify this feature and –
>
> in the same turn – to use privacy-preserving BFD's.
>
>
>
> </jonas>
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170104/793748c8/attachment.html>

2023-06-07 19:55:05 CEST

- reply

📅 Original date posted:2017-01-03
📝 Original message:If the sender doesn't control the receiver's network connection, then the
information the receiver gains by watching the mempool is if the
transaction has propagated across the bitcoin network. This is useful to
know in all kinds of situations.
Aaron Voisine
co-founder and CEO
breadwallet <http://breadwallet.com>
On Tue, Jan 3, 2017 at 3:06 PM, adiabat <rx at awsomnet.org> wrote:
> Mempool transactions have their place, but "unconfirmed" and "SPV" don't
> belong together. Only a full node can tell if a transaction may get
> confirmed, or is nonsense. Unfortunately all the light / SPV wallets I
> know of show mempool transactions, which makes it hard to go back... (e.g.
> "why doesn't your software show 0-conf! your wallet is broken!", somewhat
> akin to people complaining about RBF)
>
> So, this is easy, just don't worry about mempool filtering. Why are light
> clients looking at the mempool anyway? Maybe if there were some way to
> provide SPV proofs of all inputs, but that's a bit of a mess for full nodes
> to do.
>
> Without mempool filtering, I think the committed bloom filters would be a
> great improvement over the current bloom filter setup, especially for
> lightning network use cases (with lightning, not finding out about a
> transaction can make you lose money). I want to work on it and may be able
> to at some point as it's somewhat related to lightning.
>
> Also, if you're running a light client, and storing the filters the way
> you store block headers, there's really no reason to go all the way back to
> height 0. You can start grabbing headers at some point a while ago, before
> your set of keys was generated. I think it'd be very worth it even with
> GB-scale disk usage.
>
> -Tadge
>
>
> On Tue, Jan 3, 2017 at 5:18 PM, Aaron Voisine via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> Unconfirmed transactions are incredibly important for real world use.
>> Merchants for instance are willing to accept credit card payments of
>> thousands of dollars and ship the goods despite the fact that the
>> transaction can be reversed up to 60 days later. There is a very large cost
>> to losing the ability to have instant transactions in many or even most
>> situations. This cost is typically well above the fraud risk.
>>
>> It's important to recognize that bitcoin serves a wide variety of use
>> cases with different profiles for time sensitivity and fraud risk.
>>
>> Aaron
>>
>> On Tue, Jan 3, 2017 at 12:41 PM bfd--- via bitcoin-dev <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>>> The concept combined with the weak blocks system where miners commit
>>>
>>> to potential transaction inclusion with fractional difficulty blocks
>>>
>>> is possible. I'm not personally convinced that unconfirmed transaction
>>>
>>> display in a wallet is worth the privacy trade-off. The user has very
>>>
>>> little to gain from this knowledge until the txn is in a block.
>>>
>>>
>>>
>>>
>>>
>>> On 2017-01-01 13:01, Jonas Schnelli via bitcoin-dev wrote:
>>>
>>> > Hi
>>>
>>> >> We introduce several concepts that rework the lightweight Bitcoin
>>>
>>> >> client model in a manner which is secure, efficient and privacy
>>>
>>> >> compatible.
>>>
>>> >>
>>>
>>> >> The BFD can be used verbatim in replacement of BIP37, where the filter
>>>
>>> >> can be cached between clients without needing to be recomputed. It can
>>>
>>> >> also be used by normal pruned nodes to do re-scans locally of their
>>>
>>> >> wallet without needing to have the block data available to scan, or
>>>
>>> >> without reading the entire block chain from disk.
>>>
>>> > I started exploring the potential of BFD after this specification.
>>>
>>> >
>>>
>>> > What would be the preferred/recommended way to handle 0-conf/mempool
>>>
>>> > filtering – if & once BDF would have been deployed (any type,
>>>
>>> > semi-trusted oracles or protocol-level/softfork)?
>>>
>>> >
>>>
>>> > From the user-experience perspective, this is probably pretty important
>>>
>>> > (otherwise the experience will be that incoming funds can take serval
>>>
>>> > minutes to hours until they appear).
>>>
>>> > Using BIP37 bloom filters just for mempool filtering would obviously
>>>
>>> > result in the same unwanted privacy-setup.
>>>
>>> >
>>>
>>> > </jonas>
>>>
>>> >
>>>
>>> >
>>>
>>> > _______________________________________________
>>>
>>> > 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
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170103/7695adaf/attachment-0001.html>

2023-06-07 19:55:03 CEST

- reply

📅 Original date posted:2017-01-03
📝 Original message:Unconfirmed transactions are incredibly important for real world use.
Merchants for instance are willing to accept credit card payments of
thousands of dollars and ship the goods despite the fact that the
transaction can be reversed up to 60 days later. There is a very large cost
to losing the ability to have instant transactions in many or even most
situations. This cost is typically well above the fraud risk.
It's important to recognize that bitcoin serves a wide variety of use cases
with different profiles for time sensitivity and fraud risk.
Aaron
On Tue, Jan 3, 2017 at 12:41 PM bfd--- via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> The concept combined with the weak blocks system where miners commit
>
> to potential transaction inclusion with fractional difficulty blocks
>
> is possible. I'm not personally convinced that unconfirmed transaction
>
> display in a wallet is worth the privacy trade-off. The user has very
>
> little to gain from this knowledge until the txn is in a block.
>
>
>
>
>
> On 2017-01-01 13:01, Jonas Schnelli via bitcoin-dev wrote:
>
> > Hi
>
> >> We introduce several concepts that rework the lightweight Bitcoin
>
> >> client model in a manner which is secure, efficient and privacy
>
> >> compatible.
>
> >>
>
> >> The BFD can be used verbatim in replacement of BIP37, where the filter
>
> >> can be cached between clients without needing to be recomputed. It can
>
> >> also be used by normal pruned nodes to do re-scans locally of their
>
> >> wallet without needing to have the block data available to scan, or
>
> >> without reading the entire block chain from disk.
>
> > I started exploring the potential of BFD after this specification.
>
> >
>
> > What would be the preferred/recommended way to handle 0-conf/mempool
>
> > filtering – if & once BDF would have been deployed (any type,
>
> > semi-trusted oracles or protocol-level/softfork)?
>
> >
>
> > From the user-experience perspective, this is probably pretty important
>
> > (otherwise the experience will be that incoming funds can take serval
>
> > minutes to hours until they appear).
>
> > Using BIP37 bloom filters just for mempool filtering would obviously
>
> > result in the same unwanted privacy-setup.
>
> >
>
> > </jonas>
>
> >
>
> >
>
> > _______________________________________________
>
> > 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170103/56eb8944/attachment-0001.html>

2023-06-07 19:51:24 CEST

- reply

📅 Original date posted:2016-06-23
📝 Original message:On Thu, Jun 23, 2016 at 3:56 AM, Peter Todd via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> In any case, I'd strongly argue that we remove BIP75 from the bips
> repository,
> and boycott wallets that implement it. It's bad strategy for Bitcoin
> developers
> to willingly participate in AML/KYC, just the same way as it's bad for Tor
> to
> add wiretapping functionality, and W3C to support DRM tech. The minor
> tactical
> wins you'll get our of this aren't worth it.
>
>
Peter, BIP75 gives the parties transacting complete control over who they
choose to share their identity information with. This was the entire point
of the proposal. You authorize who you choose to give your payment address
to, and the sender can verify who they are sending payment to. All
communication and payment info are encrypted against third party snooping,
while still allowing asynchronous communication to accommodate ephemeral
mobile connections.
The fact that some people will choose to use this identity information for
AML/KYC purposes doesn't detract at all from the fact that it gives bitcoin
users the tools they need to keep their payment information private, and
only communicate it with the parties they choose.
Aaron Voisine
co-founder and CEO
breadwallet <http://breadwallet.com/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160623/a4f599d1/attachment.html>

2023-06-07 19:50:41 CEST

- reply

📅 Original date posted:2016-05-13
📝 Original message:That's a valid concern, but I don't see the conflict here. In order to
recover funds from a wallet conforming to BIPXX, you must have wallet
software that handles BIPXX. Simply making BIPXX backwards compatible with
previously created BIP44 or BIP43 purpose 0 wallets doesn't change this at
all.
Aaron Voisine
co-founder and CEO
breadwallet <http://breadwallet.com>
On Fri, May 13, 2016 at 10:57 AM, Pavol Rusnak <stick at satoshilabs.com>
wrote:
> On 13/05/16 18:59, Aaron Voisine wrote:
> > This scheme is independent of the number of accounts. It works with BIP44
> > as well as BIP43 purpose 0, or any other BIP43 purpose/layout. Instead of
> > overloading the account index to indicate the type of address, you use
> the
> > chain index, which is already being used to indicate what the specific
> > address chain is to be used for, i.e. receive vs change addresses.
>
> I see the advantage here. But there is a major problem here.
>
> We came up with BIP44 so a wallet can claim it is BIP44 compatible and
> you can be 100% sure that you can migrate accounts from one wallet
> implementation to another. This was not previously possible when a
> wallet claimed it is BIP32 compatible.
>
> Now we have a similar problem. When there is a BIP44 wallet, does it
> mean it supports segwit or not? For this reason I would like to see
> another BIPXX for segwit, so a wallet can claim it is BIP44, BIP44+BIPXX
> or BIPXX compatible and you'll know what other wallets are compatible
> with it.
>
> --
> Best Regards / S pozdravom,
>
> Pavol "stick" Rusnak
> SatoshiLabs.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160513/1fbda030/attachment.html>

2023-06-07 17:41:35 CEST

- reply

📅 Original date posted:2015-07-09
📝 Original message:Do you have any idea how much hashing power is using CPFP? It's a useful
metric for wallet developers to know what sort of confirmation times they
might be able to get when attempting to use it.
Aaron Voisine
co-founder and CEO
breadwallet.com
On Sun, Jul 5, 2015 at 9:24 PM, Luke Dashjr <luke at dashjr.org> wrote:
> On Monday, July 06, 2015 4:14:14 AM Dan Bryant wrote:
> > When I wrote the BIP proposal I was assuming (incorrectly) that CPFP TX
> > selection was already being done by miners,
>
> No, this is correct. It's just not included in the reference policy.
> Miners are not expected to use the reference policy as-is, and some of
> them do
> in fact use CPFP.
>
> Luke
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150708/0f48f29b/attachment.html>

2023-06-07 17:40:34 CEST

- reply

📅 Original date posted:2015-06-27
📝 Original message:On Sat, Jun 27, 2015 at 8:13 AM, Peter Todd <pete at petertodd.org> wrote:
> On 27 June 2015 03:14:41 GMT-04:00, Aaron Voisine <voisine at gmail.com>
> wrote:
> >Also remember that the sender is not the one who cares about delays or
> >even
> >getting confirmations at all, it's the receiver who's concerned with
> >these
> >things. They have to tell the sender up-front what they're willing to
> >accept in exchange for goods and services.
>
> You're assuming a receiver who is accepting a zeroconf transaction; most
> receivers don't.
>
> For instance, when I deposit funds on my exchange they don't credit those
> funds until 4 confirmations, so I very much cafe about how long it takes to
> get the first confirmation.
>
Yes, the receiver can tell the sender up-front that they are only willing
accept 4-confirmations, and put that on the sender to figure out, but the
sender then only cares because it's the receiver's requirement. The
receiver is the one who cares.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150627/37f62e6d/attachment.html>

2023-06-07 17:40:33 CEST

- reply

📅 Original date posted:2015-06-27
📝 Original message:Also remember that the sender is not the one who cares about delays or even
getting confirmations at all, it's the receiver who's concerned with these
things. They have to tell the sender up-front what they're willing to
accept in exchange for goods and services.
Aaron Voisine
co-founder and CEO
breadwallet.com
On Fri, Jun 26, 2015 at 11:13 PM, Filipe Farinha <filipe at ktorn.com> wrote:
> On 27/06/2015 03:36, Peter Todd wrote:
>
>> * Make websites with easy to understand displays of what the current
>> mempool
>> backlog is, and what fee/KB is needed to get to the front of the
>> queue. We've
>> done a great job for Bitcoin price charts, let's extend that to
>> transaction
>> fees.
>>
>> +1
>
> This is especially important if take into account all the projects that
> aim to build upon the bitcoin blockchain and that can have a significant
> impact, both in terms of storage space as well as transaction volume spikes.
>
> Just recently I suggested the need for a BIP to standardize reporting of
> "delay alerts" in wallets, so that users can act accordingly (i.e.
> fee-bump, postpone, cancel) before sending their transactions during these
> periods of increased transaction volume.
>
>
> https://community.blockstack.org/t/blockstore-footprint-on-blockchain/68/5?u=ktorn
>
> IMHO keeping the users informed of potential issues before committing
> transactions to the network can go a long way towards preventing
> frustration and potential backlashes against blockchain tech.
>
> Filipe Farinha
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150627/f4084b54/attachment.html>

2023-06-07 17:40:31 CEST

- reply

📅 Original date posted:2015-06-26
📝 Original message:> Jeff, block size limits large enough to prevent fee pressure is
absolutely, unequivocally unsustainable.
This is demonstrably false. It's clear that having no fee pressure is
unsustainable, of course. But people are paying fees today, so that means
there must be fee pressure. How is this the case then since blocks are
typically below the block size limit? There must be some other mechanism
inducing fee pressure. This mechanism is standard minimum relay rules, and
transaction selection rules for blocks. These are the methods that all
bitcoin software today has been built around, and handles well.
Aaron Voisine
co-founder and CEO
breadwallet.com
On Fri, Jun 26, 2015 at 11:31 AM, Mark Friedenbach <mark at friedenbach.org>
wrote:
> Jeff, block size limits large enough to prevent fee pressure is
> absolutely, unequivocally unsustainable. We are already running against
> technological limits in the tradeoff between decentralization and utility.
> Increases of the block size limit in advance of fee pressure only delay the
> problem -- it does not and cannot solve it!
>
> We must be careful to use the block size limit now to get infrastructure
> to support a world with full blocks -- it's not that hard -- while still
> having a little room to grow fast if things unexpectedly break.
>
>
> On Fri, Jun 26, 2015 at 11:23 AM, Jeff Garzik <jgarzik at gmail.com> wrote:
>
>> Failure to plan now for a hard fork increase 6(?) months in the future
>> produces that lumpy, unpredictable market behavior.
>>
>> The market has baked in the years-long behavior of low fees. From the
>> market PoV, inaction does lead to precisely that, a sudden change over the
>> span of a few months.
>>
>> At a higher level, people look at bitcoin and see people delaying,
>> waiting, dawdling until the barn is actually on fire before taking action
>> to put out the fire.
>>
>> They see a system that is not responsive to higher level externalities of
>> people & businesses making plans for the future. Based on current proposal
>> of change-through-inaction, businesses will simply shelve plans to use
>> bitcoin and not bother putting those new users on the network.
>>
>> If you wait until the need to increase block size is acute, it is already
>> too late. (1) Businesses have permanently shelved plans to use bitcoin and
>> (2) change at that point produces _larger_ disruption to the fee market.
>>
>> Hard forks require planning many months in advance. Gavin's timing is
>> sound, even though the Gavin/Hearn Bitcoin-XT antics were sub-optimal.
>>
>>
>>
>>
>>
>>
>>
>> On Fri, Jun 26, 2015 at 11:12 AM, Pieter Wuille <pieter.wuille at gmail.com>
>> wrote:
>>
>>> I am not saying that economic change is what we want. Only that it is
>>> inevitable, independent of whether larger blocks happen or not.
>>>
>>> I am saying that acting because of fear of economic change is a bad
>>> reason. The reason for increase should be because of the higher utility. We
>>> need it at some point, but there should be no rush.
>>>
>>> I do understand that we want to avoid a *sudden* change in economic
>>> policy, but I'm generally not too worried. Either fees increase and they
>>> get paid, and we're good. But more likely is that some uses just move
>>> off-chain because the block chain does not offer what they need. That's
>>> sad, but it is inevitable at any size: some uses fit, some don't.
>>>
>>> --
>>> Pieter
>>> On Jun 26, 2015 7:57 PM, "Jeff Garzik" <jgarzik at gmail.com> wrote:
>>>
>>>> It is not "fear" of fee pressure.
>>>>
>>>> 1) Blocks are mostly not-full on average.
>>>>
>>>> 2) Absent long blocks and stress tests, there is little fee pressure
>>>> above the anti-spam relay fee metric, because of #1.
>>>>
>>>> 3) As such, inducing fee pressure is a delta, a change from years-long
>>>> bitcoin economic policy. Each time we approach the soft limit, Bitcoin
>>>> Core increases the soft limit to prevent "full" blocks. Mike Hearn et. al.
>>>> lobbies miners to upgrade.
>>>>
>>>> (note - this is not an endorsement of these actions - it is a neutral
>>>> observation)
>>>>
>>>> 4) Inaction leads to consistent fee pressure as the months tick on and
>>>> system volume grows; thus, inaction leads to economic policy change.
>>>>
>>>> 5) Economic policy change leads to market and software disruption. The
>>>> market and software - notably wallets - is not prepared for this.
>>>>
>>>> 6) If you want to change economic policy, that's fine. But be honest
>>>> and admit you are arguing for a change, a delta from current market
>>>> expectations and behavior.
>>>>
>>>> 7) It is critical to first deal with what _is_, not what you wish the
>>>> world to be. You want a fee market to develop. There is nothing wrong
>>>> with that desire. It remains a delta from where we are today, and that is
>>>> critically relevant in a $3b+ market.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Fri, Jun 26, 2015 at 7:09 AM, Pieter Wuille <pieter.wuille at gmail.com
>>>> > wrote:
>>>>
>>>>> Hello all,
>>>>>
>>>>> here I'm going to try to address a part of the block size debate which
>>>>> has been troubling me since the beginning: the reason why people seem to
>>>>> want it.
>>>>>
>>>>> People say that larger blocks are necessary. In the long term, I agree
>>>>> - in the sense that systems that do not evolve tend to be replaced by other
>>>>> systems. This evolution can come in terms of layers on top of Bitcoin's
>>>>> blockchain, in terms of the technology underlying various aspects of the
>>>>> blockchain itself, and also in the scale that this technology supports.
>>>>>
>>>>> I do, however, fundamentally disagree that a fear for a change in
>>>>> economics should be considered to necessitate larger blocks. If it is, and
>>>>> there is consensus that we should adapt to it, then there is effectively no
>>>>> limit going forward. This is similar to how Congress voting to increase the
>>>>> copyright term retroactively from time to time is really no different from
>>>>> having an infinite copyright term in the first place. This scares me.
>>>>>
>>>>> Here is how Gavin summarizes the future without increasing block sizes
>>>>> in PR 6341:
>>>>>
>>>>> > 1. Transaction confirmation times for transactions with a given fee
>>>>> will rise; very-low-fee transactions will fail to get confirmed at all.
>>>>> > 2. Average transaction fee paid will rise
>>>>> > 3. People or applications unwilling or unable to pay the rising fees
>>>>> will stop submitting transactions
>>>>> > 4. People and businesses will shelve plans to use Bitcoin, stunting
>>>>> growth and adoption
>>>>>
>>>>> Is it fair to summarize this as "Some use cases won't fit any more,
>>>>> people will decide to no longer use the blockchain for these purposes, and
>>>>> the fees will adapt."?
>>>>>
>>>>> I think that is already happening, and will happen at any scale. I
>>>>> believe demand for payments in general is nearly infinite, and only a small
>>>>> portion of it will eventually fit on a block chain (independent of whether
>>>>> its size is limited by consensus rules or economic or technological means).
>>>>> Furthermore, systems that compete with Bitcoin in this space already offer
>>>>> orders of magnitude more capacity than we can reasonably achieve with any
>>>>> blockchain technology at this point.
>>>>>
>>>>> I don't know what subset of use cases Bitcoin will cater to in the
>>>>> long term. They have already changed - you see way less betting
>>>>> transactions these days than a few years ago for example - and they will
>>>>> keep changing, independent of what effective block sizes we end up with. I
>>>>> don't think we should be afraid of this change or try to stop it.
>>>>>
>>>>> If you look at graphs of block sizes over time (for example,
>>>>> http://rusty.ozlabs.org/?p=498), it seems to me that there is very
>>>>> little "organic" growth, and a lot of sudden changes (which could
>>>>> correspond to changing defaults in miner software, introduction of popular
>>>>> sites/services, changes in the economy). I think these can be seen as the
>>>>> economy changing to full up the available space, and I believe these will
>>>>> keep happening at any size effectively available.
>>>>>
>>>>> None of this is a reason why the size can't increase. However, in my
>>>>> opinion, we should do it because we believe it increases utility and
>>>>> understand the risks; not because we're afraid of what might happen if we
>>>>> don't hurry up. And from that point of view, it seems silly to make a huge
>>>>> increase at once...
>>>>>
>>>>> --
>>>>> Pieter
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150626/6fd41144/attachment.html>

2023-06-07 17:39:13 CEST

- reply

📅 Original date posted:2015-06-21
📝 Original message:We should use relay and default tx selection rules to raise the cost of
double spend attacks as far as it is easy and practical to do so. This
increases the value of the bitcoin network by making it practical to use in
more situations for more people. Merchants of course can't rely on them
being cryptographically safe, but the safer they are, the more useful.
The argument that since they can't be made perfectly safe, they should be
as easy as possible to reverse so that merchants learn not to rely on them,
is an incorrect one that reduces the usefulness and value of bitcoin.
Merchants will learn very quickly what the costs of accepting bitcoin
payments are, and the lower they are, the greater bitcoin merchant adoption
will be.
Aaron Voisine
co-founder and CEO
breadwallet.com
On Sat, Jun 20, 2015 at 5:54 PM, Eric Lombrozo <elombrozo at gmail.com> wrote:
> One more thing I would like to add to this thread: I want to make it
> unequivocally clear that I believe what is making double-spends easier has
> relatively little to do with the protocol and almost everything to do with
> poor software and poor security policy on the merchant end. Perhaps it
> isn’t prudent to push out changes to the relay policy that make these
> exploits even easier right now - but we NEED to be applying some kind of
> pressure on the merchant end to upgrade their stuff to be more resilient so
> that we have more room for changes on things like relay policy without
> significant disruption to the network.
>
> - Eric Lombrozo
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150621/d1b29009/attachment.html>

2023-06-07 17:38:59 CEST

- reply

📅 Original date posted:2015-06-19
📝 Original message:> What retail needs is escrowed microchannel hubs (what lightning provides,
for example), which enable untrusted instant payments. Not reliance on
single-signer zeroconf transactions that can never be made safe.
They don't need to be made cryptographically safe, they just have to be
safer than, for instance, credit card payments that can be charged back. As
long as it's reasonably good in practice, that's fine.
Aaron Voisine
co-founder and CEO
breadwallet.com
On Fri, Jun 19, 2015 at 6:09 PM, Mark Friedenbach <mark at friedenbach.org>
wrote:
> What retail needs is escrowed microchannel hubs (what lightning provides,
> for example), which enable untrusted instant payments. Not reliance on
> single-signer zeroconf transactions that can never be made safe.
>
> On Fri, Jun 19, 2015 at 5:47 PM, Andreas Petersson <andreas at petersson.at>
> wrote:
>
>> I have some experience here. If you are seriously suggesting these
>> measures, you might as well kill retail transactions altogether.
>>
>> In practice, if a retail place starts to accept bitcoin they have a
>> similar situation as with cash, only that the fraud potential is much
>> lower. (e.g. 100-dollar bill for a sandwich might turn out fake later)
>> and the fraud frequency is also much lower.
>>
>> 0-conf concerns were never a problem in practice. except for 2-way atms
>> i have never heard of a problem that was caused by double spends.
>> while adding these measures is generally positive, requiring them means
>> excluding 99.9% of the potential users. so you might as well not do it.
>>
>> RBF as implemented by F2Pool just flat out lowers Bitcoins utility
>> value. So it's a bad thing.
>>
>> for any online or automated system, waiting for a handful of
>> confirmations was always recommended practice.
>>
>> Am 19.06.2015 um 22:39 schrieb Matt Whitlock:
>> > Retail POS merchants probably should not be accepting vanilla Bitcoin
>> > payments, as Bitcoin alone does not (and cannot) guarantee the
>> > irreversibility of a transaction until it has been buried several
>> > blocks deep in the chain. Retail merchants should be requiring a
>> > co-signature from a mutually trusted co-signer that vows never to sign
>> > a double-spend.
>>
>>
>>
>> ------------------------------------------------------------------------------
>>
>> _______________________________________________
>> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150619/8f05595a/attachment.html>

2023-06-07 17:38:13 CEST

- reply

📅 Original date posted:2015-06-16
📝 Original message:Thanks Alex, the work you've pointed out is helpful. Limiting mempool size
should at least prevent nodes from crashing. When I looked a few days ago I
only found a few old PRs that seemed to have fallen by the wayside, so this
new one is encouraging.
I can respond in the PR comments if it's more appropriate there, but I
believe ejecting tx from mempools rather than preemptively refusing them
according to standard network wide propagation rules will result in spotty,
inconsistent tx propagation, and possibly a large increase in tx
re-broadcasts, so if those haven't been addressed they will need to be. It
would also be prudent to run some simulations to see what other issues are
going to pop-up.
We're currently using CPFP already in breadwallet when spending unconfirmed
non-change inputs. A small percentage of hashing power is using it, but
enough to get a transaction unstuck assuming breadwallet's fee calculation
is better than the sender's.
The problem with RBF is that there's currently no way to tell if your tx
has been picked up by miners or not in order to know if you need to replace
it. Miners broadcasting partial block solutions would be helpful in this
regard, but only for tx in the currently-being-worked-on block, not for tx
that won't be picked up until the block after. If miners were to eject tx
that were previously being worked on in favor of higher fee tx, then that
causes another set of problems for wallets that thought their tx was going
to get in but then it doesn't. The other problem with RBF is that users
don't know up front what fee they're actually going to pay which is a big
blow to real world usability. Also mobile wallets will have to sign lots of
tx up front and rely on a service to replace as necessary. And this is all
just on the send side. On the receive side it's much worse since you can't
rely on the sender to do the replacing. The real problem seems to be the
fact that RBF is an interactive iterative process rather than a
send-and-forget one.
What you really need is some way to tell up-front, is a transaction going
to get mined with a high probability? That problem seems really difficult
to solve with fixed-size blocks that are full. If the goal is simply to
reduce or limit the growth of the blockchain, then there are much simpler
solutions, which is why I've advocated for the blocksize increase, followed
by tx selection and propagation rule changes to create fee pressure.
Aaron Voisine
co-founder and CEO
breadwallet.com
On Mon, Jun 15, 2015 at 6:17 PM, Alex Morcos <morcos at gmail.com> wrote:
> Aaron,
>
> My understanding is that Gavin and Mike are proceeding with the XT fork, I
> hope that understanding is wrong.
>
> As for improving the non-consensus code to handle full blocks more
> gracefully. This is something I'm very interested in, block size increase
> or not. Perhaps I shouldn't hijack this thread, but maybe there are others
> who also believe this would ameliorate some of the time pressure for
> deciding on a block size increase.
>
> What is it that you would like to see improved?
> The fee estimation code that is included for 0.11 will give much more
> accurate fee estimates, which should allow adding the correct fee to a
> transaction to see it likely to be confirmed in a reasonable time. For
> further improvements:
> - There has recently been attention to overhauling the block creation and
> mempool limiting code in such a way that actual outstanding queues to be
> included in a block could also be incorporated in fee estimation. See
> https://github.com/bitcoin/bitcoin/pull/6281.
> - CPFP and RBF are candidates for inclusion in core soon, both of which
> could be integrated into transaction processing to handle the edge cases
> where a priori fee estimation fails. See
> https://github.com/bitcoin/bitcoin/pull/1647 and
> https://github.com/bitcoin/bitcoin/pull/6176
>
> I know there has been much discussion of fee estimation not working for
> SPV clients, but I believe several independent servers which were serving
> the estimates from full nodes would go a long way towards allowing that
> information to be used by SPV clients even if its not a completely
> decentralized solution. See for example
> http://core2.bitcoincore.org/smartfee/latest.json
>
>
>
> On Mon, Jun 15, 2015 at 8:08 PM, Aaron Voisine <voisine at gmail.com> wrote:
>
>> Wasn't the XT hard fork proposed as a last resort, should the
>> bitcoin-core maintainers simply refuse to lift the 1Mb limit? No one wants
>> to go that route. An alternate hard-fork proposal like BIP100 that gets
>> consensus, or a modified version of gavin's that ups the limit to 8Mb
>> instead of 20Mb, or hell even some major changes to the non-consunsus code
>> to make it adequately handle the situation when blocks fill up, and allow
>> wallet software to continue working with a send-and-forget use pattern, any
>> of these would be enough to avoid the need for an XT only hard-fork.
>>
>> So far BIP100 is the only one that seems to actually be getting any sort
>> of momentum toward consensus, and it was proposed... 2 days ago? When the
>> XT fork was proposed as a last resort, it was when the opponents were (to
>> my understanding) suggesting we just let blocks fill up, and hopefully
>> things would just work out on their own.
>>
>>
>>
>> Aaron Voisine
>> co-founder and CEO
>> breadwallet.com
>>
>> On Mon, Jun 15, 2015 at 3:56 PM, Brian Hoffman <brianchoffman at gmail.com>
>> wrote:
>>
>>> Who is actually planning to move to Bitcoin-XT if this happens?
>>>
>>> Just Gavin and Mike?
>>>
>>> [image: image1.JPG]
>>>
>>> On Jun 15, 2015, at 6:17 PM, Faiz Khan <faizkhan00 at gmail.com> wrote:
>>>
>>> I'm quite puzzled by the response myself, it doesn't seem to address
>>> some of the (more serious) concerns that Adam put out, the most important
>>> question that was asked being the one regarding personal ownership of the
>>> proposed fork:
>>>
>>> "How do you plan to deal with security & incident response for the
>>> duration you describe where you will have control while you are deploying
>>> the unilateral hard-fork and being in sole maintainership control?"
>>>
>>> I do genuinely hope that whomever (now and future) wishes to fork the
>>> protocol reconsider first whether they are truly ready to test/flex their
>>> reputation/skills/resources in this way... Intuitively, to me it seems
>>> counterproductive, and I don't fully believe it is within a single
>>> developer's talents to manage the process start-to-finish (as it is
>>> non-trivial to hard-fork successfully, others have rehashed this in other
>>> threads)...
>>>
>>> That being said I think it appropriate if Adam's questions were
>>> responded in-line when Mike is feeling up to it. I think that the answers
>>> are important for the community to hear when such a drastic change is being
>>> espoused.
>>>
>>> Faiz
>>>
>>> On Mon, Jun 15, 2015 at 4:56 PM, Bryan Bishop <kanzure at gmail.com> wrote:
>>>
>>>> On Mon, Jun 15, 2015 at 3:55 PM, Mike Hearn <mike at plan99.net> wrote:
>>>>
>>>>> Re: anyone who agrees with noted non-programmers Mike&Gavin must be
>>>>> non-technical, stupid, uninformed, etc .... OK, go ahead and show them the
>>>>> error of their ways. Anyone can write blogs.
>>>>>
>>>>
>>>> I worry that if this is the level of care you take with reading and
>>>> (mis)interpreting Adam's messages, that you might not be taking extreme
>>>> care with evaluating consensus changes, even while tired or sleeping. I
>>>> encourage you to evaluate both messages and source code more carefully,
>>>> especially in the world of bitcoin. However, this goes for everyone and not
>>>> just you. Specifically, when Adam mentioned your conversations with
>>>> non-technical people, he did not mean "Mike has talked with people who have
>>>> possibly not made pull requests to Bitcoin Core, so therefore Mike is a
>>>> non-programmer". Communication is difficult and I can understand that, but
>>>> we really have to be more careful when evaluating each other's messages;
>>>> technical miscommunication can be catastrophic in this context. On the
>>>> topic of whether you are a programmer, I suspect that ever since you built
>>>> CIA.vc we have all known you're a programmer, Mike.
>>>>
>>>> - Bryan
>>>> http://heybryan.org/
>>>> 1 512 203 0507
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>>
>>>> _______________________________________________
>>>> Bitcoin-development mailing list
>>>> Bitcoin-development at lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>>>
>>>> --
>>>>
>>>> My regards,
>>>>
>>>> Faiz Khan
>>>>
>>>> <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
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> 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
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150615/cb4817fe/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image1.JPG
Type: image/jpeg
Size: 22107 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150615/cb4817fe/attachment.jpe>

2023-06-07 17:38:12 CEST

- reply

📅 Original date posted:2015-06-15
📝 Original message:Wasn't the XT hard fork proposed as a last resort, should the bitcoin-core
maintainers simply refuse to lift the 1Mb limit? No one wants to go that
route. An alternate hard-fork proposal like BIP100 that gets consensus, or
a modified version of gavin's that ups the limit to 8Mb instead of 20Mb, or
hell even some major changes to the non-consunsus code to make it
adequately handle the situation when blocks fill up, and allow wallet
software to continue working with a send-and-forget use pattern, any of
these would be enough to avoid the need for an XT only hard-fork.
So far BIP100 is the only one that seems to actually be getting any sort of
momentum toward consensus, and it was proposed... 2 days ago? When the XT
fork was proposed as a last resort, it was when the opponents were (to my
understanding) suggesting we just let blocks fill up, and hopefully things
would just work out on their own.
Aaron Voisine
co-founder and CEO
breadwallet.com
On Mon, Jun 15, 2015 at 3:56 PM, Brian Hoffman <brianchoffman at gmail.com>
wrote:
> Who is actually planning to move to Bitcoin-XT if this happens?
>
> Just Gavin and Mike?
>
> [image: image1.JPG]
>
> On Jun 15, 2015, at 6:17 PM, Faiz Khan <faizkhan00 at gmail.com> wrote:
>
> I'm quite puzzled by the response myself, it doesn't seem to address some
> of the (more serious) concerns that Adam put out, the most important
> question that was asked being the one regarding personal ownership of the
> proposed fork:
>
> "How do you plan to deal with security & incident response for the
> duration you describe where you will have control while you are deploying
> the unilateral hard-fork and being in sole maintainership control?"
>
> I do genuinely hope that whomever (now and future) wishes to fork the
> protocol reconsider first whether they are truly ready to test/flex their
> reputation/skills/resources in this way... Intuitively, to me it seems
> counterproductive, and I don't fully believe it is within a single
> developer's talents to manage the process start-to-finish (as it is
> non-trivial to hard-fork successfully, others have rehashed this in other
> threads)...
>
> That being said I think it appropriate if Adam's questions were responded
> in-line when Mike is feeling up to it. I think that the answers are
> important for the community to hear when such a drastic change is being
> espoused.
>
> Faiz
>
> On Mon, Jun 15, 2015 at 4:56 PM, Bryan Bishop <kanzure at gmail.com> wrote:
>
>> On Mon, Jun 15, 2015 at 3:55 PM, Mike Hearn <mike at plan99.net> wrote:
>>
>>> Re: anyone who agrees with noted non-programmers Mike&Gavin must be
>>> non-technical, stupid, uninformed, etc .... OK, go ahead and show them the
>>> error of their ways. Anyone can write blogs.
>>>
>>
>> I worry that if this is the level of care you take with reading and
>> (mis)interpreting Adam's messages, that you might not be taking extreme
>> care with evaluating consensus changes, even while tired or sleeping. I
>> encourage you to evaluate both messages and source code more carefully,
>> especially in the world of bitcoin. However, this goes for everyone and not
>> just you. Specifically, when Adam mentioned your conversations with
>> non-technical people, he did not mean "Mike has talked with people who have
>> possibly not made pull requests to Bitcoin Core, so therefore Mike is a
>> non-programmer". Communication is difficult and I can understand that, but
>> we really have to be more careful when evaluating each other's messages;
>> technical miscommunication can be catastrophic in this context. On the
>> topic of whether you are a programmer, I suspect that ever since you built
>> CIA.vc we have all known you're a programmer, Mike.
>>
>> - Bryan
>> http://heybryan.org/
>> 1 512 203 0507
>>
>>
>> ------------------------------------------------------------------------------
>>
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>> --
>>
>> My regards,
>>
>> Faiz Khan
>>
>> <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
>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150615/8b369aeb/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image1.JPG
Type: image/jpeg
Size: 22107 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150615/8b369aeb/attachment.jpe>

2023-06-07 17:38:08 CEST

- reply

📅 Original date posted:2015-06-16
📝 Original message:With their money, if they were to take advantage of optional additional
financial services, like, as one example, comsumer protection insurance.
Aaron
On Tuesday, June 16, 2015, <justusranvier at riseup.net> wrote:
> On 2015-06-16 07:55, Aaron Voisine wrote:
>
>> Suppose a billion mobile phones wanted to run SPV wallets tomorrow. Who
>>> would provide the nodes they would need connect to?
>>>
>>
>> The SPV wallet author would if they wanted their wallet to function.
>>
>
> How will the SPV wallet users pay for this service? With their money, or
> with their privacy?
>
--
Aaron Voisine
co-founder and CEO
breadwallet.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150616/cc05c161/attachment.html>

2023-06-07 17:38:08 CEST

- reply

📅 Original date posted:2015-06-16
📝 Original message:Alternate funding strategy: With 1billion users, mr roger ver is now among
the worlds first $trillionaires, and he generously donates to the
non-profit organization responsible for both the wildly popular wallet, and
his new found largess.
On Tuesday, June 16, 2015, justusranvier at riseup.net <
justusranvier at riseup.net> wrote:
> On 2015-06-16 07:55, Aaron Voisine wrote:
>
>> Suppose a billion mobile phones wanted to run SPV wallets tomorrow. Who
>>> would provide the nodes they would need connect to?
>>>
>>
>> The SPV wallet author would if they wanted their wallet to function.
>>
>
> How will the SPV wallet users pay for this service? With their money, or
> with their privacy?
>
--
Aaron Voisine
co-founder and CEO
breadwallet.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150616/12b54e37/attachment.html>

2023-06-07 17:38:07 CEST

- reply

📅 Original date posted:2015-06-16
📝 Original message:> Suppose a billion mobile phones wanted to run SPV wallets tomorrow. Who
> would provide the nodes they would need connect to?
The SPV wallet author would if they wanted their wallet to function.
Aaron Voisine
co-founder and CEO
breadwallet.com
On Mon, Jun 15, 2015 at 10:28 PM, <justusranvier at riseup.net> wrote:
> On 2015-06-16 03:49, Kevin Greene wrote:
> > Hah, fair enough, there is no such thing as the "right" way to do
> > anything. But I still think punishing users who use SPV wallets is a
> > less-than-ideal way to incentive people to run full nodes. Right now
> > SPV is
> > the best way that exists for mobile phones to participate in the
> > network in
> > a decentralized way. This proposal makes the user experience for mobile
> > wallets a little more confusing and annoying.
>
> Suppose a billion mobile phones wanted to run SPV wallets tomorrow. Who
> would provide the nodes they would need connect to? The decentralization
> fairy?
>
> There's absolutely no reason that paying for connectivity would be any
> more confusing or annoying than transaction fees are.
>
> If some full nodes in the network started offering paid connection
> slots, that would just mean that users who checked the "pay subscription
> fee" box in their wallet configuration would have an easier time
> connecting than the users who did't, just like how your transaction
> might eventually get mined without a fee but paying one makes it faster
> and more probable.
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150616/1f849091/attachment.html>

2023-06-07 17:34:32 CEST

- reply

📅 Original date posted:2015-05-26
📝 Original message:See the "first-seen-safe replace-by-fee" thread
Aaron Voisine
co-founder and CEO
breadwallet.com
On Tue, May 26, 2015 at 11:22 AM, Danny Thorpe <danny.thorpe at gmail.com>
wrote:
> What prevents RBF from being used for fraudulent payment reversals?
>
> Pay 1BTC to Alice for hard goods, then after you receive the goods
> broadcast a double spend of that transaction to pay Alice nothing? Your
> only cost is the higher network fee of the 2nd tx.
>
> Thanks,
> -Danny
>
> On Mon, May 25, 2015 at 5:10 PM, Peter Todd <pete at petertodd.org> wrote:
>
>> On Tue, May 26, 2015 at 12:03:09AM +0200, Mike Hearn wrote:
>> > CPFP also solves it just fine.
>>
>> CPFP is a significantly more expensive way of paying fees than RBF,
>> particularly for the use-case of defragmenting outputs, with cost
>> savings ranging from 30% to 90%
>>
>>
>> Case 1: CPFP vs. RBF for increasing the fee on a single tx
>> ----------------------------------------------------------
>>
>> Creating an spending a P2PKH output uses 34 bytes of txout, and 148
>> bytes of txin, 182 bytes total.
>>
>> Let's suppose I have a 1 BTC P2PKH output and I want to pay 0.1 BTC to
>> Alice. This results in a 1in/2out transaction t1 that's 226 bytes in size.
>> I forget to click on the "priority fee" option, so it goes out with the
>> minimum fee of 2.26uBTC. Whoops! I use CPFP to spend that output,
>> creating a new transaction t2 that's 192 bytes in size. I want to pay
>> 1mBTC/KB for a fast confirmation, so I'm now paying 418uBTC of
>> transaction fees.
>>
>> On the other hand, had I use RBF, my wallet would have simply
>> rebroadcast t1 with the change address decreased. The rules require you
>> to pay 2.26uBTC for the bandwidth consumed broadcasting it, plus the new
>> fee level, or 218uBTC of fees in total.
>>
>> Cost savings: 48%
>>
>>
>> Case 2: Paying multiple recipients in succession
>> ------------------------------------------------
>>
>> Suppose that after I pay Alice, I also decide to pay Bob for his hard
>> work demonstrating cryptographic protocols. I need to create a new
>> transaction t2 spending t1's change address. Normally t2 would be
>> another 226 bytes in size, resulting in 226uBTC additional fees.
>>
>> With RBF on the other hand I can simply double-spend t1 with a
>> transaction paying both Alice and Bob. This new transaction is 260 bytes
>> in size. I have to pay 2.6uBTC additional fees to pay for the bandwidth
>> consumed broadcasting it, resulting in an additional 36uBTC of fees.
>>
>> Cost savings: 84%
>>
>>
>> Case 3: Paying multiple recipients from a 2-of-3 multisig wallet
>> ----------------------------------------------------------------
>>
>> The above situation gets even worse with multisig. t1 in the multisig
>> case is 367 bytes; t2 another 367 bytes, costing an additional 367uBTC
>> in fees. With RBF we rewrite t1 with an additional output, resulting in
>> a 399 byte transaction, with just 36uBTC in additional fees.
>>
>> Cost savings: 90%
>>
>>
>> Case 4: Dust defragmentation
>> ----------------------------
>>
>> My wallet has a two transaction outputs that it wants to combine into
>> one for the purpose of UTXO defragmentation. It broadcasts transaction
>> t1 with two inputs and one output, size 340 bytes, paying zero fees.
>>
>> Prior to the transaction confirming I find I need to spend those funds
>> for a priority transaction at the 1mBTC/KB fee level. This transaction,
>> t2a, has one input and two outputs, 226 bytes in size. However it needs
>> to pay fees for both transactions at once, resulting in a combined total
>> fee of 556uBTC. If this situation happens frequently, defragmenting
>> UTXOs is likely to cost more in additional fees than it saves.
>>
>> With RBF I'd simply doublespend t1 with a 2-in-2-out transaction 374
>> bytes in size, paying 374uBTC. Even better, if one of the two inputs is
>> sufficiently large to cover my costs I can doublespend t1 with a
>> 1-in-2-out tx just 226 bytes in size, paying 226uBTC.
>>
>> Cost savings: 32% to 59%, or even infinite if defragmentation w/o RBF
>> costs you more than you save
>>
>> --
>> 'peter'[:-1]@petertodd.org
>> 0000000000000000134ce6577d4122094479f548b997baf84367eaf0c190bc9f
>>
>>
>> ------------------------------------------------------------------------------
>> 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
>>
>>
>
>
> ------------------------------------------------------------------------------
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150526/cf2d8823/attachment.html>

2023-06-07 17:34:11 CEST

- reply

📅 Original date posted:2015-05-29
📝 Original message:> miners would definitely be squeezing out transactions / putting pressure
to increase transaction fees
I'd just like to re-iterate that transactions getting "squeezed out"
(failure after a lengthy period of uncertainty) is a radical change from
the current behavior of the network. There are plenty of avenues to create
fee pressure without resorting to such a drastic change in how the network
works today.
Aaron Voisine
co-founder and CEO
breadwallet.com
On Thu, May 28, 2015 at 8:53 AM, Gavin Andresen <gavinandresen at gmail.com>
wrote:
> On Fri, May 8, 2015 at 3:20 AM, Matt Whitlock <bip at mattwhitlock.name>
> wrote:
>
>> Between all the flames on this list, several ideas were raised that did
>> not get much attention. I hereby resubmit these ideas for consideration and
>> discussion.
>>
>> - Perhaps the hard block size limit should be a function of the actual
>> block sizes over some trailing sampling period. For example, take the
>> median block size among the most recent 2016 blocks and multiply it by 1.5.
>> This allows Bitcoin to scale up gradually and organically, rather than
>> having human beings guessing at what is an appropriate limit.
>>
>
> A lot of people like this idea, or something like it. It is nice and
> simple, which is really important for consensus-critical code.
>
> With this rule in place, I believe there would be more "fee pressure"
> (miners would be creating smaller blocks) today. I created a couple of
> histograms of block sizes to infer what policy miners are ACTUALLY
> following today with respect to block size:
>
> Last 1,000 blocks:
> http://bitcoincore.org/~gavin/sizes_last1000.html
>
> Notice a big spike at 750K -- the default size for Bitcoin Core.
> This graph might be misleading, because transaction volume or fees might
> not be high enough over the last few days to fill blocks to whatever limit
> miners are willing to mine.
>
> So I graphed a time when (according to statoshi.info) there WERE a lot of
> transactions waiting to be confirmed:
> http://bitcoincore.org/~gavin/sizes_357511.html
>
> That might also be misleading, because it is possible there were a lot of
> transactions waiting to be confirmed because miners who choose to create
> small blocks got lucky and found more blocks than normal. In fact, it
> looks like that is what happened: more smaller-than-normal blocks were
> found, and the memory pool backed up.
>
> So: what if we had a dynamic maximum size limit based on recent history?
>
> The average block size is about 400K, so a 1.5x rule would make the max
> block size 600K; miners would definitely be squeezing out transactions /
> putting pressure to increase transaction fees. Even a 2x rule (implying
> 800K max blocks) would, today, be squeezing out transactions / putting
> pressure to increase fees.
>
> Using a median size instead of an average means the size can increase or
> decrease more quickly. For example, imagine the rule is "median of last
> 2016 blocks" and 49% of miners are producing 0-size blocks and 51% are
> producing max-size blocks. The median is max-size, so the 51% have total
> control over making blocks bigger. Swap the roles, and the median is
> min-size.
>
> Because of that, I think using an average is better-- it means the max
> size will change (up or down) more slowly.
>
> I also think 2016 blocks is too long, because transaction volumes change
> quicker than that. An average over 144 blocks (last 24 hours) would be
> better able to handle increased transaction volume around major holidays,
> and would also be able to react more quickly if an economically irrational
> attacker attempted to flood the network with fee-paying transactions.
>
> So my straw-man proposal would be: max size 2x average size over last 144
> blocks, calculated at every block.
>
> There are a couple of other changes I'd pair with that consensus change:
>
> + Make the default mining policy for Bitcoin Core neutral-- have its
> target block size be the average size, so miners that don't care will "go
> along with the people who do care."
>
> + Use something like Greg's formula for size instead of bytes-on-the-wire,
> to discourage bloating the UTXO set.
>
>
> ---------
>
> When I've proposed (privately, to the other core committers) some dynamic
> algorithm the objection has been "but that gives miners complete control
> over the max block size."
>
> I think that worry is unjustified right now-- certainly, until we have
> size-independent new block propagation there is an incentive for miners to
> keep their blocks small, and we see miners creating small blocks even when
> there are fee-paying transactions waiting to be confirmed.
>
> I don't even think it will be a problem if/when we do have
> size-independent new block propagation, because I think the combination of
> the random timing of block-finding plus a dynamic limit as described above
> will create a healthy system.
>
> If I'm wrong, then it seems to me the miners will have a very strong
> incentive to, collectively, impose whatever rules are necessary (maybe a
> soft-fork to put a hard cap on block size) to make the system healthy again.
>
>
> --
> --
> Gavin Andresen
>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150529/8755354e/attachment.html>

2023-06-07 17:34:08 CEST

- reply

📅 Original date posted:2015-05-30
📝 Original message:> or achieving less than great DOS protection
Right now a bunch of redditors can DOS the network at the cost of a few
thousand dollars per day, shared between them. Since the cost of validating
transactions is far lower than current minimum relay fees, then increasing
the block size increases the cost of DOSing the network.
Aaron Voisine
co-founder and CEO
breadwallet.com
On Fri, May 29, 2015 at 10:53 AM, Admin Istrator <andy at ftlio.com> wrote:
> What about trying the dynamic scaling method within the 20MB range + 1
> year with a 40% increase of that cap? Until a way to dynamically scale is
> found, the cap will only continue to be an issue. With 20 MB + 40% yoy,
> we're either imposing an arbitrary cap later, or achieving less than great
> DOS protection always. Why not set that policy as a maximum for 2 years as
> a protection against the possibility of dynamic scaling abuse, and see what
> happens with a dynamic method in the mean time. The policy of Max(1MB,
> (average size over previous 144 blocks) * 2) calculated at each block seems
> pretty reasonable.
>
> As an outsider, the real 'median' here seems to be 'keeping the cap as
> small as possible while allowing for larger blocks still'. We know
> miners will want to keep space in their blocks relatively scarce, but we
> also know that doesn't exclude the more powerful miners from
> including superfluous transactions to increase their effective share of the
> network. I have the luck of not being drained by this topic over the past
> three years, so it looks to me as if its two poles of 'block size must
> increase' and 'block size must not increase' are forcing what is the clear
> route to establishing the 'right' block size off the table.
>
> --Andrew Len
> (sorry if anybody received this twice, sent as the wrong email the first
> time around).
>
> On Fri, May 29, 2015 at 5:39 AM, Gavin Andresen <gavinandresen at gmail.com>
> wrote:
>
>> What do other people think?
>>
>>
>> If we can't come to an agreement soon, then I'll ask for help
>> reviewing/submitting patches to Mike's Bitcoin-Xt project that implement a
>> big increase now that grows over time so we may never have to go through
>> all this rancor and debate again.
>>
>> I'll then ask for help lobbying the merchant services and exchanges and
>> hosted wallet companies and other bitcoind-using-infrastructure companies
>> (and anybody who agrees with me that we need bigger blocks sooner rather
>> than later) to run Bitcoin-Xt instead of Bitcoin Core, and state that they
>> are running it. We'll be able to see uptake on the network by monitoring
>> client versions.
>>
>> Perhaps by the time that happens there will be consensus bigger blocks
>> are needed sooner rather than later; if so, great! The early deployment
>> will just serve as early testing, and all of the software already deployed
>> will ready for bigger blocks.
>>
>> But if there is still no consensus among developers but the "bigger
>> blocks now" movement is successful, I'll ask for help getting big miners to
>> do the same, and use the soft-fork block version voting mechanism to
>> (hopefully) get a majority and then a super-majority willing to produce
>> bigger blocks. The purpose of that process is to prove to any doubters that
>> they'd better start supporting bigger blocks or they'll be left behind, and
>> to give them a chance to upgrade before that happens.
>>
>>
>> Because if we can't come to consensus here, the ultimate authority for
>> determining consensus is what code the majority of merchants and exchanges
>> and miners are running.
>>
>>
>> --
>> --
>> Gavin Andresen
>>
>>
>> ------------------------------------------------------------------------------
>>
>> _______________________________________________
>> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150530/bf19ef13/attachment.html>

2023-06-07 17:33:59 CEST

- reply

📅 Original date posted:2015-05-08
📝 Original message:That's fair, and we've implemented child-pays-for-parent for spending
unconfirmed inputs in breadwallet. But what should the behavior be when
those options aren't understood/implemented/used?
My argument is that the less risky, more conservative default fallback
behavior should be either non-propagation or delayed confirmation, which is
generally what we have now, until we hit the block size limit. We still
have lots of safe, non-controversial, easy to experiment with options to
add fee pressure, causing users to economize on block space without
resorting to dropping transactions after a prolonged delay.
Aaron Voisine
co-founder and CEO
breadwallet.com
On Fri, May 8, 2015 at 3:45 PM, Mark Friedenbach <mark at friedenbach.org>
wrote:
> On Fri, May 8, 2015 at 3:43 PM, Aaron Voisine <voisine at gmail.com> wrote:
>
>> This is a clever way to tie block size to fees.
>>
>> I would just like to point out though that it still fundamentally is
>> using hard block size limits to enforce scarcity. Transactions with below
>> market fees will hang in limbo for days and fail, instead of failing
>> immediately by not propagating, or seeing degraded, long confirmation times
>> followed by eventual success.
>>
>
> There are already solutions to this which are waiting to be deployed as
> default policy to bitcoind, and need to be implemented in other clients:
> replace-by-fee and child-pays-for-parent.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150508/561f60f5/attachment.html>

2023-06-07 17:33:58 CEST

- reply

📅 Original date posted:2015-05-08
📝 Original message:This is a clever way to tie block size to fees.
I would just like to point out though that it still fundamentally is using
hard block size limits to enforce scarcity. Transactions with below market
fees will hang in limbo for days and fail, instead of failing immediately
by not propagating, or seeing degraded, long confirmation times followed by
eventual success.
Aaron Voisine
co-founder and CEO
breadwallet.com
On Fri, May 8, 2015 at 1:33 PM, Mark Friedenbach <mark at friedenbach.org>
wrote:
> It is my professional opinion that raising the block size by merely
> adjusting a constant without any sort of feedback mechanism would be a
> dangerous and foolhardy thing to do. We are custodians of a multi-billion
> dollar asset, and it falls upon us to weigh the consequences of our own
> actions against the combined value of the entire bitcoin ecosystem. Ideally
> we would take no action for which we are not absolutely certain of the
> ramifications, with the information that can be made available to us. But
> of course that is not always possible: there are unknown-unknowns, time
> pressures, and known-unknowns where information has too high a marginal
> cost. So where certainty is unobtainable, we must instead hedge against
> unwanted outcomes.
>
> The proposal to raise the block size now by redefining a constant carries
> with it risk associated with infrastructure scaling, centralization
> pressures, and delaying the necessary development of a constraint-based fee
> economy. It also simply kicks the can down the road in settling these
> issues because a larger but realistic hard limit must still exist, meaning
> a future hard fork may still be required.
>
> But whatever new hard limit is chosen, there is also a real possibility
> that it may be too high. The standard response is that it is a soft-fork
> change to impose a lower block size limit, which miners could do with a
> minimal amount of coordination. This is however undermined by the
> unfortunate reality that so many mining operations are absentee-run
> businesses, or run by individuals without a strong background in bitcoin
> protocol policy, or with interests which are not well aligned with other
> users or holders of bitcoin. We cannot rely on miners being vigilant about
> issues that develop, as they develop, or able to respond in the appropriate
> fashion that someone with full domain knowledge and an objective
> perspective would.
>
> The alternative then is to have some sort of dynamic block size limit
> controller, and ideally one which applies a cost to raising the block size
> in some way the preserves the decentralization and/or long-term stability
> features that we care about. I will now describe one such proposal:
>
> * For each block, the miner is allowed to select a different difficulty
> (nBits) within a certain range, e.g. +/- 25% of the expected difficulty,
> and this miner-selected difficulty is used for the proof of work check. In
> addition to adjusting the hashcash target, selecting a different difficulty
> also raises or lowers the maximum block size for that block by a function
> of the difference in difficulty. So increasing the difficulty of the block
> by an additional 25% raises the block limit for that block from 100% of the
> current limit to 125%, and lowering the difficulty by 10% would also lower
> the maximum block size for that block from 100% to 90% of the current
> limit. For simplicity I will assume a linear identity transform as the
> function, but a quadratic or other function with compounding marginal cost
> may be preferred.
>
> * The default maximum block size limit is then adjusted at regular
> intervals. For simplicity I will assume an adjustment at the end of each
> 2016 block interval, at the same time that difficulty is adjusted, but
> there is no reason these have to be aligned. The adjustment algorithm
> itself is either the selection of the median, or perhaps some sort of
> weighted average that respects the "middle majority." There would of course
> be limits on how quickly the block size limit can adjusted in any one
> period, just as there are min/max limits on the difficulty adjustment.
>
> * To prevent perverse mining incentives, the original difficulty without
> adjustment is used in the aggregate work calculations for selecting the
> most-work chain, and the allowable miner-selected adjustment to difficulty
> would have to be tightly constrained.
>
> These rules create an incentive environment where raising the block size
> has a real cost associated with it: a more difficult hashcash target for
> the same subsidy reward. For rational miners that cost must be
> counter-balanced by additional fees provided in the larger block. This
> allows block size to increase, but only within the confines of a
> self-supporting fee economy.
>
> When the subsidy goes away or is reduced to an insignificant fraction of
> the block reward, this incentive structure goes away. Hopefully at that
> time we would have sufficient information to soft-fork set a hard block
> size maximum. But in the mean time, the block size limit controller
> constrains the maximum allowed block size to be within a range supported by
> fees on the network, providing an emergency relief valve that we can be
> assured will only be used at significant cost.
>
> Mark Friedenbach
>
> * There has over time been various discussions on the bitcointalk forums
> about dynamically adjusting block size limits. The true origin of the idea
> is unclear at this time (citations would be appreciated!) but a form of it
> was implemented in Bytecoin / Monero using subsidy burning to increase the
> block size. That approach has various limitations. These were corrected in
> Greg Maxwell's suggestion to adjust the difficulty/nBits field directly,
> which also has the added benefit of providing incentive for bidirectional
> movement during the subsidy period. The description in this email and any
> errors are my own.
>
> On Fri, May 8, 2015 at 12:20 AM, Matt Whitlock <bip at mattwhitlock.name>
> wrote:
>
>> Between all the flames on this list, several ideas were raised that did
>> not get much attention. I hereby resubmit these ideas for consideration and
>> discussion.
>>
>> - Perhaps the hard block size limit should be a function of the actual
>> block sizes over some trailing sampling period. For example, take the
>> median block size among the most recent 2016 blocks and multiply it by 1.5.
>> This allows Bitcoin to scale up gradually and organically, rather than
>> having human beings guessing at what is an appropriate limit.
>>
>> - Perhaps the hard block size limit should be determined by a vote of the
>> miners. Each miner could embed a desired block size limit in the coinbase
>> transactions of the blocks it publishes. The effective hard block size
>> limit would be that size having the greatest number of votes within a
>> sliding window of most recent blocks.
>>
>> - Perhaps the hard block size limit should be a function of block-chain
>> length, so that it can scale up smoothly rather than jumping immediately to
>> 20 MB. This function could be linear (anticipating a breakdown of Moore's
>> Law) or quadratic.
>>
>> I would be in support of any of the above, but I do not support Mike
>> Hearn's proposed jump to 20 MB. Hearn's proposal kicks the can down the
>> road without actually solving the problem, and it does so in a
>> controversial (step function) way.
>>
>>
>> ------------------------------------------------------------------------------
>> 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
>>
>
>
>
> ------------------------------------------------------------------------------
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150508/95998365/attachment.html>

2023-06-07 17:33:05 CEST

- reply

📅 Original date posted:2015-05-08
📝 Original message:As the author of a popular SPV wallet, I wanted to weigh in, in support of
the Gavin's 20Mb block proposal.
The best argument I've heard against raising the limit is that we need fee
pressure. I agree that fee pressure is the right way to economize on
scarce resources. Placing hard limits on block size however is an
incredibly disruptive way to go about this, and will severely negatively
impact users' experience.
When users pay too low a fee, they should:
1) See immediate failure as they do now with fees that fail to propagate.
2) If the fee lower than it should be but not terminal, they should see
degraded performance, long delays in confirmation, but eventual success.
This will encourage them to pay higher fees in future.
The worst of all worlds would be to have transactions propagate, hang in
limbo for days, and then fail. This is the most important scenario to
avoid. Increasing the 1Mb block size limit I think is the simplest way to
avoid this least desirable scenario for the immediate future.
We can play around with improved transaction selection for blocks and
encourage miners to adopt it to discourage low fees and create fee
pressure. These could involve hybrid priority/fee selection so low fee
transactions see degraded performance instead of failure. This would be the
conservative low risk approach.
Aaron Voisine
co-founder and CEO
breadwallet.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150508/61a099ec/attachment.html>

2023-06-07 17:31:27 CEST

- reply

📅 Original date posted:2015-03-11
📝 Original message:I'm not convinced that wallet seed interoperability is such a great thing.
There is a wide variability in the quality and security level of wallet
implementations and platforms. Each new device and wallet software a user
types their seed into increases their attack surface and exposure to flaws.
Their security level is reduced to the lowest common denominator. I see the
need for a "fire exit", certainly, but we must also remember that fire
exits are potential entrances for intruders.
Aaron Voisine
co-founder and CEO
breadwallet.com
On Wed, Mar 11, 2015 at 12:46 PM, Gregory Maxwell <gmaxwell at gmail.com>
wrote:
> On Wed, Mar 11, 2015 at 7:24 PM, Ricardo Filipe
> <ricardojdfilipe at gmail.com> wrote:
> > i guess you look at the glass half full :)
> > even though what you say is true, we should aim for wallets not to
> > require those instructions, by standardizing these things in BIPs.
> > let's hope bitcoin doesn't fail in standards as our industries have in
> > the past...
>
> There are genuine principled disagreements on how some things should
> be done. There are genuine differences in functionality.
>
> We cannot expect and should not expect complete compatibility. If you
> must have complete compatibility: use the same software (or maybe not
> even then, considering how poor the forward compatibility of some
> things has been..).
>
> What we can hope to do, and I think the best we can hope to do, is to
> minimize the amount of gratuitous incompatibility and reduce the
> amount of outright flawed constructions (so if there are choices which
> must be made, they're at least choices among relatively good options).
>
>
> ------------------------------------------------------------------------------
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150311/9247ee7b/attachment.html>

2023-06-07 17:25:42 CEST

- reply

📅 Original date posted:2014-09-12
📝 Original message:Are there any circumstances where the payment request object might be
served over a different domain than the CNAME of the object's signer?
BIP72 states "Bitcoin wallets must support fetching PaymentRequests
via http and https protocols;". If the request object is signed by the
owner of the domain, then the worst an attacker who doesn't have the
signing key can do is replace the request with another validly signed
request intended for someone else, but that could be the attacker's
own product order, tricking someone else into paying for it.
Should BIP72 require that signed payment requests be from the same
domain, and also require https?
Aaron
Aaron Voisine
breadwallet.com
On Fri, Sep 12, 2014 at 9:31 AM, Mike Hearn <mike at plan99.net> wrote:
> Putting aside the question of necessity for a moment, a more efficient
> approach to this would be;
>
> Add another marker param like &s to the end of the URL
> Add another field to PaymentRequest that contains an ECC signature
> calculated using the public key that hashes to the address in the URI
> Upgraded wallets look for the additional param and if it's there, expect to
> find the PaymentDetails signed with the address key. PKI signing of course
> is still useful to provide an actual identity for receipts, display on
> hardware wallets, dispute mediation etc.
>
> This adds only a few characters to a normal backwards-compatible QR code,
> and is not hard to implement.
>
>
> On Fri, Sep 12, 2014 at 5:37 PM, Mike Hearn <mike at plan99.net> wrote:
>>>
>>> That way we leave up to implementers to experiment with different
>>> lengths and figure out what the optimum is
>>
>>
>> Ah, that's a good suggestion if we do go this way.
>
>
>
> ------------------------------------------------------------------------------
> Want excitement?
> Manually upgrade your production database.
> When you want reliability, choose Perforce
> Perforce version control. Predictably reliable.
> http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

2023-06-07 17:24:24 CEST

- reply

📅 Original date posted:2014-07-25
📝 Original message:Yes, if the wallet isn't up to date yet, it uses the highest estimated
block height from connected peers, but that could be gamed by
controlling the network. The app has blockchain checkpoints in it
though, so you couldn't truncate the chain starting point below that.
The worst case is that you get a 4-5 extra guesses, but as I
mentioned, it'd be easier to just jailbreak the phone if the phone
itself isn't using a system wide pin lock. I just though it was a fun
and convenient way to prevent the system time hack. The system pin is
what protects your wallet in the event of physical theft, and the app
pin is just for when you lend your phone to a friend for a few
minutes.
Aaron Voisine
breadwallet.com
On Fri, Jul 25, 2014 at 9:22 AM, Natanael <natanael.l at gmail.com> wrote:
> Probably because the network isn't designed for interactive proofs. Most
> interactive algoritms AFAICT requires that some machine holds a secret state
> (or at least continuous and untampered state, but you still need to verify
> you're falling to the right machine), otherwise the machine can be mimicked
> and "rewound" to earlier states. Without a challenge-response that can't be
> faked, you've got problems.
>
> There's no trusted machines here that you can rely on. The certainty of
> having the right blockchain is a statistical one over longer periods of
> time, not enough for a PIN you want verified right now. So you can always be
> shown an old copy, and if your node isn't up to date yet then it can also be
> shown fake chains further into the future.
>
> Maybe you could throw in some kind of Secure Multiparty Computation among
> the miners to enable challenge-response, with state saved in the blockchain
> (so it can't be rolled back), but that would be fragile. How do you select
> what nodes may participate? How do you prevent the secret state from
> leaking? And performance would be absolutely horrible, and reliability is a
> huge problem.
>
> Den 25 jul 2014 18:03 skrev "Mike Hearn" <mike at plan99.net>:
>
>> Sorry, you're right. I'd have hoped a delay that doubles on failure each
>> time up to some max would be good enough, relying on the p2p network to
>> unlock a PIN feels weird, but I can't really quantify why or what's wrong
>> with it so I guess it's just me :-)
>>
>>
>> On Fri, Jul 25, 2014 at 4:45 PM, Aaron Voisine <voisine at gmail.com> wrote:
>>>
>>> The problem is if someone moves system time forward between app launches.
>>> The lockout period doesn't have to be all that precise, it just makes you
>>> wait for the next block, then 5, then 25, and so on. Using a well known time
>>> server over https would also be a good option, but the wallet app already
>>> has the chain height anyway.
>>>
>>>
>>> On Friday, July 25, 2014, Mike Hearn <mike at plan99.net> wrote:
>>>>
>>>> Given that the speed at which the block chain advances is kind of
>>>> unpredictable, I'd think it might be better to just record the time to disk
>>>> when a PIN attempt is made and if you observe time going backwards, refuse
>>>> to allow more attempts until it's advanced past the previous attempt.
>>>>
>>>>
>>>> On Fri, Jul 25, 2014 at 7:56 AM, Aaron Voisine <voisine at gmail.com>
>>>> wrote:
>>>>>
>>>>> It's based on the block height, not the block's timestamp. If you have
>>>>> access to the device and the phone itself is not pin locked, then you
>>>>> can jailbreak it and get access to the wallet seed that way. A pin
>>>>> locked device however is reasonably secure as the filesystem is
>>>>> hardware aes encrypted to a combination of pin+uuid. This was just an
>>>>> easy way to prevent multiple pin guesses by changing system time in
>>>>> settings, so that isn't the weakest part of the security model.
>>>>>
>>>>> Aaron Voisine
>>>>> breadwallet.com
>>>>>
>>>>>
>>>>> On Thu, Jul 24, 2014 at 8:21 PM, William Yager <will.yager at gmail.com>
>>>>> wrote:
>>>>> > On Thu, Jul 24, 2014 at 10:39 PM, Gregory Maxwell
>>>>> > <gmaxwell at gmail.com>
>>>>> > wrote:
>>>>> >>
>>>>> >>
>>>>> >> Is breadwallet tamper resistant & zero on tamper hardware? otherwise
>>>>> >> this sounds like security theater.... I attach a debugger to the
>>>>> >> process (or modify the program) and ignore the block sourced time.
>>>>> >>
>>>>> >
>>>>> > It's an iOS application. I would imagine it is substantially more
>>>>> > difficult
>>>>> > to attach to a process (which, at the very least, requires root, and
>>>>> > perhaps
>>>>> > other things on iOS) than to convince the device to change its system
>>>>> > time.
>>>>> >
>>>>> > That said, the security benefits might not be too substantial.
>>>>> >
>>>>> >
>>>>> > ------------------------------------------------------------------------------
>>>>> > Want fast and easy access to all the code in your enterprise? Index
>>>>> > and
>>>>> > search up to 200,000 lines of code with a free copy of Black Duck
>>>>> > Code Sight - the same software that powers the world's largest code
>>>>> > search on Ohloh, the Black Duck Open Hub! Try it now.
>>>>> > http://p.sf.net/sfu/bds
>>>>> > _______________________________________________
>>>>> > Bitcoin-development mailing list
>>>>> > Bitcoin-development at lists.sourceforge.net
>>>>> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>>>> >
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> Want fast and easy access to all the code in your enterprise? Index and
>>>>> search up to 200,000 lines of code with a free copy of Black Duck
>>>>> Code Sight - the same software that powers the world's largest code
>>>>> search on Ohloh, the Black Duck Open Hub! Try it now.
>>>>> http://p.sf.net/sfu/bds
>>>>> _______________________________________________
>>>>> Bitcoin-development mailing list
>>>>> Bitcoin-development at lists.sourceforge.net
>>>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>>>
>>>>
>>>
>>>
>>> --
>>>
>>> Aaron Voisine
>>> breadwallet.com
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Want fast and easy access to all the code in your enterprise? Index and
>> search up to 200,000 lines of code with a free copy of Black Duck
>> Code Sight - the same software that powers the world's largest code
>> search on Ohloh, the Black Duck Open Hub! Try it now.
>> http://p.sf.net/sfu/bds
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>

2023-06-07 17:24:23 CEST

- reply

📅 Original date posted:2014-07-25
📝 Original message:The problem is if someone moves system time forward between app launches.
The lockout period doesn't have to be all that precise, it just makes you
wait for the next block, then 5, then 25, and so on. Using a well
known time server over https would also be a good option, but the wallet
app already has the chain height anyway.
On Friday, July 25, 2014, Mike Hearn <mike at plan99.net> wrote:
> Given that the speed at which the block chain advances is kind of
> unpredictable, I'd think it might be better to just record the time to disk
> when a PIN attempt is made and if you observe time going backwards, refuse
> to allow more attempts until it's advanced past the previous attempt.
>
>
> On Fri, Jul 25, 2014 at 7:56 AM, Aaron Voisine <voisine at gmail.com
> <javascript:_e(%7B%7D,'cvml','voisine at gmail.com');>> wrote:
>
>> It's based on the block height, not the block's timestamp. If you have
>> access to the device and the phone itself is not pin locked, then you
>> can jailbreak it and get access to the wallet seed that way. A pin
>> locked device however is reasonably secure as the filesystem is
>> hardware aes encrypted to a combination of pin+uuid. This was just an
>> easy way to prevent multiple pin guesses by changing system time in
>> settings, so that isn't the weakest part of the security model.
>>
>> Aaron Voisine
>> breadwallet.com
>>
>>
>> On Thu, Jul 24, 2014 at 8:21 PM, William Yager <will.yager at gmail.com
>> <javascript:_e(%7B%7D,'cvml','will.yager at gmail.com');>> wrote:
>> > On Thu, Jul 24, 2014 at 10:39 PM, Gregory Maxwell <gmaxwell at gmail.com
>> <javascript:_e(%7B%7D,'cvml','gmaxwell at gmail.com');>>
>> > wrote:
>> >>
>> >>
>> >> Is breadwallet tamper resistant & zero on tamper hardware? otherwise
>> >> this sounds like security theater.... I attach a debugger to the
>> >> process (or modify the program) and ignore the block sourced time.
>> >>
>> >
>> > It's an iOS application. I would imagine it is substantially more
>> difficult
>> > to attach to a process (which, at the very least, requires root, and
>> perhaps
>> > other things on iOS) than to convince the device to change its system
>> time.
>> >
>> > That said, the security benefits might not be too substantial.
>> >
>> >
>> ------------------------------------------------------------------------------
>> > Want fast and easy access to all the code in your enterprise? Index and
>> > search up to 200,000 lines of code with a free copy of Black Duck
>> > Code Sight - the same software that powers the world's largest code
>> > search on Ohloh, the Black Duck Open Hub! Try it now.
>> > http://p.sf.net/sfu/bds
>> > _______________________________________________
>> > Bitcoin-development mailing list
>> > Bitcoin-development at lists.sourceforge.net
>> <javascript:_e(%7B%7D,'cvml','Bitcoin-development at lists.sourceforge.net');>
>> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>> >
>>
>>
>> ------------------------------------------------------------------------------
>> Want fast and easy access to all the code in your enterprise? Index and
>> search up to 200,000 lines of code with a free copy of Black Duck
>> Code Sight - the same software that powers the world's largest code
>> search on Ohloh, the Black Duck Open Hub! Try it now.
>> http://p.sf.net/sfu/bds
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> <javascript:_e(%7B%7D,'cvml','Bitcoin-development at lists.sourceforge.net');>
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>
>
--
Aaron Voisine
breadwallet.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140725/bab41a50/attachment.html>

2023-06-07 17:24:15 CEST

- reply

📅 Original date posted:2014-07-19
📝 Original message:Well, you could always create a transaction with a different signature
hash, say, by changing something trivial like nLockTime, or changing
the order of inputs or outputs. Is that what you're talking about? Or
is there some sophistry I'm ignorant of having to do with the elliptic
curve math in the signature itself?
Aaron Voisine
breadwallet.com
On Fri, Jul 18, 2014 at 6:28 PM, Gregory Maxwell <gmaxwell at gmail.com> wrote:
> On Fri, Jul 18, 2014 at 3:03 PM, Aaron Voisine <voisine at gmail.com> wrote:
>>> 9. New signatures by the sender
>>
>> I'm not suggesting it be required, but it would be possible to
>> mitigate this one by requiring that all signatures deterministically
>> generate k per RFC6979. I'm using this in breadwallet.
>
> Nope.
>
> Your homework assignment is to explain why. :)

2023-06-07 17:24:15 CEST

- reply

📅 Original date posted:2014-07-19
📝 Original message:Ah, good point. For some reason I was thinking the k value was
generated only from the hash being signed, but it's derived from both
the private key and the hash, so as you say there's no way for the
verifier to tell if the scheme is being followed.
Aaron Voisine
breadwallet.com
On Fri, Jul 18, 2014 at 11:56 PM, Gregory Maxwell <gmaxwell at gmail.com> wrote:
> On Fri, Jul 18, 2014 at 9:38 PM, Aaron Voisine <voisine at gmail.com> wrote:
>> Well, you could always create a transaction with a different signature
>> hash, say, by changing something trivial like nLockTime, or changing
>> the order of inputs or outputs. Is that what you're talking about? Or
>> is there some sophistry I'm ignorant of having to do with the elliptic
>> curve math in the signature itself?
>
> No, though thats true too. I was talking about the properties of the DSA nonce:
>
> An attacker is not obligated to follow your protocol unless you can
> prevent him. You can _say_ use derandomized DSA all you like, but he
> can just not do so, there is no (reasonable) way to prove you're using
> a particular nonce generation scheme without revealing the private key
> in the process. The verifier cannot know the nonce or he can trivially
> recover your private key thus he can't just repeat the computation
> (well, plus if you're using RFC6979 the computation includes the
> private key), so short of a very fancy ZKP (stuff at the forefront of
> cryptographic/computer science) or precommiting to a nonce per public
> key (e.g. single use public keys), you cannot control how a DSA nonce
> was generated in the verifier in a way that would prevent equivalent
> but not identical signatures.
>
> (I believe there was some P.O.S. altcoin that was vulnerable because
> of precisely the above too— thinking specifying a deterministic signer
> would prevent someone from grinding signatures to improve their mining
> odds... there are signature systems which are naturally
> randomness-free: most hash based signatures and pairing short
> signatures are two examples that come to mind... but not DSA, schnorr,
> or any of their derivatives).

2023-06-07 17:24:14 CEST

- reply

📅 Original date posted:2014-07-18
📝 Original message:> 9. New signatures by the sender
I'm not suggesting it be required, but it would be possible to
mitigate this one by requiring that all signatures deterministically
generate k per RFC6979. I'm using this in breadwallet.
Aaron Voisine
breadwallet.com
On Fri, Jul 18, 2014 at 1:56 PM, Wladimir <laanwj at gmail.com> wrote:
> On Fri, Jul 18, 2014 at 5:39 PM, Mike Hearn <mike at plan99.net> wrote:
>> The rationale doesn't seem to apply to rule #4, what's so special about that
>> one?
>
>> 4. Non-push operations in scriptSig Any non-push operation in a scriptSig invalidates it.
>
> Having non-push operations in the scriptSig is a source of
> malleability, as there can be multiple sequences of opcodes that
> evaluate to the same result.
>
> Wladimir
>
> ------------------------------------------------------------------------------
> Want fast and easy access to all the code in your enterprise? Index and
> search up to 200,000 lines of code with a free copy of Black Duck
> Code Sight - the same software that powers the world's largest code
> search on Ohloh, the Black Duck Open Hub! Try it now.
> http://p.sf.net/sfu/bds
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

2023-06-07 17:23:54 CEST

- reply

📅 Original date posted:2014-07-16
📝 Original message:If I first remove \u0000, so the non-normalized passphrase is
"\u03D2\u0301\U00010400\U0001F4A9", and then NFC normalize it, it
becomes "\u03D3\U00010400\U0001F4A9"
UTF-8 encoded this is: 0xcf93f0909080f09f92a9 (not the same as what
you got, Andreas!)
Encoding private key: 5Jajm8eQ22H3pGWLEVCXyvND8dQZhiQhoLJNKjYXk9roUFTMSZ4
with this passphrase, I get a BIP38 key of:
6PRW5o9FMb4hAYRQPmgcvVDTyDtr6R17VMXGLmvKjKVpGkYhBJ4uYuR9wZ
I recommend rather than simply removing control characters from the
password that instead the spec require that passwords containing
control characters are invalid. We don't want people trying to be
clever and putting them in thinking they are adding to the password
entropy.
Also for UI compatibility across many platforms, I'm also in favor
disallowing any character below U+0020 (space)
I can submit a PR once we figure out why Andreas's passphrase was
different than what I got.
Aaron Voisine
breadwallet.com
On Wed, Jul 16, 2014 at 4:04 AM, Andreas Schildbach
<andreas at schildbach.de> wrote:
> Damn, I just realized that I implement only the decoding side of BIP38.
> So I cannot propose a complete test vector. Here is what I have:
>
>
> Passphrase: ϓ␀𐐀💩 (\u03D2\u0301\u0000\U00010400\U0001F4A9; GREEK
> UPSILON WITH HOOK, COMBINING ACUTE ACCENT, NULL, DESERET CAPITAL LETTER
> LONG I, PILE OF POO)
>
> Passphrase bytes after removing ISO control characters and NFC
> normalization: 0xcf933034303066346139
>
> Bitcoin Address: 16ktGzmfrurhbhi6JGqsMWf7TyqK9HNAeF
>
> Unencrypted private key (WIF):
> 5Jajm8eQ22H3pGWLEVCXyvND8dQZhiQhoLJNKjYXk9roUFTMSZ4
>
>
> Can someone calculate the encrypted key from it (using whatever
> implementation) and I will verify it decodes properly in bitcoinj?
>
>
>
> On 07/16/2014 12:46 PM, Andreas Schildbach wrote:
>> I will change the bitcoinj implementation and propose a new test vector.
>>
>>
>>
>> On 07/16/2014 11:29 AM, Mike Hearn wrote:
>>> Yes sorry, you're right, the issue starts with the null code point.
>>> Python seems to have problems starting there too. It might work if we
>>> took that out.
>>>
>>>
>>> On Wed, Jul 16, 2014 at 11:17 AM, Andreas Schildbach
>>> <andreas at schildbach.de <mailto:andreas at schildbach.de>> wrote:
>>>
>>> Guys, you are always talking about the Unicode astral plane, but in fact
>>> its a plain old (ASCII) control character where this problem starts and
>>> likely ends: \u0000.
>>>
>>> Let's ban/filter ISO control characters and be done with it. Most
>>> control characters will never be enterable by any keyboard into a
>>> password field. Of course I assume that Character.isISOControl() works
>>> consistently across platforms.
>>>
>>> http://docs.oracle.com/javase/7/docs/api/java/lang/Character.html#isISOControl%28char%29
>>>
>>>
>>> On 07/16/2014 12:23 AM, Aaron Voisine wrote:
>>> > If the user creates a password on an iOS device with an astral
>>> > character and then can't enter that password on a JVM wallet, that
>>> > sucks. If JVMs really can't support unicode NFC then that's a strong
>>> > case to limit the spec to the subset of unicode that all popular
>>> > platforms can support, but it sounds like it might just be a JVM
>>> > string library bug that could hopefully be reported and fixed. I get
>>> > the same result as in the test case using apple's
>>> > CFStringNormalize(passphrase, kCFStringNormalizationFormC);
>>> >
>>> > Aaron Voisine
>>> > breadwallet.com <http://breadwallet.com>
>>> >
>>> >
>>> > On Tue, Jul 15, 2014 at 11:20 AM, Mike Hearn <mike at plan99.net
>>> <mailto:mike at plan99.net>> wrote:
>>> >> Yes, we know, Andreas' code is indeed doing normalisation.
>>> >>
>>> >> However it appears the output bytes end up being different. What
>>> I get back
>>> >> is:
>>> >>
>>> >> cf930001303430300166346139
>>> >>
>>> >> vs
>>> >>
>>> >> cf9300f0909080f09f92a9
>>> >>
>>> >> from the spec.
>>> >>
>>> >> I'm not sure why. It appears this is due to the character from
>>> the astral
>>> >> planes. Java is old and uses 16 bit characters internally - it
>>> wouldn't
>>> >> surprise me if there's some weirdness that means it doesn't/won't
>>> support
>>> >> this kind of thing.
>>> >>
>>> >> I recommend instead that any implementation that wishes to be
>>> compatible
>>> >> with JVM based wallets (I suspect Android is the same) just
>>> refuse any
>>> >> passphrase that includes characters outside the BMP. At least
>>> unless someone
>>> >> can find a fix. I somehow doubt this will really hurt anyone.
>>> >>
>>> >>
>>> ------------------------------------------------------------------------------
>>> >> Want fast and easy access to all the code in your enterprise?
>>> Index and
>>> >> search up to 200,000 lines of code with a free copy of Black Duck
>>> >> Code Sight - the same software that powers the world's largest code
>>> >> search on Ohloh, the Black Duck Open Hub! Try it now.
>>> >> http://p.sf.net/sfu/bds
>>> >> _______________________________________________
>>> >> Bitcoin-development mailing list
>>> >> Bitcoin-development at lists.sourceforge.net
>>> <mailto:Bitcoin-development at lists.sourceforge.net>
>>> >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>> >>
>>> >
>>> >
>>> ------------------------------------------------------------------------------
>>> > Want fast and easy access to all the code in your enterprise?
>>> Index and
>>> > search up to 200,000 lines of code with a free copy of Black Duck
>>> > Code Sight - the same software that powers the world's largest code
>>> > search on Ohloh, the Black Duck Open Hub! Try it now.
>>> > http://p.sf.net/sfu/bds
>>> >
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Want fast and easy access to all the code in your enterprise? Index and
>>> search up to 200,000 lines of code with a free copy of Black Duck
>>> Code Sight - the same software that powers the world's largest code
>>> search on Ohloh, the Black Duck Open Hub! Try it now.
>>> http://p.sf.net/sfu/bds
>>> _______________________________________________
>>> Bitcoin-development mailing list
>>> Bitcoin-development at lists.sourceforge.net
>>> <mailto:Bitcoin-development at lists.sourceforge.net>
>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Want fast and easy access to all the code in your enterprise? Index and
>>> search up to 200,000 lines of code with a free copy of Black Duck
>>> Code Sight - the same software that powers the world's largest code
>>> search on Ohloh, the Black Duck Open Hub! Try it now.
>>> http://p.sf.net/sfu/bds
>>>
>>>
>>>
>>> _______________________________________________
>>> Bitcoin-development mailing list
>>> Bitcoin-development at lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Want fast and easy access to all the code in your enterprise? Index and
>> search up to 200,000 lines of code with a free copy of Black Duck
>> Code Sight - the same software that powers the world's largest code
>> search on Ohloh, the Black Duck Open Hub! Try it now.
>> http://p.sf.net/sfu/bds
>>
>
>
>
> ------------------------------------------------------------------------------
> Want fast and easy access to all the code in your enterprise? Index and
> search up to 200,000 lines of code with a free copy of Black Duck
> Code Sight - the same software that powers the world's largest code
> search on Ohloh, the Black Duck Open Hub! Try it now.
> http://p.sf.net/sfu/bds
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

2023-06-07 17:23:51 CEST

- reply

📅 Original date posted:2014-07-15
📝 Original message:If the user creates a password on an iOS device with an astral
character and then can't enter that password on a JVM wallet, that
sucks. If JVMs really can't support unicode NFC then that's a strong
case to limit the spec to the subset of unicode that all popular
platforms can support, but it sounds like it might just be a JVM
string library bug that could hopefully be reported and fixed. I get
the same result as in the test case using apple's
CFStringNormalize(passphrase, kCFStringNormalizationFormC);
Aaron Voisine
breadwallet.com
On Tue, Jul 15, 2014 at 11:20 AM, Mike Hearn <mike at plan99.net> wrote:
> Yes, we know, Andreas' code is indeed doing normalisation.
>
> However it appears the output bytes end up being different. What I get back
> is:
>
> cf930001303430300166346139
>
> vs
>
> cf9300f0909080f09f92a9
>
> from the spec.
>
> I'm not sure why. It appears this is due to the character from the astral
> planes. Java is old and uses 16 bit characters internally - it wouldn't
> surprise me if there's some weirdness that means it doesn't/won't support
> this kind of thing.
>
> I recommend instead that any implementation that wishes to be compatible
> with JVM based wallets (I suspect Android is the same) just refuse any
> passphrase that includes characters outside the BMP. At least unless someone
> can find a fix. I somehow doubt this will really hurt anyone.
>
> ------------------------------------------------------------------------------
> Want fast and easy access to all the code in your enterprise? Index and
> search up to 200,000 lines of code with a free copy of Black Duck
> Code Sight - the same software that powers the world's largest code
> search on Ohloh, the Black Duck Open Hub! Try it now.
> http://p.sf.net/sfu/bds
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

2023-06-07 17:23:36 CEST

- reply

📅 Original date posted:2014-07-04
📝 Original message:Agreed. If the POW is most efficient on general purpose CPUs, that
means Intel, AMD and maybe IBM would be the only entities capable of
producing competitive mining equipment.
Aaron
Aaron Voisine
breadwallet.com
On Fri, Jul 4, 2014 at 11:39 AM, Ron Elliott <ronaldbelliott at gmail.com> wrote:
> I feel everyone should re-read that last paragraph as it carries the most
> weight IMO.
>
>
> On Fri, Jul 4, 2014 at 9:50 AM, kjj <bitcoin-devel at jerviss.org> wrote:
>>
>> Just some general comments on this topic/discussion.
>>
>> I suspect that there exist no algorithms which cannot be done better in
>> an application-specific device than in a general purpose computer. And
>> if there is such a thing, then it must necessarily perform best on one
>> specific platform, making that platform the de facto application
>> specific device.
>>
>> I'm not sure how one would go about proving or disproving that, but it
>> seems very likely to be true.
>>
>> IO-bound is exactly the same as memory bound, for devices that have
>> enough memory. 20 GB is already trivial today, and you don't really get
>> into ask-the-wife-for-permission money until you cross 128 GB. The
>> exception would be if the IO was to an oracle outside of the device's
>> control, and artificially limited in throughput. Such a centralized
>> oracle would be contrary to the goals usually stated by people thinking
>> about anti-ASIC designs, so there isn't much point.
>>
>> Keeping the algorithm simple, and ASIC-easy, has one other advantage.
>> Just about anyone can sit down and design an ASIC for SHA, for example,
>> leading to diversity in the marketplace. A harder algorithm can still
>> be made into an ASIC (or more generally into an ASD), but will require
>> more skilled designers, more expensive fabrication, etc. This actually
>> concentrates the ASIC advantage into the hands of fewer people, which
>> again, is contrary to the stated goals.
>>
>>
>> ------------------------------------------------------------------------------
>> Open source business process management suite built on Java and Eclipse
>> Turn processes into business applications with Bonita BPM Community
>> Edition
>> Quickly connect people, data, and systems into organized workflows
>> Winner of BOSSIE, CODIE, OW2 and Gartner awards
>> http://p.sf.net/sfu/Bonitasoft
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>
>
> --
> - Ron
> end of line.
>
> ------------------------------------------------------------------------------
> Open source business process management suite built on Java and Eclipse
> Turn processes into business applications with Bonita BPM Community Edition
> Quickly connect people, data, and systems into organized workflows
> Winner of BOSSIE, CODIE, OW2 and Gartner awards
> http://p.sf.net/sfu/Bonitasoft
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

2023-06-07 17:20:47 CEST

- reply

📅 Original date posted:2014-05-02
📝 Original message:It will also be important to chose the currency symbol for "bits" at the
same time. Lowercase stroke "b" I think is the obvious choice.
Unicode U+0180
Aaron
On Friday, May 2, 2014, Alan Reiner <etotheipi at gmail.com> wrote:
> I've been a strong supporter of the 1e-6 unit switch since the beginning
> and ready to do whatever I can with Armory to help ease that transition.
> I'm happy to prioritize a release that updates the Armory interface to make
> "bits" the default unit, when the time is right. I think it makes sense to
> get as many apps and services to upgrade nearly simultaneously.
>
> My plan is to have a popup on the first load of the new version that
> briefly introduces the change, and mentions that they can go back to the
> old way in the settings, but make them work to do it. For the transient
> period (6 months?) all input boxes will auto-update nearby labels with the
> converted-to-BTC value as they type, so that they don't have to do any math
> in their head. Similarly, all displayed BTC values will show both. But
> the 1e-6 unit will always be default or first unless they explicitly change
> it in the interface.
>
>
>
>
> On 5/2/2014 8:54 PM, Ben Davenport wrote:
>
> I fully support this (it's what I suggested over a year ago), but what it
> comes down to is BitPay, Coinbase, Blockchain and Bitstamp getting
> together, agreeing what they're going to use, and doing a little joint
> customer education campaign around it. If there's community momentum around
> "bits", great.
>
> My only addition is that I think we should all stop trying to attach SI
> prefixes to the currency unit. Name me another world currency that uses SI
> prefixes. No one quotes amounts as 63 k$ or 3 M$. The accepted standard at
> least in the US is <currency-symbol><amount><modifier>, i.e. $63k or $3M.
> That may not be accepted form everywhere, but in any case it's an informal
> format, not a formal one. The important point is there should be one base
> unit that is not modified with SI prefixes. And I think the arguments are
> strong for that unit being = 100 satoshi.
>
> Ben
>
>
>
>
> On Fri, May 2, 2014 at 12:17 PM, Jeff Garzik <jgarzik at bitpay.com<javascript:_e(%7B%7D,'cvml','jgarzik at bitpay.com');>
> > wrote:
>
>> <vendor hat: on>
>>
>> Related:
>> http://blog.bitpay.com/2014/05/02/bitpay-bitcoin-and-where-to-put-that-decimal-point.html
>>
>> --
>> Jeff Garzik
>> Bitcoin core developer and open source evangelist
>> BitPay, Inc. https://bitpay.com/
>>
>>
>> ------------------------------------------------------------------------------
>> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
>> Instantly run your Selenium tests across 300+ browser/OS combos. Get
>> unparalleled scalability from the best Selenium testing platform
>> available.
>> Simple to use. Nothing to install. Get started now for free."
>> http://p.sf.net/sfu/SauceLabs
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net<javascript:_e(%7B%7D,'cvml','Bitcoin-development at lists.sourceforge.net');>
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>
>
>
> ------------------------------------------------------------------------------
> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> Instantly run your Selenium tests across 300+ browser/OS combos. Get
> unparalleled scalability from the best Selenium testing platform available.
> Simple to use. Nothing to install. Get started now for free."http://p.sf.net/sfu/SauceLabs
>
>
>
> _______________________________________________
> Bitcoin-development mailing listBitcoin-development at lists.sourceforge.net <javascript:_e(%7B%7D,'cvml','Bitcoin-development at lists.sourceforge.net');>https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>
--
There's no trick to being a humorist when you have the whole government
working for you -- Will Rodgers
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140502/2e5065c9/attachment.html>

2023-06-07 17:20:35 CEST

- reply

📅 Original date posted:2014-05-03
📝 Original message:I have to agree with Mike. Human language is surprisingly tolerant of
overloading and inference from context. Neurotypical people have no
problem with it and perceive a software engineer's aversion to it as
being pedantic and strange. Note that "bits" was a term for a unit of
money long before the invention of digital computers.
Aaron
There's no trick to being a humorist when you have the whole
government working for you -- Will Rodgers
On Fri, May 2, 2014 at 7:06 PM, Gordon Mohr <gojomo at gmail.com> wrote:
> [resend - apologies if duplicate]
>
> Microbitcoin is a good-sized unit, workable for everyday transaction
> values, with room-to-grow, and a nice relationship to satoshis as 'cents'.
>
> But "bits" has problems as a unit name.
>
> "Bits" will be especially problematic whenever people try to graduate
> from informal use to understanding the system internals - that is, when
> the real "bits" of key sizes, hash sizes, and storage/bandwidth needs
> become important. The "bit" as "binary digit" was important enough that
> Satoshi named the system after it; that homage gets lost if the word is
> muddied with a new retconned meaning that's quite different.
>
> Some examples of possible problems:
>
> * If "bit" equals "100 satoshis", then the natural-language unpacking of
> "bit-coin" is "100 satoshi coin", which runs against all prior usage.
>
> * If people are informed that a "256-bit private key" is what ultimately
> controls their balances, it could prompt confusion like, "if each key
> has 256-bits, will I need 40 keys to hold 10,000.00 bits?"
>
> * When people learn that there are 8 bits to a byte, they may think,
> "OK, my wallet holding my 80,000.00 bits will then take up 10 kilobytes".
>
> * When people naturally extend "bit" into "kilobits" to mean "1000
> bits", then the new coinage "kilobits" will mean the exact same amount
> (100,000 satoshi) as many have already been calling "millibits".
>
> I believe it'd be best to pick a new made-up single-syllable word as a
> synonym for "microbitcoin", and I've laid out the case for "zib" as that
> word at <http://zibcoin.org>.
>
> 'Zib' also lends itself to an expressive unicode symbol, 'Ƶ'
> (Z-with-stroke), that remains distinctive even if it loses its stroke or
> gets case-reversed. (Comparatively, all 'b'-derived symbols for
> data-bits, bitcoins, or '100 satoshi bits' risk collision in contexts
> where subtleties of casing/stroking are lost.)
>
> (There's summary of more problems with "bit" in the zibcoin.org FAQ at:
> <http://zibcoin.org/faq#why-not-bits-to-mean-microbitcoins>.)
>
> - Gordon
>
> On 5/1/14, 3:35 PM, Aaron Voisine wrote:
>> I'm also a big fan of standardizing on microBTC as the standard unit.
>> I didn't like the name "bits" at first, but the more I think about it,
>> the more I like it. The main thing going for it is the fact that it's
>> part of the name bitcoin. If Bitcoin is the protocol and network, bits
>> are an obvious choice for the currency unit.
>>
>> I would like to propose using Unicode character U+0180, lowercase b
>> with stroke, as the symbol to represent the microBTC denomination,
>> whether we call bits or something else:
>> http://www.fileformat.info/info/unicode/char/0180/index.htm
>>
>> Another candidate is Unicode character U+2422, the blank symbol, but I
>> prefer stroke b.
>> http://www.fileformat.info/info/unicode/char/2422/index.htm
>>
>> Aaron
>>
>> There's no trick to being a humorist when you have the whole
>> government working for you -- Will Rodgers
>>
>>> On Apr 21, 2014 5:41 AM, "Pieter Wuille" <pieter.wuille at gm...> wrote:
>>>
>>>> On Apr 21, 2014 3:37 AM, "Un Ix" <slashdevnull at ...> wrote:
>>>>
>>>> Something tells me this would be reduced to a single syllable in common
>>>> usage I.e. bit.
>>>
>>> What units will be called colloquially is not something developers will
>>> determine. It will vary, depend on language and culture, and is not
>>> relevant to this discussion in my opinion.
>>>
>>> It may well be that people in some geographic or language area will end up
>>> (or for a while) calling 1e-06 BTC "bits". That's fine, but using that as
>>> "official" name in software would be very strange and potentially confusing
>>> in my opinion. As mentioned by others, that would seem to me like calling
>>> dollars "bucks" in bank software. Nobody seems to have a problem with
>>> having colloquial names, but "US dollar" or "euro" are far less ambiguous
>>> than "bit". I think we need a more distinctive name.
>>>
>>> --
>>> Pieter
>>
>> ------------------------------------------------------------------------------
>> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
>> Instantly run your Selenium tests across 300+ browser/OS combos. Get
>> unparalleled scalability from the best Selenium testing platform available.
>> Simple to use. Nothing to install. Get started now for free."
>> http://p.sf.net/sfu/SauceLabs
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>
> ------------------------------------------------------------------------------
> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> Instantly run your Selenium tests across 300+ browser/OS combos. Get
> unparalleled scalability from the best Selenium testing platform available.
> Simple to use. Nothing to install. Get started now for free."
> http://p.sf.net/sfu/SauceLabs
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

2023-06-07 17:20:35 CEST

- reply

📅 Original date posted:2014-05-01
📝 Original message:I'm also a big fan of standardizing on microBTC as the standard unit.
I didn't like the name "bits" at first, but the more I think about it,
the more I like it. The main thing going for it is the fact that it's
part of the name bitcoin. If Bitcoin is the protocol and network, bits
are an obvious choice for the currency unit.
I would like to propose using Unicode character U+0180, lowercase b
with stroke, as the symbol to represent the microBTC denomination,
whether we call bits or something else:
http://www.fileformat.info/info/unicode/char/0180/index.htm
Another candidate is Unicode character U+2422, the blank symbol, but I
prefer stroke b.
http://www.fileformat.info/info/unicode/char/2422/index.htm
Aaron
There's no trick to being a humorist when you have the whole
government working for you -- Will Rodgers
> On Apr 21, 2014 5:41 AM, "Pieter Wuille" <pieter.wuille at gm...> wrote:
>
>>On Apr 21, 2014 3:37 AM, "Un Ix" <slashdevnull at ...> wrote:
>>
>> Something tells me this would be reduced to a single syllable in common
>> usage I.e. bit.
>
> What units will be called colloquially is not something developers will
> determine. It will vary, depend on language and culture, and is not
> relevant to this discussion in my opinion.
>
> It may well be that people in some geographic or language area will end up
> (or for a while) calling 1e-06 BTC "bits". That's fine, but using that as
> "official" name in software would be very strange and potentially confusing
> in my opinion. As mentioned by others, that would seem to me like calling
> dollars "bucks" in bank software. Nobody seems to have a problem with
> having colloquial names, but "US dollar" or "euro" are far less ambiguous
> than "bit". I think we need a more distinctive name.
>
> --
> Pieter