Aaron Voisine [ARCHIVE]

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

Public Key

npub18gjvug29c4yg46lmplq38e75gg6wn5mn8taytckcsr4jt8p74h3s5knkzl

Profile Code

nprofile1qqsr5fxwy9zu2jy2a0aslsgnul2yyd8f6den47j9utvgp6e9nsl2mcc72ctu3

Author Public Key

npub18gjvug29c4yg46lmplq38e75gg6wn5mn8taytckcsr4jt8p74h3s5knkzl

Show more details

Last Notes

2023-06-07 17:55:12

- reply

📅 Original date posted:2017-01-06
📝 Original message:Credit card transactions are simply an expample of a widely used payment
system that has frequent fraud and chargebacks. The argument I'm making is
that different people in different situations value speed and convenience
over a known fraud risk. Instant zero confirmation transactions are
extremely useful despite the risk in all kinds of real world situations.
You can't substitute your own value judgements for everyone in every
situation.
Aaron
On Thu, Jan 5, 2017 at 6:15 PM <bfd at cock.lu> wrote:
> With a credit card you have an institution worth billions of dollars
>
> asserting that a payment has been made, with the option that it may be
>
> retracted under special circumstances by the card issuer.
>
>
>
> Unconfirmed Bitcoin transactions with a SPV client has you trusting
>
> that the un-authenticated DNS seed lookup has not been tampered with,
>
> the connection to the random node that you connect to has not been
>
> tampered with, and that the seed nor the node are attempting to
>
> manipulate you.
>
>
>
> The two scenarios aren’t even remotely comparable.
>
>
>
>
>
> On 2017-01-04 00:56, Aaron Voisine wrote:
>
> > 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/20170106/2aaca08b/attachment.html>

2023-06-07 17:55:07

- 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 17:55:06

- reply

📅 Original date posted:2017-01-03
📝 Original message:Knowing that a transaction is property formatted and that it has been
broadcast to the gossip network is useful in many situations. You're only
thinking about whether you can know a transaction is valid and/or settled.
This is not the only possible useful information in actual real world use.
Any situation where credit card transactions are accepted today for
instance, it is useful to know that a transaction has been initiated, even
though it can be reversed at any time up to 60 days later.
Aaron Voisine
co-founder and CEO
breadwallet <http://breadwallet.com>
On Tue, Jan 3, 2017 at 4:10 PM, <bfd at cock.lu> wrote:
> Unfortunately a non validating SPV wallet has absolutely no idea if
> the information about an unconfirmed transaction they are seeing is
> anything but properly formatted. They are connecting to an easily
> manipulated, sybil attacked, and untrusted network and then asking
> them for financial information. Seeing an unconfirmed transaction in a
> wallet that's not also fully validating is at best meaningless.
>
>
> On 2017-01-03 15:46, Aaron Voisine wrote:
>
>> 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 [2]
>>
>> 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 [1]
>>>>
>>>
>>> _______________________________________________
>>>
>>> bitcoin-dev mailing list
>>>
>>> bitcoin-dev at lists.linuxfoundation.org
>>>
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev [1]
>>>
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev [1]
>>>
>>
>>
>>
>> Links:
>> ------
>> [1] https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> [2] http://breadwallet.com
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170103/06669e05/attachment-0001.html>

2023-06-07 17:55:05

- 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 17:55:03

- 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 17:51:24

- 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 17:51:04

- reply

📅 Original date posted:2016-06-18
📝 Original message:This works for segwit version 1 with the addition of also using a different
chain id.
I presume that segwit version 2 will be implementing schnorr signatures.
What do we know about the likely implementation details? Is there any way
to avoid using a third derivation path to support it?
Aaron Voisine
co-founder and CEO
breadwallet <http://breadwallet.com>
On Tue, Jun 14, 2016 at 8:41 AM, Daniel Weigl via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hi List,
>
> Following up to the discussion last month (
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-May/012695.html
> ), ive prepared a proposal for a BIP here:
>
>
> https://github.com/DanielWeigl/bips/blob/master/bip-p2sh-accounts.mediawiki
>
>
> Any comments on it? Does anyone working on a BIP44 compliant wallet
> implement something different?
> If there are no objection, id also like to request a number for it.
>
> Thx,
> Daniel
> _______________________________________________
> 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/20160617/e8e17b28/attachment.html>

2023-06-07 17:50:45

- reply

📅 Original date posted:2016-05-14
📝 Original message:On Sat, May 14, 2016 at 7:08 AM, Pavol Rusnak via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On 14/05/16 09:00, Andreas Schildbach via bitcoin-dev wrote:
> > The whole idea of BIP43 (which BIP44 bases on) is that how these BIPs
> > define balance retrieval never changes. This is to make sure you always
> > see the same balance on "same BIP" wallets (and same seed of course).
>
> This! Thanks Andreas for formulating my thought that I was not able to
> articulate earlier.
>
Indeed, this would still be the case when using a new BIPXX to define
adding segwit chains to what were previously BIP43/44 wallets. In this case
retrieval of a BIP44 wallet remains exactly the same as it did before. A
BIP44 wallet can still be recovered with any BIP44 compatible wallet
software. After you upgrade an existing BIP44 wallet to a BIPXX wallet, now
it is no longer a BIP44 wallet. It is now a BIPXX wallet, and can only be
recovered using BIPXX compatible wallet software.
If you are concerned about making a new BIP that fits in the BIP43
framework, i.e. a new purpose number, there's no reason this can't also be
done. You could create a new purpose number YY. Wallets that follow BIPYY
look just like BIPXX, except that they may only contain segwit address
chains, no standard P2PKH address chains.
On Sat, May 14, 2016 at 9:14 AM, Jonas Schnelli via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> AFAIK: Bip39 import (cross-wallet) is not supported by Schildbachs
> android wallet [1] and Electrum [2] and Breadwallet [3].
Breadwallet is BIP39, with the BIP43 purpose 0 derivation path, and I
believe Schlindbachs is as well. Electrum has their own format. I don't
know if it also supports sweeping other mnemonics and wallet layouts.
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/20160514/270a10da/attachment-0001.html>

2023-06-07 17:50:44

- reply

📅 Original date posted:2016-05-15
📝 Original message:On Sun, May 15, 2016 at 5:08 AM, Daniel Weigl via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> > 0x40000000 would be the next available to specify witness addresses.
> > This is compatible with existing accounts and wallet layouts.
>
> my main concern here is that
> -) every Bip<this-bip>-compatible wallet in the future will have to
> implement all (then probably) legacy derivation and tx schemes.
>
I can see the advantage of a segwit only scheme, but we will need to
support old derivations anyway for many decades if not indefinitely. People
are using it to store value for the long term.
> -) it does not fail in a deterministic way, if I import a seed or
> xPriv/xPub across different capable wallets.
> It is more visible if one account has [no funds/does not show up]
> at all after an import than if something shows up but you need to make sure
> that the balance is what you might expect.
>
This is certainly a downside. It has to be weighed against the benefit of
being able to upgrade existing wallets in place. Asking users to create a
new wallet, and replace their recovery phrase backups is an even bigger
problem in my estimation.
What do you think of doing both? A new BIP43 purpose number for segwit only
wallets, but that also specifies 0x40000000/1 for the change/receive index
so that the scheme is compatible with other schemes for upgrade existing
wallets in place? There will certainly be wallet developers who decide to
upgrade in place, but we can standardized both how to indicate segwit
chains, independent of segwit only schemes or upgrade schemes, and still
have the advantages of a new segwit only BIP43 purpose number.
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/20160515/447aa364/attachment.html>

2023-06-07 17:50:41

- reply

📅 Original date posted:2016-05-13
📝 Original message: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.
Aaron Voisine
co-founder and CEO
breadwallet <http://breadwallet.com>
On Fri, May 13, 2016 at 9:11 AM, Pavol Rusnak <stick at satoshilabs.com> wrote:
> On 13/05/16 18:03, Aaron Voisine wrote:
> > I like the idea of specifying the type of address as a bit field flag.
> > 0x80000000 is already used to specify hardened derivation, so 0x40000000
> > would be the next available to specify witness addresses. This is
> > compatible with existing accounts and wallet layouts.
>
> I think this is over-optimization. What is the advantage of
>
> m/0'/0x40000000 instead of m/whatever'/0 ?
>
> But this is off-topic anyway, as we are discussing multiple-accounts per
> wallet layout here, not one-account-per-wallet design.
>
> --
> 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/53135073/attachment.html>

2023-06-07 17:50:41

- 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:50:40

- reply

📅 Original date posted:2016-05-13
📝 Original message:We use the default BIP32 wallet layout, mentioned in BIP43 as purpose "0".
We were thinking of of having 4 chains below the "account" level, the
original 0 and 1 for receive and change addresses, and then 0x40000000 and
0x40000001 for P2WPKH-in-P2SH versions of receive and change addresses.
I like the idea of specifying the type of address as a bit field flag.
0x80000000 is already used to specify hardened derivation, so 0x40000000
would be the next available to specify witness addresses. This is
compatible with existing accounts and wallet layouts.
As Daniel mentioned, the downside is that trying to recover on non-segwit
software will miss segwit receives, however it does avoid the problem of
having to check multiple address types for each key.
Aaron Voisine
co-founder and CEO
breadwallet <http://breadwallet.com>
On Fri, May 13, 2016 at 8:00 AM, Pavol Rusnak via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On 13/05/16 15:16, Daniel Weigl via bitcoin-dev wrote:
> > 2) Define a new derivation path, parallel to Bip44, but a different
> 'purpose' (eg. <BipNumber-of-this-BIP>' instead of 44'). Let the user
> choose which account he want to add ("Normal account", "Witness account").
>
> We had quite a long discussion in our team some time ago and we agreed
> on that option #2 is much better and we'd like to implement this way in
> myTREZOR.
>
> > +) Wallet needs only to take care of 1 address per public key
>
> True, if this BIP only supports P2WPKH.
>
> P2WSH should probably be handled by another account type and another
> BIP, anyway.
>
> > Has any Bip44 compliant wallet already done any integration at this
> point?
>
> We have something in the pipeline, but no visible results yet.
>
> --
> Best Regards / S pozdravom,
>
> Pavol "stick" Rusnak
> SatoshiLabs.com
> _______________________________________________
> 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/20160513/656973a5/attachment.html>

2023-06-07 17:46:25

- reply

📅 Original date posted:2015-12-23
📝 Original message:> You present this as if the Bitcoin Core development team is in charge
> of deciding the network consensus rules, and is responsible for
> making changes to it in order to satisfy economic demand. If that is
> the case, Bitcoin has failed, in my opinion.
Pieter, what's actually happening is that the bitcoin-core release has
become a Schelling point in the consensus game:
https://en.wikipedia.org/wiki/Schelling_point
Due to the strong incentives for consensus, everyone is looking for an
obvious reference point that they think everyone else will also pick, even
though the point itself isn't critical, only that everyone agree on
whatever point is picked. Like it or not, the bitcoin-core release, and by
extension it's committers have a great degree of influence over what the
community as a whole decides to do. If core screws things up badly enough,
yes, the community will settle on some other focal point for consensus, but
the cost and risk of doing so is high, so there is indeed unavoidable moral
hazard for whoever has control over any such focus point.
Aaron Voisine
co-founder and CEO
breadwallet <http://breadwallet.com>
On Wed, Dec 16, 2015 at 10:34 AM, Pieter Wuille via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Wed, Dec 16, 2015 at 3:53 PM, Jeff Garzik via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> > 2) If block size stays at 1M, the Bitcoin Core developer team should
> sign a
> > collective note stating their desire to transition to a new economic
> policy,
> > that of "healthy fee market" and strongly urge users to examine their fee
> > policies, wallet software, transaction volumes and other possible User
> > impacting outcomes.
>
> You present this as if the Bitcoin Core development team is in charge
> of deciding the network consensus rules, and is responsible for making
> changes to it in order to satisfy economic demand. If that is the
> case, Bitcoin has failed, in my opinion.
>
> What the Bitcoin Core team should do, in my opinion, is merge any
> consensus change that is uncontroversial. We can certainly -
> individually or not - propose solutions, and express opinions, but as
> far as maintainers of the software goes our responsibility is keeping
> the system running, and risking either a fork or establishing
> ourselves as the de-facto central bank that can make any change to the
> system would greatly undermine the system's value.
>
> Hard forking changes require that ultimately every participant in the
> system adopts the new rules. I find it immoral and dangerous to merge
> such a change without extremely widespread agreement. I am personally
> fine with a short-term small block size bump to kick the can down the
> road if that is what the ecosystem desires, but I can only agree with
> merging it in Core if I'm convinced that there is no strong opposition
> to it from others.
>
> Soft forks on the other hand only require a majority of miners to
> accept them, and everyone else can upgrade at their leisure or not at
> all. Yes, old full nodes after a soft fork are not able to fully
> validate the rules new miners enforce anymore, but they do still
> verify the rules that their operators opted to enforce. Furthermore,
> they can't be prevented. For that reason, I've proposed, and am
> working hard, on an approach that includes Segregated Witness as a
> first step. It shows the ecosystem that something is being done, it
> kicks the can down the road, it solves/issues half a dozen other
> issues at the same time, and it does not require the degree of
> certainty needed for a hardfork.
>
> --
> Pieter
> _______________________________________________
> 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/20151222/2a316e8d/attachment.html>

2023-06-07 17:38:12

- reply

📅 Original date posted:2015-08-26
📝 Original message:Breadwallet also implements CPFP when spending unconfirmed non-change
inputs. It was released back in May, but happy to let Andreas have the
bounty:
https://github.com/voisine/breadwallet/blob/v0.5.1/BreadWallet/BRWallet.m#L382
Aaron Voisine
co-founder and CEO
breadwallet.com
On Wed, Jul 15, 2015 at 9:26 AM, Dan Bryant via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Offering a bounty for this feature
>
> Specifically...
>
> Anyone who can put a CPFP transaction creation feature into any wallet
> featured on the bitcoin homepage (ref1) can claim this bounty. The
> funds are being raised by donation. The funds will be dispersed from
> the following address when the bounty is claimed:
> 3FEUByMeaxrNmBCVYjvsnhyAjiUdat5i7M
>
> Currently there isn't much in there, but I welcome angels to fill the
> bucket.
>
> Here's proof that the multisig address is not 1 of 1:
> https://bitcointalk.org/index.php?topic=1122956.0
>
> Bounty announce: https://bitcointalk.org/index.php?topic=1123464.0
>
> ref1: https://bitcoin.org/en/choose-your-wallet
> _______________________________________________
> 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/20150826/a8403484/attachment.html>

2023-06-07 15:41:35

- 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 15:41:05

- reply

📅 Original date posted:2015-06-27
📝 Original message:This is a reasonable vision, but I think we can do better. We can easily
achieve the goal of letting hobbyists with very limited resources and
connectivity run full nodes. The way to do this is to limit growth of the
blockchain, and the right way to do that is to have fees that reflect the
costs of having large numbers of people validating, storing, and serving
transactions.
I think we're all agreed that decentralization is priority #1. It's what
makes bitcoin unique from everything else. So what then is the best way to
have fees reflect the costs? Having a fixed blocksize (fixed production
quotas) is one very disruptive option that would be a significant departure
from what we have today. The way the network today discourages spam and
other low value uses of the blockchain is with minimum relay fees and
transaction selection rules for blocks. This technique is proven, safe, and
can easily be tuned and experimented with. It's also what all bitcoin
software today is designed to work with.
Aaron Voisine
co-founder and CEO
breadwallet.com
On Sat, Jun 27, 2015 at 5:14 PM, Santino Napolitano <
santino.napolitano at yandex.com> wrote:
>
> There is much heated debate going on right now and I know it can be very
> stressful but I'd like to point out that it is really amazing how
> passionately so many feel about this once very small project. Let's not
> forget there is something really special going on here and we're all part
> of it.
>
> The current debate has little to do with block size or hard-forks, IMO.
> It's about the nature of Bitcoin and what it means to people and how it
> will grow. I would like to take a moment to share my interpretation of the
> original author's intent based on everything I could find and read from
> this person. This is not to say their original vision is paramount-- or
> even that I got it completely correct but I think it might do us some good
> to think about.
>
> It seems as though the incentive conceived of for running a full network
> node was that it would enable mining. The proceeds from mining (new coins
> and transaction fees) would be the reward and provide a reason to continue
> operating these nodes. If fees are ever to be a sufficient reward and still
> allow for a practical and useful system the size of the blocks must grow
> significantly as must the user base. I'm not sure that this is really
> contested but I haven't exhaustively reviewed everyone's opinion so please
> excuse me if I have marginalized you. If you do contest that I would be
> interested in hearing it.
>
> Further, it appears clear that the original author intended organizations
> operating full network nodes would provide connectivity to light clients
> and these light clients would make up the majority of the user base. This
> is completely consistent with current trends in Internet consumption, e.g.
> tablets and phones are becoming more preferred to even owning a traditional
> computer. Having the system be entirely decentralized and trustless for
> every client does not appear to me to be the original design goal. Yes, the
> whitepaper speaks of the design goal as not having a need for a trusted
> third party but it does not say that some amount of trust won't be
> preferred by a majority of users. In fact, in the SPV section it implies
> some amount of localized trust is perhaps a necessary trade-off and maybe
> businesses should still run their own full network node if they want the
> stronger completely trustless guarantee. The global decentralized consensus
> appears meant to make the network r
> esilient to a single government or other adversary's ability to shut the
> network down. If you really want to trust no one it is your option at a
> cost and should be possible by design. The author further gives evidence
> that they believe Moore's observation would keep the idea of running a full
> network node a practical one at global scale for perpetuity. It does not
> appear as if they intended for every individual to run one at home nor in
> their pocket.
>
> If my interpretation seems incorrect please do point it out. I hope this
> hasn't been too off-topic and distracting. The original author's
> engineering ingenuity is what gave me any interest in this project so
> re-visiting their design and scaling intentions might be helpful for us to
> move forward-- together.
>
> _______________________________________________
> 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/a5fe2a0f/attachment-0001.html>

2023-06-07 15:40:43

- reply

📅 Original date posted:2015-06-28
📝 Original message:Moving the list to BCC, since this isn't really a technical discussion.
On Sun, Jun 28, 2015 at 9:37 AM, Venzen Khaosan <venzen at mail.bihthai.net>
wrote:
>
> Bitcoin's exchange rate, as a commodity money floating freely in the
> market, will go up and down according to speculative cycles and we
> should conceptually separate its valuation in fiat terms, from its
> fundamental value which is: mathematical consensus, cryptographic
> transaction security and censorship resistance, etc.
I get the feeling we might be reasoning from different underlying
assumptions, but I don't think you can separate value that way. Those
fundamental properties were chosen to serve the goal of creating a digital
commodity money. They are useful only in as much as they serve ends that
people value. Consensus, security, censorship resistance are valuable
because they are desirable properties for money to have.
If you want to argue that the properties of bitcoin are valuable for other
things besides money, that's fine, but those other uses presumably can be
accomplished with tiny amounts of bitcoin, so don't appreciably increase
demand.
> These values are
> critically reliant on Bitcoin's *degree of decentralization* for them
> to remain true and for Bitcoin to retain its meaning, and, therefore,
> its value. That is what I point out when I say "greater adoption has
> not reflected in the price chart". And that may remain the case for
> evermore because the value is in the protocol, the blockchain and its
> utility and degree of decentralization, not in the chart or the size
> of the user base
>
I think it depends on what you mean by "adoption". Adoption as a
store-of-value must necessarily increase the market price given the
restricted and eventually fixed supply. If we're talking about merchant
adoption as a payment system, or increased transaction volume, the yes,
these things have no direct impact on the price. They only impact the price
indirectly in as much as they encourage further adoption as a
store-of-value.
> I argue that we already know what the value of Bitcoin is. In its
> current form Bitcoin most likely fulfills 80% or 90% of its eventual
> fully evolved value. Increased adoption will not strengthen the
> fundamentals, so let's proceed with scaling that will safeguard
> Bitcoin's fundamental value and implement protections that ensure
> quality of decentralization.
>
Increased adoption does strengthen the fundamentals. The most important
fundamental for money is how many other people standardize on the same
money, and want to hold it. This drives it's price in terms of other
commodities. You want to hold what everyone else wants to hold.
Aaron Voisine
co-founder and CEO
breadwallet.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150628/1f837fbc/attachment.html>

2023-06-07 15:40:42

- reply

📅 Original date posted:2015-06-27
📝 Original message:On Sat, Jun 27, 2015 at 3:19 AM, Venzen Khaosan <venzen at mail.bihthai.net>
wrote:
>
> That is a false assumption. Given the increased adoption of Bitcoin by
> users and businesses during the past year, does the price chart
> reflect greater value or price? Of course not, the price chart is at
> terminal lows. Fact not fiction.
>
You're not taking speculative cycles into account. For most of 2013 the
price was in the $100 range. Adoption as a store-of-value is what
determines the price over the long term, as with any monetary commodity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150627/5088206e/attachment-0001.html>

2023-06-07 15:40:34

- 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 15:40:33

- 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 15:40:31

- 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 15:39:13

- 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 15:38:59

- 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 15:38:13

- 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 15:38:12

- 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 15:38:08

- 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 15:38:08

- 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 15:38:07

- 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 15:38:06

- reply

📅 Original date posted:2015-06-16
📝 Original message:We're planning to run our own full nodes to take load off the volunteer
network as breadwallet use increases, and also contribute any SPV serving
performance optimizations we can make to bitcoin-core. Just want to let
people know we share these concerns and have plans to mitigate any negative
impact on the network.
Aaron Voisine
co-founder and CEO
breadwallet.com
On Mon, Jun 15, 2015 at 8:49 PM, Kevin Greene <kgreenek at gmail.com> wrote:
>
>
> On Mon, Jun 15, 2015 at 8:41 PM, Luke Dashjr <luke at dashjr.org> wrote:
>
>> On Tuesday, June 16, 2015 3:30:44 AM Kevin Greene wrote:
>> > Would SPV wallets have to pay to connect to the network too? From the
>> > user's perspective, it would be somewhat upsetting (and confusing) to
>> see
>> > your balance slowly draining every time you open your wallet app. It
>> would
>> > also tie up outputs every time you open up your wallet. You may go to
>> pay
>> > for something in a coffee shop, only to find that you can't spend your
>> > bitcoin because the wallet had to create a transaction to pay to sync
>> with
>> > the network.
>> >
>> > Also, users of centralized wallet services like Coinbase would not have
>> to
>> > pay that fee; but users of native wallets like breadwallet would have no
>> > such option. This incentivizes users to use centralized wallets.
>> >
>> > So this is kind of imposing a worse user experience on users who want to
>> > use bitcoin the "right" way. That doesn't seem like a good thing to me
>> :/
>>
>> SPV isn't the "right" way either ;)
>>
>
> 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.
>
>
>>
>> If you're running a full node (the real "right way"), you should be able
>> to
>> earn more bitcoins than you pay out.
>>
>> Luke
>>
>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> 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/79706241/attachment.html>

2023-06-07 15:37:40

- reply

📅 Original date posted:2015-06-14
📝 Original message:>
> Yes, it does bother (some) people to see the consensus based system
> because of the difficulties that can be associated with implementing
> it. But that's the way it is. If you don't like consensus based
> systems (or decentralized, distributed systems) this is probably the
> wrong space for you.
>
If consensus must be reached to make any changes, that just means that
changes of anything more than trivial consequence simply can't be made.
Extreme bias toward the status-quo will only work if external factors
affecting the network also remain static.
Aaron Voisine
co-founder and CEO
breadwallet.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150613/7454d242/attachment.html>

2023-06-07 15:37:21

- reply

📅 Original date posted:2015-06-12
📝 Original message:One possible solution that wallets could adopt when blocks fill up, would
be to abandon the p2p network for transaction propagation altogether, and
instead work directly with a handful of the largest miners and pools to get
transactions into blocks. The miners could auction off space in their
blocks with the guarantee that they will be included in the order accepted.
We'd lose the peer-to-peer nature of sending transactions for a federated
service operator style model, but avoid the problem of unpredictable
transaction failure. Also, unlike replace-by-fee, this would allow for
a send-and-forget usage pattern, as well as known up-front fees. Something
like this is certainly what I imagine the large hosted wallet companies
will end up moving to.
Aaron
On Thursday, June 11, 2015, Mike Hearn <mike at plan99.net> wrote:
> > Re: "dropped in an unpredictable way" - transactions would be dropped
>> > lowest fee/KB first, a completely predictable way.
>>
>> Quite agreed.
>
>
> No, Aaron is correct. It's unpredictable from the perspective of the user
> sending the transaction, and as they are the ones picking the fees, that is
> what matters.
>
--
Aaron Voisine
co-founder and CEO
breadwallet.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150611/18a6e3a1/attachment.html>

2023-06-07 15:37:19

- reply

📅 Original date posted:2015-06-10
📝 Original message:The other complication is that this will tend to be a lagging indicator
based on network congestion from the last time you connected. If we assume
that transactions are being dropped in an unpredictable way when blocks are
full, knowing the network congestion *right now* is critical, and even then
you just have to hope that someone who wants that space more than you do
doesn't show up after you disconnect.
Aaron Voisine
co-founder and CEO
breadwallet.com
On Wed, Jun 10, 2015 at 1:26 PM, Mike Hearn <mike at plan99.net> wrote:
> I described an alternative way for SPV wallets to learn about fees some
> time ago. It requires a new transaction version that embeds output values
> into the signed data. Then an upgrade to the P2P protocol to send UTXO data
> along with transactions when they are relayed.
>
> The idea is that the wallet sets a Bloom filter with an FP rate that
> ensures it will see some random subset of all transactions being broadcast
> on the network, and with the extra data, it can calculate the fee paid.
> Once a transaction broadcast is observed the wallet includes that tx hash
> in its next Bloom filter, thus it can see which block the tx confirmed in.
> By measuring the amount of time that passed between a broadcast and it
> appearing in a block, it can calculate its own tables of fee paid:time
> taken.
>
> This has the advantage that you don't have to trust miners to publish data
> accurately. However it requires some protocol upgrades and of course, a lot
> of new code in SPV wallets.
>
> The way Bitcoin Wallet for Android handles fees currently is to just
> update a hard coded value every so often.
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> 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/20150610/e4d5b79a/attachment.html>

2023-06-07 15:37:18

- reply

📅 Original date posted:2015-06-11
📝 Original message:> A Header-PoW-verifying client could still be given all transactions in a
recent block, from which it can see the in-band fees directly.
You don't know the fees paid by any given transaction unless you also have
all it's inputs. Transaction inputs do not include an amount. You could
however get the average fee-per-kb paid by all transactions in a block by
looking at the coinbase transaction, subtracting the block reward, and
dividing by the size of block minus the header.
Aaron Voisine
co-founder and CEO
breadwallet.com
On Thu, Jun 11, 2015 at 11:30 AM, Nathan Wilcox <nathan at leastauthority.com>
wrote:
> On Wed, Jun 10, 2015 at 2:03 PM, Peter Todd <pete at petertodd.org> wrote:
>
>> On Wed, Jun 10, 2015 at 02:00:27PM -0600, Nathan Wilcox wrote:
>> > On Wed, Jun 10, 2015 at 1:19 PM, Aaron Voisine <voisine at gmail.com>
>> wrote:
>> >
>> > > It could be done by agreeing on a data format and encoding it in an
>> > > op_return output in the coinbase transaction. If it catches on it
>> could
>> > > later be enforced with a soft fork.
>> > >
>> > >
>> > Sounds plausible, except SPV protocols would need to include this
>> coinbase
>> > txn if it's going to help SPV clients. (Until a softfork is activated,
>> SPV
>> > clients should not rely on this encoding, since until that time the
>> results
>> > can be fabricated by individual miners.)
>>
>> Fee stats can always be fabricated by individual miners because fees can
>> be paid out-of-band.
>>
>>
> This is a point I hadn't considered carefully before. I don't understand
> the marketplace here or why miners would want to move fees outside of
> explicit inband fees. Implicit in this proposal is that the statistics only
> cover in-band data, because that's the scope of consensus rules, and thus
> the proposal is only as useful as the information of in-band fees is useful.
>
> I've also noticed a detracting technical argument given a particular
> tradeoff:
>
> A Header-PoW-verifying client could still be given all transactions in a
> recent block, from which it can see the in-band fees directly. The
> trade-off is the size of those transactions versus the need to alter any
> consensus rules or do soft forks.
>
> Notice how this trade-off's costs change with maximum block size.
>
>
>
>
>> --
>> 'peter'[:-1]@petertodd.org
>> 00000000000000001245bd2f5c99379ee76836227ded9c08324894faabc0d27f
>>
>
>
>
> --
> Nathan Wilcox
> Least Authoritarian
>
> email: nathan at leastauthority.com
> twitter: @least_nathan
> PGP: 11169993 / AAAC 5675 E3F7 514C 67ED E9C9 3BFE 5263 1116 9993
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150611/574993ab/attachment.html>

2023-06-07 15:37:18

- reply

📅 Original date posted:2015-06-10
📝 Original message:> Sounds plausible, except SPV protocols would need to include this
coinbase txn if it's going to help SPV clients.
Yes you'd either need a way to add those transactions to the bloom filter,
or add/modify a p2p message to request it specifically.
> when you mention Sybil attack, I don't quite follow.
I just mean that someone could spin up a bunch of malicious p2p nodes that
lied about mempool data. It's a bit worse for SPV clients since they can't
verify that unconfirmed transactions are valid.
> I had previously believed fees were fairly static presently,
I actually just added it the other day after getting blockcypher to include
it in their api. The current release is still using a hard coded fee rate.
Aaron Voisine
co-founder and CEO
breadwallet.com
On Wed, Jun 10, 2015 at 1:00 PM, Nathan Wilcox <nathan at leastauthority.com>
wrote:
> On Wed, Jun 10, 2015 at 1:19 PM, Aaron Voisine <voisine at gmail.com> wrote:
>
>> It could be done by agreeing on a data format and encoding it in an
>> op_return output in the coinbase transaction. If it catches on it could
>> later be enforced with a soft fork.
>>
>>
> Sounds plausible, except SPV protocols would need to include this coinbase
> txn if it's going to help SPV clients. (Until a softfork is activated, SPV
> clients should not rely on this encoding, since until that time the results
> can be fabricated by individual miners.)
>
>
>> For real up-to-the-minute fee calculations you're also going to want to
>> look at the current mempool, how many transactions are waiting, what fees
>> they're paying, etc, but of course that information is susceptible to sybil
>> attack.
>>
>
> Hm, when you mention Sybil attack, I don't quite follow.
>
> When a client relies on any report of a mempool [*], this is already
> outside the realm of locally-verifiable SPV information, so they are
> already susceptible to the service making false claims. If that's
> acceptable (and in many cases it may be) then this whole mechanism is moot,
> because the client can ask the service for fee statistics for past blocks.
>
>
>> In practice what we're doing for now is using services like blockcypher
>> who's business is improving reliability of zero-conf to tell us what
>> fee-per-kb is needed, and then putting a hard coded range around it to
>> protect against the service being compromised.
>>
>
> This is interesting for me, because I had previously believed fees were
> fairly static presently, and also because I like hearing about real life
> wallet implementations.
>
> So if this "SPV Fee Stats" feature were added, a wallet might rely on an
> API for timely stats (aka "block height < 1") then verify that the API
> isn't lying after doing SPV verification of fee stats for confirmed blocks.
>
>
> This is also the kind of thing being done for exchange rate data which is
>> probably the bigger security risk until bitcoin becomes the standard unit
>> of account for the planet.
>>
>>
> That makes sense, although there's no SPV equivalent for exchange data.
>
>
> Aaron Voisine
>> co-founder and CEO
>> breadwallet.com
>>
>> On Wed, Jun 10, 2015 at 10:37 AM, Nathan Wilcox <
>> nathan at leastauthority.com> wrote:
>>
>>> [I'm currently wading through bitcoin-development. I'm still about a
>>> month behind, so I apologize in advance for any noisy redundancy in this
>>> post.]
>>>
>>> While reading about blocksize, I've just finished Mike Hearn's blog post
>>> describing expected systemic behavior as actual blocks approach the current
>>> limit (with or without non-protocol-changing implementation improvements):
>>>
>>> https://medium.com/@octskyward/crash-landing-f5cc19908e32
>>>
>>>
>>> One detail Mike uses to argue against the "fee's will save us" line of
>>> reasoning is that wallets have no good way to learn fee information.
>>>
>>> So, here's a proposal to fix that: put fee and (and perhaps block size,
>>> UTXO, etc...) statistics into the locally-verifiable data available to SPV
>>> clients (ie: block headers).
>>>
>>>
>>> It's easy to imagine a hard fork that places details like per-block
>>> total fees, transaction count, fee variance, UTXO delta, etc... in a each
>>> block header. This would allow SPV clients to rely on this data with the
>>> same PoW-backed assurances as all other header data.
>>>
>>> This mechanism seems valuable regardless of the outcome of blocksize
>>> debate. So long as fees are interesting or important, SPV clients should
>>> know about them. (Same for other stats such as UTXO count.)
>>>
>>> Upgrading the protocol without a hard-fork may be possible and is left
>>> as an exercise for the reader. ;-)
>>>
>>> --
>>> Nathan Wilcox
>>> Least Authoritarian
>>>
>>> email: nathan at leastauthority.com
>>> twitter: @least_nathan
>>> PGP: 11169993 / AAAC 5675 E3F7 514C 67ED E9C9 3BFE 5263 1116 9993
>>>
>>>
>>> ------------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> Bitcoin-development mailing list
>>> Bitcoin-development at lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>>
>>>
>>
>
>
> --
> Nathan Wilcox
> Least Authoritarian
>
> email: nathan at leastauthority.com
> twitter: @least_nathan
> PGP: 11169993 / AAAC 5675 E3F7 514C 67ED E9C9 3BFE 5263 1116 9993
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150610/b38d33f6/attachment.html>

2023-06-07 15:37:16

- reply

📅 Original date posted:2015-06-10
📝 Original message:It could be done by agreeing on a data format and encoding it in an
op_return output in the coinbase transaction. If it catches on it could
later be enforced with a soft fork.
For real up-to-the-minute fee calculations you're also going to want to
look at the current mempool, how many transactions are waiting, what fees
they're paying, etc, but of course that information is susceptible to sybil
attack.
In practice what we're doing for now is using services like blockcypher
who's business is improving reliability of zero-conf to tell us what
fee-per-kb is needed, and then putting a hard coded range around it to
protect against the service being compromised. This is also the kind of
thing being done for exchange rate data which is probably the bigger
security risk until bitcoin becomes the standard unit of account for the
planet.
Aaron Voisine
co-founder and CEO
breadwallet.com
On Wed, Jun 10, 2015 at 10:37 AM, Nathan Wilcox <nathan at leastauthority.com>
wrote:
> [I'm currently wading through bitcoin-development. I'm still about a month
> behind, so I apologize in advance for any noisy redundancy in this post.]
>
> While reading about blocksize, I've just finished Mike Hearn's blog post
> describing expected systemic behavior as actual blocks approach the current
> limit (with or without non-protocol-changing implementation improvements):
>
> https://medium.com/@octskyward/crash-landing-f5cc19908e32
>
>
> One detail Mike uses to argue against the "fee's will save us" line of
> reasoning is that wallets have no good way to learn fee information.
>
> So, here's a proposal to fix that: put fee and (and perhaps block size,
> UTXO, etc...) statistics into the locally-verifiable data available to SPV
> clients (ie: block headers).
>
>
> It's easy to imagine a hard fork that places details like per-block total
> fees, transaction count, fee variance, UTXO delta, etc... in a each block
> header. This would allow SPV clients to rely on this data with the same
> PoW-backed assurances as all other header data.
>
> This mechanism seems valuable regardless of the outcome of blocksize
> debate. So long as fees are interesting or important, SPV clients should
> know about them. (Same for other stats such as UTXO count.)
>
> Upgrading the protocol without a hard-fork may be possible and is left as
> an exercise for the reader. ;-)
>
> --
> Nathan Wilcox
> Least Authoritarian
>
> email: nathan at leastauthority.com
> twitter: @least_nathan
> PGP: 11169993 / AAAC 5675 E3F7 514C 67ED E9C9 3BFE 5263 1116 9993
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> 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/20150610/21988162/attachment.html>

2023-06-07 15:34:48

- reply

📅 Original date posted:2015-05-16
📝 Original message:On Sat, May 16, 2015 at 1:35 PM, Owen Gunden <ogunden at phauna.org> wrote:
>
> This strikes me as a leap. There are alternatives that still use bitcoin
> as the unit of value, such as sidechains, offchain, etc. To say that
> these are "not bitcoin" is misleading.
>
The only options available today and in the near future that I'm aware of
are of the centralized custody variety, which is pretty bad in my opinion,
but your point is taken.
>
> Are we sure that raising the block size is the only way to avoid
> "unpredictable transaction failure"? If so, and it's as bad as you say
> it is, aren't we screwed anyway when we inevitably start hitting the cap
> (even if it's raised 10x or 20x)? And if that's the case, then don't we
> do a disservice to users by continuing to pretend that we can make this
> problem go away?
>
When we start bumping up against the block size limit, the transactions at
the margins will experience failure in a way that will be unpredictable to
current wallet software. We can slow blockchain growth by increasing fees
alone, without introducing the additional cost of unpredictability around
confirmation failure, which when it comes down to it is just another
(extreme) way to keep usage low. Instead of fees and unpredictable
confirmation, why not just have fees alone. A single, upfront, known cost.
>
>
> On what do you base this? Gold has a very high cost of using (storage,
> transport) and yet is perhaps the most widely accepted store of value.
>
I would argue that the reason gold is not the one world global currency
that it once was is because of those costs. That's why people shifted over
time to gold backed bank notes and eventually fiat.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150516/b3aa6233/attachment.html>

2023-06-07 15:34:47

- reply

📅 Original date posted:2015-05-13
📝 Original message:> by people and businesses deciding to not use on-chain settlement.
I completely agree. Increasing fees will cause people voluntary economize
on blockspace by finding alternatives, i.e. not bitcoin. A fee however is a
known, upfront cost... unpredictable transaction failure in most cases will
be a far higher, unacceptable cost to the user than the actual fee. The
higher the costs of using the system, the lower the adoption as a
store-of-value. The lower the adoption as store-of-value, the lower the
price, and the lower the value of bitcoin to the world.
> That only measures miner adoption, which is the least relevant.
I concede the point. Perhaps a flag date based on previous observation of
network upgrade rates with a conservative additional margin in addition to
supermajority of mining power.
Aaron Voisine
co-founder and CEO
breadwallet.com
On Wed, May 13, 2015 at 6:19 PM, Pieter Wuille <pieter.wuille at gmail.com>
wrote:
> On Wed, May 13, 2015 at 6:13 PM, Aaron Voisine <voisine at gmail.com> wrote:
>
>> Conservative is a relative term. Dropping transactions in a way that is
>> unpredictable to the sender sounds incredibly drastic to me. I'm suggesting
>> increasing the blocksize, drastic as it is, is the more conservative choice.
>>
>
> Transactions are already being dropped, in a more indirect way: by people
> and businesses deciding to not use on-chain settlement. That is very sad,
> but it's completely inevitable that there is space for some use cases and
> not for others (at whatever block size). It's only a "things don't fit
> anymore" when you see on-chain transactions as the only means for doing
> payments, and that is already not the case. Increasing the block size
> allows for more utility on-chain, but it does not fundamentally add more
> use cases - only more growth space for people already invested in being
> able to do things on-chain while externalizing the costs to others.
>
>
>> I would recommend that the fork take effect when some specific large
>> supermajority of the pervious 1000 blocks indicate they have upgraded, as a
>> safer alternative to a simple flag date, but I'm sure I wouldn't have to
>> point out that option to people here.
>>
>
> That only measures miner adoption, which is the least relevant. The
> question is whether people using full nodes will upgrade. If they do, then
> miners are forced to upgrade too, or become irrelevant. If they don't, the
> upgrade is risky with or without miner adoption.
>
> --
> Pieter
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150513/0268ac4b/attachment.html>

2023-06-07 15:34:47

- reply

📅 Original date posted:2015-05-13
📝 Original message:> I concede the point. Perhaps a flag date based on previous observation of
network upgrade rates with a conservative additional margin in addition to
supermajority of mining power.
It occurs to me that this would allow for a relatively small percentage of
miners to stop the upgrade if the flag date turns out to be poorly chosen
and a large number of non-mining nodes haven't upgraded yet. Would be a
nice safety fallback.
Aaron Voisine
co-founder and CEO
breadwallet.com
On Wed, May 13, 2015 at 6:31 PM, Aaron Voisine <voisine at gmail.com> wrote:
> > by people and businesses deciding to not use on-chain settlement.
>
> I completely agree. Increasing fees will cause people voluntary economize
> on blockspace by finding alternatives, i.e. not bitcoin. A fee however is a
> known, upfront cost... unpredictable transaction failure in most cases will
> be a far higher, unacceptable cost to the user than the actual fee. The
> higher the costs of using the system, the lower the adoption as a
> store-of-value. The lower the adoption as store-of-value, the lower the
> price, and the lower the value of bitcoin to the world.
>
> > That only measures miner adoption, which is the least relevant.
>
> I concede the point. Perhaps a flag date based on previous observation of
> network upgrade rates with a conservative additional margin in addition to
> supermajority of mining power.
>
>
> Aaron Voisine
> co-founder and CEO
> breadwallet.com
>
> On Wed, May 13, 2015 at 6:19 PM, Pieter Wuille <pieter.wuille at gmail.com>
> wrote:
>
>> On Wed, May 13, 2015 at 6:13 PM, Aaron Voisine <voisine at gmail.com> wrote:
>>
>>> Conservative is a relative term. Dropping transactions in a way that is
>>> unpredictable to the sender sounds incredibly drastic to me. I'm suggesting
>>> increasing the blocksize, drastic as it is, is the more conservative choice.
>>>
>>
>> Transactions are already being dropped, in a more indirect way: by people
>> and businesses deciding to not use on-chain settlement. That is very sad,
>> but it's completely inevitable that there is space for some use cases and
>> not for others (at whatever block size). It's only a "things don't fit
>> anymore" when you see on-chain transactions as the only means for doing
>> payments, and that is already not the case. Increasing the block size
>> allows for more utility on-chain, but it does not fundamentally add more
>> use cases - only more growth space for people already invested in being
>> able to do things on-chain while externalizing the costs to others.
>>
>>
>>> I would recommend that the fork take effect when some specific large
>>> supermajority of the pervious 1000 blocks indicate they have upgraded, as a
>>> safer alternative to a simple flag date, but I'm sure I wouldn't have to
>>> point out that option to people here.
>>>
>>
>> That only measures miner adoption, which is the least relevant. The
>> question is whether people using full nodes will upgrade. If they do, then
>> miners are forced to upgrade too, or become irrelevant. If they don't, the
>> upgrade is risky with or without miner adoption.
>>
>> --
>> Pieter
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150513/92f0f8d2/attachment.html>

2023-06-07 15:34:46

- reply

📅 Original date posted:2015-05-13
📝 Original message:Conservative is a relative term. Dropping transactions in a way that is
unpredictable to the sender sounds incredibly drastic to me. I'm suggesting
increasing the blocksize, drastic as it is, is the more conservative
choice. I would recommend that the fork take effect when some specific
large supermajority of the pervious 1000 blocks indicate they have
upgraded, as a safer alternative to a simple flag date, but I'm sure I
wouldn't have to point out that option to people here.
Aaron Voisine
co-founder and CEO
breadwallet.com
On Wed, May 13, 2015 at 5:58 PM, Pieter Wuille <pieter.wuille at gmail.com>
wrote:
> On Wed, May 13, 2015 at 5:48 PM, Aaron Voisine <voisine at gmail.com> wrote:
>
>> We have $3billion plus of value in this system to defend. The safe,
>> conservative course is to increase the block size. Miners already have an
>> incentive to find ways to encourage higher fees and we can help them with
>> standard recommended propagation rules and hybrid priority/fee transaction
>> selection for blocks that increases confirmation delays for low fee
>> transactions.
>>
>
> You may find that the most economical solution, but I can't understand how
> you can call it conservative.
>
> Suggesting a hard fork is betting the survival of the entire ecosystem on
> the bet that everyone will agree with and upgrade to new suggested software
> before a flag date.
>
> --
> Pieter
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150513/f4f8a27c/attachment.html>

2023-06-07 15:34:45

- reply

📅 Original date posted:2015-05-13
📝 Original message:> increasing the block size is simply not a solution, it's just kicking
> the can down the road (while reducing the incentives to deploy real
> solutions like payment channels).
Placing hard limits on blocksize is not the right solution. There are still
plenty of options to be explored to increase fees, resulting in users
voluntarily economizing on block space. It's premature to resort to
destroying the reliability of propagated transaction getting into blocks.
Child-pays-for-parent is useful, but requires the recipient to spend inputs
upon receipt, consuming even more block space. Replace-by-fee may also
help, but users won't know the fee they are getting charged until after the
fact, and it will make worse all the problems that tx malleability causes
today.
We have $3billion plus of value in this system to defend. The safe,
conservative course is to increase the block size. Miners already have an
incentive to find ways to encourage higher fees and we can help them with
standard recommended propagation rules and hybrid priority/fee transaction
selection for blocks that increases confirmation delays for low fee
transactions.
Aaron Voisine
co-founder and CEO
breadwallet.com
On Wed, May 13, 2015 at 5:11 PM, Jorge Timón <jtimon at jtimon.cc> wrote:
> On Mon, May 11, 2015 at 7:29 PM, Gavin Andresen <gavinandresen at gmail.com>
> wrote:
> > I think long-term the chain will not be secured purely by proof-of-work.
> I
> > think when the Bitcoin network was tiny running solely on people's home
> > computers proof-of-work was the right way to secure the chain, and the
> only
> > fair way to both secure the chain and distribute the coins.
> >
> > See https://gist.github.com/gavinandresen/630d4a6c24ac6144482a for some
> > half-baked thoughts along those lines. I don't think proof-of-work is the
> > last word in distributed consensus (I also don't think any alternatives
> are
> > anywhere near ready to deploy, but they might be in ten years).
>
> Or never, nobody knows at this point.
>
> > I also think it is premature to worry about what will happen in twenty or
> > thirty years when the block subsidy is insignificant. A lot will happen
> in
> > the next twenty years. I could spin a vision of what will secure the
> chain
> > in twenty years, but I'd put a low probability on that vision actually
> > turning out to be correct.
>
> I think is very healthy to worry about that since we know it's
> something that will happen.
> The system should work without subsidies.
>
> > That is why I keep saying Bitcoin is an experiment. But I also believe
> that
> > the incentives are correct, and there are a lot of very motivated, smart,
> > hard-working people who will make it work. When you're talking about
> trying
> > to predict what will happen decades from now, I think that is the best
> you
> > can (honestly) do.
>
> Lightning payment channels may be a new idea, but payment channels are
> not, and nobody is using them.
> They are the best solution to scalability we have right now,
> increasing the block size is simply not a solution, it's just kicking
> the can down the road (while reducing the incentives to deploy real
> solutions like payment channels).
>
> Not worrying about 10 years in the future but asking people to trust
> estimates and speculations about how everything will burn in 2 years
> if we don't act right now seems pretty arbitrary to me.
> One could just as well argue that there's smart hard-working people
> that will solve those problems before they hit us.
>
> It is true that the more distant the future you're trying to predict
> is, the more difficult it is to predict it, but any threshold that
> separates "relevant worries" from "too far in the future to worry
> about it" will always be arbitrary.
> Fortunately we don't need to all share the same time horizon for what
> is worrying and what is not.
> What we need is a clear criterion for what is acceptable for a
> hardfork and a general plan to deploy them:
>
> -Do all the hardfork changes need to be uncontroversial? How do we
> define uncontroversial?
> -Should we maintain and test implementation of hardfork whises that
> seem too small to justify a hardfork on their own (ie time travel fix,
> allowing to sign inputs values...) to also deploy them at the same
> time that other more necessary hardforks?
>
> I agree that hardforks shouldn't be impossible and in that sense I'm
> glad that you started the hardfork debate, but I believe we should be
> focusing on that debate rather than the block size one.
> Once we have a clear criteria, hopefully the block size debate should
> become less noisy and more productive.
>
>
> ------------------------------------------------------------------------------
> 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/20150513/ded3ba9b/attachment.html>

2023-06-07 15:34:32

- 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 15:34:11

- 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 15:34:08

- 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 15:33:59

- 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 15:33:58

- 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 15:33:05

- 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 15:31:56

- reply

📅 Original date posted:2015-03-16
📝 Original message:Thanks Jan, we added several additional checks for non-standard protocol
responses, and also made the client revert to DNS seeding more quickly if
it runs into trouble, so it's now more robust against sybil/DOS attack. I
mentioned in the coindesk article that I didn't think what your nodes were
doing was intended to be malicious with respect to network disruption. It's
our job to better handle non-standard or even malicious behavior from
random p2p nodes.
Aaron Voisine
co-founder and CEO
breadwallet.com
On Mon, Mar 16, 2015 at 1:44 AM, Jan Møller <jan.moller at gmail.com> wrote:
> What we were trying to achieve was determining the flow of funds between
> countries by figuring out which country a transaction originates from.
> To do that with a certain accuracy you need many nodes. We chose a class C
> IP range as we knew that bitcoin core and others only connect to one node
> in any class C IP range. We were not aware that breadwallet didn't follow
> this practice. Breadwallet risked getting tar-pitted, but that was not our
> intention and we are sorry about that.
>
> Our nodes DID respond with valid blocks and merkle-blocks and allowed
> everyone connecting to track the blockchain. We did however not relay
> transactions. The 'service' bit in the version message is not meant for
> telling whether or how the node relays transactions, it tells whether you
> can ask for block headers only or full blocks.
>
> Many implementations enforce non standard rules for handling transactions;
> some nodes ignore transactions with address reuse, some nodes happily
> forward double spends, and some nodes forward neither blocks not
> transactions. We did blocks but not transactions.
>
> In hindsight we should have done two things:
> 1. relay transactions
> 2. advertise address from 'foreign' nodes
>
> Both would have fixed the problems that breadwallet experienced. My
> understanding is that breadwallet now has the same 'class C' rule as
> bitcoind, which would also fix it.
>
> Getting back on the topic of this thread and whether it is illegal, your
> guess is as good as mine. I don't think it is illegal to log incoming
> connections and make statistical analysis on it. That would more or less
> incriminate anyone who runs a web-server and looks into the access log.
> At lease one Bitcoin service has been collecting IP addresses for years
> and given them to anyone visiting their web-site (you know who) and I
> believe that this practise is very wrong. We have no intention of giving IP
> addresses away to anyone, but we believe that you are free to make
> statistics on connection logs when nodes connect to you.
>
> On a side note: When you make many connections to the network you see lots
> of strange nodes and suspicious patterns. You can be certain that we were
> not the only ones connected to many nodes.
>
> My takeaway from this: If nodes that do not relay transactions is a
> problem then there is stuff to fix.
>
> /Jan
>
> On Fri, Mar 13, 2015 at 10:48 PM, Mike Hearn <mike at plan99.net> wrote:
>
>> That would be rather new and tricky legal territory.
>>
>> But even putting the legal issues to one side, there are definitional
>> issues.
>>
>> For instance if the Chainalysis nodes started following the protocol
>> specs better and became just regular nodes that happen to keep logs, would
>> that still be a violation? If so, what about blockchain.info? It'd be
>> shooting ourselves in the foot to try and forbid block explorers given how
>> useful they are.
>>
>> If someone non-maliciously runs some nodes with debug logging turned on,
>> and makes full system backups every night, and keeps those backups for
>> years, are they in violation of whatever pseudo-law is involved?
>>
>> I think it's a bit early to think about these things right now. Michael
>> Grønager and Jan Møller have been Bitcoin hackers for a long time. I'd be
>> interested to know their thoughts on all of this.
>>
>>
>> ------------------------------------------------------------------------------
>> 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
>>
>>
>
>
> ------------------------------------------------------------------------------
> 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/20150316/3bccccf3/attachment.html>

2023-06-07 15:31:39

- reply

📅 Original date posted:2015-03-12
📝 Original message:On Wed, Mar 11, 2015 at 10:12 PM, Thy Shizzle <thashiznets at yahoo.com.au>
wrote:
>
> BIP39 is beautiful.
meh... the fact that you can't derive the seed phrase from the wallet seed,
and that the password key stretching is so weak as to be ineffectual
security theater bugs me. Feels like a pretty big compromise to work on
current generation low power embedded devices when the next generation will
be more than capable. But I understand the motivation for the compromise.
Aaron Voisine
co-founder and CEO
breadwallet.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150311/1c12393a/attachment.html>

2023-06-07 15:31:27

- 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 15:31:13

- reply

📅 Original date posted:2015-02-22
📝 Original message:>> However, I don't think we should base
>> bitcoin around what Apple wants us to do. They've already had their war
>> on bitcoin. They are going to do whatever they can to protect their NFC
>> based payment system. We need to make their platform the the less
>> desirable one if they are going to play the game that way. If that means
>> an Airbitz like proposal is implemented as a fallback, maybe that is
>> fine and POS systems need to support both, but I just don't think we
>> should limit what we can do because of Apple's products capabilities.
>
> Ack on Airbitz, and ack on our relationship to Apple (-:
I also agree we shouldn't limit specs to Apple product capabilities. If
history is any indication, NFC will be opened up to developers in iOS 9,
just like touch id in was in iOS 8, and bluetooth LE in iOS 5, one major OS
revision after the hardware capability is first introduced.
Also, I'm pretty sure that Apple doesn't care about bitcoin at all. When
they banned wallets from the app store, it was prior to the 2013 FinCEN
guidance. At the time many of us, myself included, assumed USG would take
the same stance with bitcoin as they did against e-gold. It wasn't clear at
all that bitcoin didn't violate legal tender laws or who knows what. When
Apple allowed wallets back in, it was just weeks before Apple pay launched.
It's seems clear that bitcoin is too small for them to be concerned about
in the slightest.
Aaron Voisine
co-founder and CEO
breadwallet.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150222/4374ae80/attachment.html>

2023-06-07 15:28:59

- reply

📅 Original date posted:2015-01-21
📝 Original message:Ultimately the only way to insure bitcoin holdings is with an insurer
who themselves holds enough bitcoin to cover replacement of insured
funds. In the existing insurance industry, this is handled through a
system of re-insurance, where smaller firms are themselves insured
against catastrophic events that might cause a large number of
simultaneous claims. At the top of the chain sits super-cat insurance
firms like Berkshire Hathaway who do actually have the reserves to pay
out in case of such a super catastrophy. This is one of the most
lucrative businesses in the world, and one that today's very large
bitcoin holders will find themselves uniquely positioned to engage in
as bitcoin grows into a major global currency.
Aaron Voisine
breadwallet.com
On Tue, Jan 20, 2015 at 10:07 PM, 21E14 <21xe14 at gmail.com> wrote:
> This is a response to a wonderfully insightful recent post by Joichi Ito,
> the Director of the MIT Media Lab. In it, Dr. Ito, notably a former Board
> Member of ICANN, offered his thoughts on "Why Bitcoin is and isn't like the
> Internet" and asked a most pertinent question: "Whether there is an ICANN
> equivalent needed for Bitcoin." As suggested in recent posts to the mailing
> list, I believe there might be, but for a reason that may not seem obvious
> at first.
>
> Alan Reiner expressed the need this way: "I think one of the biggest issues
> facing Bitcoin right now is not the lack of a 'killer app.' It is lack of
> insurance options. Early adopters would like to believe that the majority of
> users will hold their own Bitcoin, but I believe that is not a realistic
> option when life-changing quantities of Bitcoin are involved. We should not
> trust Grandma to secure her own retirement savings via complicated computer
> maneuvers. More to the point, she should not trust herself or anyone else
> (sic!) to hold it unless there is a strong protection against loss events.
> Right now the solution is for Grandma to avoid keeping her money in Bitcoin.
> Bitcoin needs a strong backbone of insured storage options so that Grandma
> can confidently participate in this new technology." This is certainly an
> observation to take heed of coming from the founder of Armory Technologies.
>
> The protection against loss events ought to be understood in the broadest
> sense. What is needed is a disaster recovery mechanism. Andreas Antonopoulos
> remarks expressed this candidly last year: "Bitcoin doesn't have a middle of
> the road mediocre growth model. It basically either dies, because of a
> fundamental flaw in the Bitcoin system. Not an external factor, an internal
> factor: We blow it up by accident. And that could happen... Bitcoin will
> play out in the next three years. In the next three years we're going to see
> Bitcoin arrive on the global stage and make a substantial impact, both in
> financial terms and in political terms. It will happen. Or it will die.
> Either way. I'm not sure. In which case we'll reboot another currency."
>
> A body, not entirely unlike ICANN, can manage the nexus to the physical
> world, and help address Bitcoin's catastrophic failure modes. Bitcoin's coin
> ownership protocol would thus join the ranks of its payment protocol, coin
> issuance protocol, consensus mechanism and inflation control that pose no
> lethal threat to the ecosystem. In addition to their coin-agnostic nature, I
> suspect the high valuation of large Bitcoin hubs relative to Bitcoin's
> market cap at this stage in its lifecycle is partly reflective of the
> sneaking suspicion that a custodial bitcoin (a bitcoin attached to an
> identity) may be worth more than a non-custodial one. With this in mind,
> I'll pitch in for the ticket should Dr. Ito decide to join the next month's
> DevCore Boston conference aimed at supporting the future development of
> Bitcoin. It's an hour's walk from MIT after all.
>
> ------------------------------------------------------------------------------
> New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
> GigeNET is offering a free month of service with a new server in Ashburn.
> Choose from 2 high performing configs, both with 100TB of bandwidth.
> Higher redundancy.Lower latency.Increased capacity.Completely compliant.
> http://p.sf.net/sfu/gigenet
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

2023-06-07 15:26:22

- reply

📅 Original date posted:2014-10-12
📝 Original message:This is great Pieter. I was able to sync the entire blockchain from
scratch in a little over 4 hours on a laptop over cable modem. :) No
issues to report. Even my family photos are intact! This makes it
practical to run a full node, part time on a laptop again.
Aaron Voisine
breadwallet.com
On Sat, Oct 11, 2014 at 4:34 PM, Pieter Wuille <pieter.wuille at gmail.com> wrote:
> Hi all,
>
> I believe that a large change that I've been working on for Bitcoin
> Core is ready for review and testing: headers-first synchronization.
> In short, it changes the way the best chain is discovered, downloaded
> and verified, with several advantages:
> * Parallel block downloading (much faster sync on typical network connections).
> * No more stalled downloads.
> * Much more robust against unresponsive or slow peers.
> * Removes a class of DoS attacks related to peers feeding you
> low-difficulty valid large blocks on a side branch.
> * Reduces the need for checkpoints in the code.
> * No orphan blocks stored in memory anymore (reducing memory usage during sync).
> * A major step step towards an SPV mode using the reference codebase.
>
> Historically, this mode of operation has been known for years (Greg
> Maxwell wrote up a description of a very similar method in
> https://en.bitcoin.it/wiki/User:Gmaxwell/Reverse_header-fetching_sync
> in early 2012, but it was known before that), but it took a long time
> to refactor these code enough to support it.
>
> Technically, it works by replacing the single-peer blocks download by
> a single-peer headers download (which typically takes seconds/minutes)
> and verification, and simultaneously fetching blocks along the best
> known headers chain from all peers that are known to have the relevant
> blocks. Downloading is constrained to a moving window to avoid
> unbounded unordering of blocks on disk (which would interfere with
> pruning later).
>
> At the protocol level, it increases the minimally supported version
> for peers to 31800 (corresponding to bitcoin v3.18, released in
> december 2010), as earlier versions did not support the getheaders P2P
> message.
>
> So, the code is available as a github pull request
> (https://github.com/bitcoin/bitcoin/pull/4468), or packaged on
> http://bitcoin.sipa.be/builds/headersfirst, where you can also find
> binaries to test with.
>
> Known issues:
> * At the very start of the sync, especially before all headers are
> processed, downloading is very slow due to a limited number of blocks
> that are requested per peer simultaneously. The policies around this
> will need some experimentation can certainly be improved.
> * Blocks will be stored on disk out of order (in the order they are
> received, really), which makes it incompatible with some tools or
> other programs. Reindexing using earlier versions will also not work
> anymore as a result of this.
> * The block index database will now hold headers for which no block is
> stored on disk, which earlier versions won't support. If you are fully
> synced, it may still be possible to go back to an earlier version.
>
> Unknown issues:
> * Who knows, maybe it will replace your familiy pictures with Nyan
> Cat? Use at your own risk.
>
> TL;DR: Review/test https://github.com/bitcoin/bitcoin/pull/4468 or
> http://bitcoin.sipa.be/builds/headersfirst.
>
> --
> Pieter
>
> ------------------------------------------------------------------------------
> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
> http://p.sf.net/sfu/Zoho
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

2023-06-07 15:25:58

- reply

📅 Original date posted:2014-09-25
📝 Original message:Of course you wouldn't want nodes to propagate alerts without
independently verifying them, otherwise anyone could just issue alerts
for every new transaction.
Aaron Voisine
breadwallet.com
On Thu, Sep 25, 2014 at 7:16 PM, Matt Whitlock <bip at mattwhitlock.name> wrote:
> Probably the first double-spend attempt (i.e., the second transaction to spend the same output(s) as another tx already in the mempool) would still need to be relayed. A simple "double-spend alert" wouldn't work because it could be forged. But after there have been two attempts to spend the same output, no further transactions spending that same output should be relayed, in order to prevent flooding the network.
>
>
> On Thursday, 25 September 2014, at 7:12 pm, Aaron Voisine wrote:
>> Something like that would be a great help for SPV clients that can't
>> detect double spends on their own. (still limited of course to sybil
>> attack concerns)
>>
>> Aaron Voisine
>> breadwallet.com
>>
>>
>> On Thu, Sep 25, 2014 at 7:07 PM, Matt Whitlock <bip at mattwhitlock.name> wrote:
>> > What's to stop an attacker from broadcasting millions of spends of the same output(s) and overwhelming nodes with slower connections? Might it be a better strategy not to relay the actual transactions (after the first) but rather only propagate (once) some kind of double-spend alert?
>> >
>> >
>> > On Thursday, 25 September 2014, at 7:02 pm, Aaron Voisine wrote:
>> >> There was some discussion of having nodes relay double-spends in order
>> >> to alert the network about double spend attempts.
>> >>
>> >> A lot more users will be using SPV wallets in the future, and one of
>> >> the techniques SPV clients use to judge how likely a transaction is to
>> >> be confirmed is if it propagates across the network. I wonder if and
>> >> when double-spend relaying is introduced, if nodes should also send
>> >> BIP61 reject messages or something along those lines to indicate which
>> >> transactions those nodes believe to be invalid, but are relaying
>> >> anyway.
>> >>
>> >> This would be subject to sybil attacks, as is monitoring propagation,
>> >> however it does still increase the cost of performing a 0 confirmation
>> >> double spend attack on an SPV client above just relaying double-spends
>> >> without indicating if a node believes the transaction to be valid.
>> >>
>> >> Aaron Voisine
>> >> breadwallet.com
>> >

2023-06-07 15:25:58

- reply

📅 Original date posted:2014-09-25
📝 Original message:Something like that would be a great help for SPV clients that can't
detect double spends on their own. (still limited of course to sybil
attack concerns)
Aaron Voisine
breadwallet.com
On Thu, Sep 25, 2014 at 7:07 PM, Matt Whitlock <bip at mattwhitlock.name> wrote:
> What's to stop an attacker from broadcasting millions of spends of the same output(s) and overwhelming nodes with slower connections? Might it be a better strategy not to relay the actual transactions (after the first) but rather only propagate (once) some kind of double-spend alert?
>
>
> On Thursday, 25 September 2014, at 7:02 pm, Aaron Voisine wrote:
>> There was some discussion of having nodes relay double-spends in order
>> to alert the network about double spend attempts.
>>
>> A lot more users will be using SPV wallets in the future, and one of
>> the techniques SPV clients use to judge how likely a transaction is to
>> be confirmed is if it propagates across the network. I wonder if and
>> when double-spend relaying is introduced, if nodes should also send
>> BIP61 reject messages or something along those lines to indicate which
>> transactions those nodes believe to be invalid, but are relaying
>> anyway.
>>
>> This would be subject to sybil attacks, as is monitoring propagation,
>> however it does still increase the cost of performing a 0 confirmation
>> double spend attack on an SPV client above just relaying double-spends
>> without indicating if a node believes the transaction to be valid.
>>
>> Aaron Voisine
>> breadwallet.com
>

2023-06-07 15:25:57

- reply

📅 Original date posted:2014-09-25
📝 Original message:There was some discussion of having nodes relay double-spends in order
to alert the network about double spend attempts.
A lot more users will be using SPV wallets in the future, and one of
the techniques SPV clients use to judge how likely a transaction is to
be confirmed is if it propagates across the network. I wonder if and
when double-spend relaying is introduced, if nodes should also send
BIP61 reject messages or something along those lines to indicate which
transactions those nodes believe to be invalid, but are relaying
anyway.
This would be subject to sybil attacks, as is monitoring propagation,
however it does still increase the cost of performing a 0 confirmation
double spend attack on an SPV client above just relaying double-spends
without indicating if a node believes the transaction to be valid.
Aaron Voisine
breadwallet.com

2023-06-07 15:25:42

- 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 15:24:24

- 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 15:24:23

- 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 15:24:22

- reply

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

2023-06-07 15:24:22

- reply

📅 Original date posted:2014-07-24
📝 Original message:The upcoming release of breadwallet uses the height of the blockchain to
enforce timed pin code lockouts for preventing an attacker from
quickly making multiple pin guesses. This prevents them changing the
devices system time to get around the lockout period.
Aaron
On Thursday, July 24, 2014, Ron OHara <ron.ohara54 at gmail.com> wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> I thought I should shortcut my research by asking a direct question here.
>
> As I understand it, the blockchain actually provides an extra piece of
> reliable data that is not being exploited by applications.
>
> Which data? The time. In this case 'the time' as agreed by >50% of
> the participants, where those participants have a strong financial
> incentive to keep that 'time' fairly accurate. (+/- about 10 minutes)
>
> Is this a reasonable understanding of 'time'? ... aka timestamps on the
> block
>
> Ok... 'time' on the blockchain could be 'gamed' ... but with great
> difficulty. An application presented with a fake blockchain can use
> quite a few heuristics to test the 'validity' of the block chain.
> It can review the usual cryptographic proofs, and check that difficulty
> is growing/declining only in a realistic manner up to the most recent
> block. Even use some arbitrary test like difficulty > 10,000,000,000
> ... on the presumption that any less means that the Bitcoin system has
> failed massively from where it currently is and has become an unreliable
> time source.
>
> Reliable 'time' has been impossible up until now - because you need to
> trust the time source, and that can always be faked. Using the
> blockchain as an approximate time source gives you a world wide
> consensus without direct trust of any player.
>
> So if this presumption is correct, then we can now build time capsule
> applications that can not be tricked into exposing their contents too
> early by running them in a virtual environment with the wrong system time.
>
> Is this right? or did miss I something fundamental?
>
> Ron
>
> - --
> public identify: https://www.onename.io/ron_ohara
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.20 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQEcBAEBAgAGBQJT0a9sAAoJEAla1VT1+xc2ONQH/0R09guSNNCxP36KziAjfcBc
> JEhxMpIlqTTYEvNXaBmuPy4BN+IZQ9izgrW/cvlEJJNMmc5/VIBk83WZltmDwcKl
> oo4MIdmp6vz984GWToyyLcLSEDT60UE9Hhe+U9RyF5J9kwbN8Uy4ozUHhFVP/0EL
> q4O1V6ggPbHWgH4q8m8E9qWOlIFXCDgCjxpL8Ptxsk+UlBq2NWMiwTz6Tbc9KOB4
> hOffzXCZV+DkwjFZD2Rc4rHaxw1yLuYr7DzmzwZbhRQclv9tZt9hoVaAT+RQpE1k
> X7pi+zVzeMMng0bzUv8t/G+gq0gaelyV41MJQRparEXhnuYkgU7rAPKIQEG8qpc=
> =T5fw
> -----END PGP SIGNATURE-----
>
>
>
> ------------------------------------------------------------------------------
> 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:;>
> 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/20140724/aa8aca93/attachment.html>

2023-06-07 15:24:16

- reply

📅 Original date posted:2014-07-19
📝 Original message:Thanks g.maxwell, your explanation of *why* you can't just generate k
in a way that the verifier can duplicate is really helpful. This also
servers as a great illustration why engineers should never try to
designing their own crypto protocols! I knew enough to know not try
that at least.
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 15:24:15

- 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 15:24:15

- 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 15:24:14

- 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 15:23:54

- 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 15:23:51

- 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 15:23:42

- reply

📅 Original date posted:2014-07-13
📝 Original message:I believe tx have to be ordered sequentially within a block. Also
since a tx is referenced by it's hash, it's practically impossible to
make a self referential tx.
Aaron Voisine
breadwallet.com
On Sun, Jul 13, 2014 at 4:32 PM, Richard Moore <me at ricmoo.com> wrote:
> Hey all,
>
> I'm working on the UTXO database for my Python implementation of bitcoind
> and have found a situation I did not realize was valid, but since it seems
> to be, had a quick question.
>
> If you look at block #546 the 4th transaction's first input uses its own
> block's 3rd transaction as an input.
> https://blockchain.info/block/000000005a4ded781e667e06ceefafb71410b511fe0d5adc3e5a27ecbec34ae6
>
> My question is, would the other way be valid, that is, could the 3rd
> transaction of a block, use the 4th transaction from the same block as an
> input? Or are transactions processed strictly top to bottom?
>
> Thanks,
> RicMoo
>
> P.S. If it is valid, another question; what would happen if a transaction
> was self-referencing? I realize it would be very difficult to find one, but
> if I could find a transaction X whose input was X and had an output Y, would
> Y be a new valid utxo, without being a generation transaction input?
>
> .·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸><(((º>
>
> Richard Moore ~ Founder
> Genetic Mistakes Software inc.
> phone: (778) 882-6125
> email: ricmoo at geneticmistakes.com
> www: http://GeneticMistakes.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 15:23:36

- 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 15:23:28

- reply

📅 Original date posted:2014-07-08
📝 Original message:I wrote down a really short description in code comments for
breadwallet, based on what I figured out:
https://github.com/voisine/breadwallet/blob/master/BreadWallet/BRPeer.m#L318
Aaron Voisine
breadwallet.com
On Tue, Jul 8, 2014 at 1:04 PM, Matt Whitlock <bip at mattwhitlock.name> wrote:
> Is anyone working on a similar specification document for Satoshi's P2P protocol? I know how blocks and transactions are structured and verified, but I'm interested in knowing how they're communicated over the network.
>
> ------------------------------------------------------------------------------
> 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 15:22:30

- reply

📅 Original date posted:2014-06-06
📝 Original message:I'll implement it in breadwallet (oss SPV wallet, hopefully about to
be in the app store) if other wallet authors are planning to.
Aaron
https://github.com/voisine/breadwallet
There's no trick to being a humorist when you have the whole
government working for you -- Will Rodgers
On Fri, Jun 6, 2014 at 12:00 PM, Jeff Garzik <jgarzik at bitpay.com> wrote:
> We are considering pulling in https://github.com/bitcoin/bitcoin/pull/2340
> "Discourage fee sniping with nLockTime"
>
> Comments from other wallet implementors in particular are welcomed.
>
> --
> Jeff Garzik
> Bitcoin core developer and open source evangelist
> BitPay, Inc. https://bitpay.com/
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/NeoTech
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

2023-06-07 15:20:50

- reply

📅 Original date posted:2014-05-02
📝 Original message:At the moment BIP70 specifically requires that a request be rejected
if validation fails, so that should be fixed that sooner rather than
later:
"The recipient must verify the certificate chain according to
[RFC5280] and reject the PaymentRequest if any validation failure
occurs."
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 8:39 AM, Mike Hearn <mike at plan99.net> wrote:
> A bunch of different people either have implemented or are implementing
> BIP70 at the moment. Here's a bunch of things I've been telling people in
> response to questions. At some point I'll submit a pull req with this stuff
> in but for now it's just an email.
>
> Error handling during signature checking
>
> I've had queries around the right behaviour here. BIP 70 is underspecified
> and we should fix it IMO. If PKI checking fails you should just treat the
> request as if it's unsigned. The reason is that there is no incentive for an
> attacker to break the signature instead of just removing it entirely, so an
> attacker would never trigger any error flows you put in. However, someone
> who is signing their request with an unknown CA or using an upgraded version
> of the protocol that isn't entirely backwards compatible could trigger
> signature checking failure.
>
> Therefore, in order to make introducing new (possibly community run) CA's or
> new variations on signing possible, please treat any errors as if there was
> no signature at all. This is not what browsers do, but browsers have an
> advantage - they were already given an identity and told to expect a secure
> protocol when the user typed in the web address with an https:// prefix (or
> clicked a link). Unfortunately a Bitcoin wallet has no context like this.
>
> One person asked me whether this makes the whole scheme pointless because a
> MITM can just delete the signature. The answer is no - downgrade attacks are
> always possible on systems that start out insecure. The solution is to train
> users to expect the upgrade and refuse to go ahead if it's not there.
> Training users to expect signed payment requests will be a big task similar
> to the way the browser industry trained users to look for the padlock when
> typing in credit card details, but it must be done.
>
> Because wallets lack context there's no equivalent to HSTS for us either. So
> in your GUI's try to train the user - when showing a signed payment request,
> tell them to expect the recipient name to appear in future and that they
> should not proceed if it doesn't. This gives us a kind of mental HSTS.
>
> Extended validation certs
>
> When a business is accepting payment, showing the name of the business is
> usually better than showing just the domain name, for a few reasons:
>
> Unless your domain name is your business name like blockchain.info, it looks
> better and gives more info.
>
> Domain names are more phishable than EV names, e.g. is the right name
> bitpay.com or bit-pay.com or bitpay.co.uk?
>
> More important: Someone who hacks your web server or DNS provider can
> silently get themselves a domain name SSL cert issued, probably without you
> noticing. Certificate transparency will eventually fix that but it's years
> away from full deployment. It's much harder for a hacker to get a bogus EV
> cert issued to them because there's a lot more checking involved.
>
> EV certs still have the domain name in the CN field, but they also have the
> business name in the OU field.
>
> In theory we are supposed to have extra code to check that a certificate
> really was subject to extended validation before showing the contents of
> this field. In practice either bitcoinj nor Bitcoin Core actually do, they
> just always trust it. It'd be nice to fix that in future.
>
> You should show the organisation data instead of the domain name if you find
> it, for EV certs.
>
> pki=none
>
> Signing is optional in BIP 70 for good reasons. One implementor told me they
> were considering rejecting unsigned payment requests. Do not do this! A MITM
> can easily rewrite the bitcoin URI to look as if BIP70 isn't in use at all.
>
> Even though today most (all?) payment requests you'll encounter are signed,
> it's important that signing is optional because in future we need individual
> people to start generating payment requests too, and many of them won't have
> any kind of memorisable digital identity. Plus other people just won't want
> to do it. BIP70 is about lots of features, signing is only one.
>
> S/MIME certs
>
> Email address certs look a bit different to SSL certs. You can get one for
> free from here
>
> https://comodo.com/home/email-security/free-email-certificate.php
>
> In these certs the display name can be found in the Subject Alternative Name
> field with a type code of 1. Example code:
>
>
> https://github.com/bitcoinj/bitcoinj/commit/feecc8f48641cd02cafc42150abba4e4841ea33d
>
> You won't encounter many of these today except on Gavin's test site, but in
> future people may wish to start creating and signing their own payment
> requests for individual purposes using these certs (especially as they are
> free). So please try to handle them correctly.
>
> Broadcast vs upload
>
> Please upload transactions and commit them to your wallet when the server
> responds with 200 OK, but expect the merchant to broadcast them. Don't give
> the user an option to pick - it's pointless as there's no obvious right
> answer.
>
> Testing
>
> You can find a test site here:
>
> http://bitcoincore.org/~gavin/createpaymentrequest.php
>
> It's testnet only. For testing regular payment requests on the main network,
> I use BitPay as they were the first seller-side implementation:
>
> http://bitgivefoundation.org/donate-now/
>
> Memo contents
>
> Please put something useful here, ideally what is actually being sold but
> failing that, the name of the merchant if you're a payment processor. Don't
> be like BitPay and put large random numbers in the memo field but nothing
> about what's actually purchased.
>
> This is not particularly important today except for cosmetic reasons,
> because wallets don't store the payment requests they saw to disk. But in
> future they will and then a properly signed memo field + the transactions
> used for payment give us a digital receipt. Receipts are useful for things
> like filing expense reports, proving a purchase when returning an item to a
> merchant, etc.
>
> Expiry times
>
> Don't be too aggressive with these. Although today it doesn't matter much,
> some users may be trying to pay from multi-party accounts that require
> multiple humans to coordinate to make a payment.
>
>
>
>
>
>
> ------------------------------------------------------------------------------
> "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 15:20:47

- 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 15:20:40

- reply

📅 Original date posted:2014-05-04
📝 Original message:Bit by bit, it's become clear that it's a bit much to worry even a
little bit that overloading the word "bit" would be every bit as bad
as a two bit horse with the bit between it's teeth that bit the hand
that feeds it, or a drill bit broken to bits after just a bit of use.
Aaron
There's no trick to being a humorist when you have the whole
government working for you -- Will Rodgers
On Sat, May 3, 2014 at 10:18 PM, Drak <drak at zikula.org> wrote:
> +1
>
> On 4 May 2014 02:06, "Chris Pacia" <ctpacia at gmail.com> wrote:
>>
>> Absent a concerted effort to move to something else other than 'bits', I
>> would be willing to bet the nomenclature moves in that direction anyway.
>> 'Bits' is just a shorten word for 'millibits' (or microbits, if you
>> will). It's easier to say and my guess is people would tend to use it
>> naturally own their own. Kind of like 'bucks' for dollars.
>>
>> The other synergies are:
>> -bit is part of the word Bitcoin. The currency unit bit is part of a
>> whole bitcoin.
>> -bit symbolically represents the tech nature of the bitcoin.
>> -bit used to be a unit of money way back when. This largely reclaims it.
>> -when used as money bit when in references to a precession metal coin.
>> The name 'bitcoin' references that as well as the mimicking of the gold
>> standard in the protocol rules.
>>
>> All around I don't think there is a better fit. I doubt people will get
>> confused by it. The context it's used in will distinguish it from other
>> uses of the word.
>>
>> On 05/03/2014 12:27 PM, Mike Caldwell wrote:
>> > I agree with the sentiment that most people don't understand either
>> > computer science or Bitcoin. The goal of getting people to understand
>> > enough about Bitcoin to use it is achievable and a goal that is "in scope"
>> > of our efforts. Getting them to understand computer science at large at the
>> > same time, less so.
>> >
>> > The fact that people routinely confuse RAM and hard drive sizes has much
>> > to do with the fact that the average lay person has little need to
>> > prioritize this as something to keep in the forefront. They don't get
>> > "horribly" confused, they just simply don't get worked up over what looks to
>> > them like a rounding error, much to the dismay of anyone who believes that
>> > everyone should be an expert at computer science. The average joe may
>> > assess (accurately from his perspective) that the distinction isn't
>> > important enough to merit significant mental resources and he is justified
>> > in not expending them that way even if someone else thinks he should.
>> >
>> > Poor understanding is precisely what a proper effort to name this would
>> > be to avoid. It is not frill or aesthetics, it is a planned targeting of
>> > language to achieve the clearest communication to the widest possible target
>> > audience using the language most likely to be understood by them in light of
>> > our objectives. It's marketing.
>> >
>> > Mike
>> >
>> > Sent from my iPhone
>> >
>> >> On May 3, 2014, at 9:49 AM, "Christophe Biocca"
>> >> <christophe.biocca at gmail.com> wrote:
>> >>
>> >> Context as a disambiguator works fine when the interlocutors
>> >> understand the topics they're talking about.
>> >> Not a day goes by without me seeing "neurotypical people" get horribly
>> >> confused between RAM and Hard Drive sizes, because they share the same
>> >> units (not that that can be helped, as the units are supposed to be
>> >> the same, base 1000 vs 1024 notwithstanding).
>> >>
>> >> Bit (as a unit) is already really confusing for anyone who doesn't
>> >> deal with it on a regular basis. I think people who don't see an issue
>> >> are making an assumption based on their own lack of confusion. We
>> >> understand computer science AND Bitcoin. Most people have zero
>> >> understanding of either.
>> >>
>> >> Bitcoin already has a ton of issues with terrible names for things:
>> >>
>> >> - Mining (for transaction validation).
>> >> - Addresses (which are meant to be one-time use, and don't even really
>> >> exist at the network level).
>> >> - Wallets (which don't hold your bitcoins, can be copied, and all
>> >> backups can be stolen from equally).
>> >>
>> >> I end up having to make the distinctions obvious every time I explain
>> >> Bitcoin to someone new to it. There's an acceptable tradeoff here,
>> >> because there were arguably no better words to assign to these
>> >> concepts (although I'd argue mining is a really awful metaphor, and is
>> >> the one that prompts the most questions from people). Then add to the
>> >> pile a bunch of third parties naming themselves after parts of the
>> >> protocol (Coinbase,Blockchain.info). Not blaming them for it, but I've
>> >> definitiely seen average people get confused between "the blockchain"
>> >> and "blockchain.info" (not so much Coinbase, because that name doesn't
>> >> come up in beginner explanations).
>> >>
>> >> It seems downright masochistic to add
>> >> yet-another-word-that-doesn't-mean-what-you-think-it-means to the pile
>> >> for no reason other than aesthetics. Are we actively trying to confuse
>> >> people?
>> >
>> > ------------------------------------------------------------------------------
>> > "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
>
>
> ------------------------------------------------------------------------------
> "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 15:20:35

- 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 15:20:35

- 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

2023-06-07 15:20:05

- reply

📅 Original date posted:2014-04-25
📝 Original message:On github I commented on the BIP43 pull request about adding a
"purpose" of 0' which would correspond to the BIP32 recommended tree
structure for a single account wallet. (m/0'/chain) This will allow
for backwards compatibility and interoperability at least for existing
single account BIP32 implementations like my own. The only issue is
that it would involve a new BIP, and it wouldn't follow the BIP43
recommendation of using the BIP number as the "purpose number", unless
I can get BIP0. :)
Aaron
There's no trick to being a humorist when you have the whole
government working for you -- Will Rodgers
On Fri, Apr 25, 2014 at 8:49 AM, Mike Hearn <mike at plan99.net> wrote:
> I generally agree, but I wonder how popular cloning wallets between devices
> will be in future. Right now if someone wants to have a wallet shared
> between Hive, blockchain.info and Bitcoin Wallet for Android, we just tell
> them they're out of luck and they need to pick one, or split their funds up
> manually.
>
> But probably a lot of people would like to use different UI's to access the
> same wallets. Sharing key trees is a part of that, though full blown wallet
> metadata sync would also be needed.
>
> So I guess we're going to end up with some kind of fairly complex
> compatibility matrix. But I agree it may be unavoidable.
>
> ------------------------------------------------------------------------------
> Start Your Social Network Today - Download eXo Platform
> Build your Enterprise Intranet with eXo Platform Software
> Java Based Open Source Intranet - Social, Extensible, Cloud Ready
> Get Started Now And Turn Your Intranet Into A Collaboration Platform
> http://p.sf.net/sfu/ExoPlatform
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>