Nostr notes by James MacWhyte [ARCHIVE]

📅 Original date posted:2022-07-11 📝 Original message:On ...

2023-06-07T23:11:44Z

In reply to nevent1q…tpgw
_________________________

📅 Original date posted:2022-07-11
📝 Original message:On Tue, Jul 12, 2022 at 12:26 AM Peter Todd <pete at petertodd.org> wrote:

> Anyway, designing protocols for "price go up forever" hopium is a bad idea.
>

I'm quite disappointed that this is what you've reduced my argument to. The
price doesn't need hopium; if it stays between where it is now and the all
time high, that is enough to make mining rewards appealing.

Anyway, once the LA dinner rush ends at 8PM it is already noon in Tokyo.
The Pacific is big, but not *that* big.

Certainly we should be designing protocols in anticipation of increased
adoption, and not assuming the world will always be exactly as it is today?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220712/05d46411/attachment.html>;

📅 Original date posted:2022-07-11 📝 Original message:I ...

2023-06-07T23:11:44Z

In reply to nevent1q…z5t8
_________________________

📅 Original date posted:2022-07-11
📝 Original message:I think many of these discussions about the loss of the mining reward are
fatally shortsighted.

It's always daytime somewhere--when you talk about volume dropping at
night, that simply means there is not enough activity outside the US. If
Bitcoin continues its rise in price, mining rewards will still be
substantial for decades to come. Given another 10 years, I'm fairly
confident there will be enough adoption worldwide to make mining profitable
around the clock, even if the mining reward were minimal.

James

On Mon, Jul 11, 2022 at 8:19 PM Bram Cohen via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> If transaction fees came in at an even rate over time all at the exact
> same level then they work fine for security, acting similarly to fixed
> block rewards. Unfortunately that isn't how it works in the real world.
> There's a very well established day/night cycle with fees going to zero
> overnight and even longer gaps on weekends and holidays. If in the future
> Bitcoin is entirely dependent on fees for security (scheduled very
> strongly) and this pattern keeps up (overwhelmingly likely) then this is
> going to become a serious problem.
>
> What's likely to happen is that at first there will simply be no or very
> few blocks mined overnight. There are likely to be some, as miners at first
> turn off their mining rigs completely overnight then adopt the more
> sophisticated strategy of waiting until there are enough fees in the
> mempool to warrant attempting to make a block and only then doing it.
> Unfortunately the gaming doesn't end there. Eventually the miners with
> lower costs of operation will figure out that they can collectively reorg
> the last hour (or some time period) of the day overnight and this will be
> profitable. That's likely to cause the miners with more expensive
> operations to stop attempting mining the last hour of the day preemptively.
>
> What happens after that I'm not sure. There are a small enough number of
> miners with a quirky enough distribution of costs of operation and
> profitability that the dynamic is heavily dependent on those specifics, but
> the beginnings of a slippery slope to a mining cabal which reorgs everyone
> else out of existence and eventually 51% attacks the whole thing have
> begun. It even gets worse than that because once there's a cabal
> aggressively reorging anyone else out when they make a block other miners
> will shut down and rapidly lose the ability to quickly spin up again, so
> the threshold needed for that 51% attack will keep going down.
>
> In short, relying completely on transaction fees for security is likely to
> be a disaster. What we can say from existing experience is that having
> transaction fees be about 10% of rewards on average works well. It's enough
> to incentivize collecting fees but not so much that it makes incentives get
> all weird. 90% transaction fees is probably very bad. 50% works but runs
> the risk of spikes getting too high.
>
> There are a few possible approaches to fixes. One would be to drag most of
> east asia eastward to a later time zone thus smoothing out the day/night
> cycle but that's probably unrealistic. Another would be to hard fork in
> fixed rewards in perpetuity, which is slightly less unrealistic but still
> extremely problematic.
>
> Much more actionable are measures which smooth out fees over time. Having
> wallets opportunistically collect their dust during times of low
> transaction fees would help and would save users on fees. Also making UX
> which clarifies when things are likely to take a day or week but that it's
> reliable would be a reasonable thing to do, but users unfortunately are
> very averse to transactions taking a while.
> _______________________________________________
> 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/20220712/4828c452/attachment-0001.html>;

📅 Original date posted:2022-07-08 📝 Original message:> ...

2023-06-07T23:11:17Z

In reply to nevent1q…7d2z
_________________________

📅 Original date posted:2022-07-08
📝 Original message:> What do you do if the "first" word (of 12), happens to be the last word in
> the list alphabetically?
>

That couldn't happen. If one word is the very last from the wordlist, it
would end up at the end of your mnemonic once you rearrange your 12 words
alphabetically.

However!

(@vjudeu) Choosing 11 random words and then sorting them alphabetically
before assigning a checksum would reduce entropy considerably. If you think
about it, to bruteforce the entire keyspace one would only need to come up
with every possible combination of 11 words + 1 checksum. I'm not the best
at napkin math, but I think that leaves you with around 10 trillion
combinations, which would only take a couple months to exhaust with
hardware that can do 1 million guesses per second.

James
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220708/fa49a159/attachment.html>;

📅 Original date posted:2022-07-09 📝 Original ...

2023-06-07T23:11:17Z

In reply to nevent1q…7mup
_________________________

📅 Original date posted:2022-07-09
📝 Original message:Thanks, Zac!

I indeed did get the napkin math very wrong. I now get around 10^30 total
possible phrases, which would take an impossibly long time to brute force.
So, it is less entropy but probably still sufficient for low-stakes usage.

James

On Sat, Jul 9, 2022 at 10:31 PM Zac Greenwood <zachgrw at gmail.com> wrote:

> Sorting a seed alphabetically reduces entropy by ~29 bits.
>
> A 12-word seed has (12, 12) permutations or 479 million, which is ln(469m)
> / ln(2) ~= 29 bits of entropy. Sorting removes this entropy entirely,
> reducing the seed entropy from 128 to 99 bits.
>
> Zac
>
>
> On Fri, 8 Jul 2022 at 16:09, James MacWhyte via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>>
>> What do you do if the "first" word (of 12), happens to be the last word
>>> in the list alphabetically?
>>>
>>
>> That couldn't happen. If one word is the very last from the wordlist, it
>> would end up at the end of your mnemonic once you rearrange your 12 words
>> alphabetically.
>>
>> However!
>>
>> (@vjudeu) Choosing 11 random words and then sorting them alphabetically
>> before assigning a checksum would reduce entropy considerably. If you think
>> about it, to bruteforce the entire keyspace one would only need to come up
>> with every possible combination of 11 words + 1 checksum. I'm not the best
>> at napkin math, but I think that leaves you with around 10 trillion
>> combinations, which would only take a couple months to exhaust with
>> hardware that can do 1 million guesses per second.
>>
>>
>> James
>> _______________________________________________
>> 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/20220710/26e276d1/attachment-0001.html>;

📅 Original date posted:2021-07-26 📝 Original message:Hi ...

2023-06-07T22:57:10Z

In reply to nevent1q…3ezw
_________________________

📅 Original date posted:2021-07-26
📝 Original message:Hi Billy!

See above, but to break down that situation a bit further, these are the
> two situations I can think of:
>
> 1. The opcode limits user/group A to send the output to user/group B
> 2. The opcode limits user A to send from one address they own to
> another address they own.
>
> I'm trying to think of a good use case for this type of opcode. In these
examples, an attacker who compromises the key for user A can't steal the
money because it can only be sent to user B. So if the attacker wants to
steal the funds, they would need to compromise the keys of both user A and
user B.

But how is that any better than a 2-of-2 multisig? Isn't the end result
exactly the same?

James
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210726/688c8adb/attachment.html>;

📅 Original date posted:2021-06-11 📝 Original message:@Billy ...

2023-06-07T22:54:38Z

In reply to nevent1q…av3f
_________________________

📅 Original date posted:2021-06-11
📝 Original message:@Billy I like the idea. It is very obvious how useful an opcode like this
would be! (My background is in wallet implementation)

@Russell I do understand your concerns of monotonism, however I'm having a
hard time really coming up with an attack vector. You said "one can design
a wallet to passively take advantage of reorgs by always spending through
an OP_BBV that is on the verge of becoming invalid." Unless I'm mistaken,
this means you would need to send yourself a fresh transaction using OP_BBV
set to, say, 2 blocks in the future, then immediately spend that output in
a new payment to someone else and hope a reorg happens. Does this mean the
theoretical double-spend wallet you are proposing would have to send two
transactions every time you make a single payment, doubling the transaction
fees and adding more uncertainty around when the second transaction would
get confirmed?

In a normal double spend scenario, there is no cost to a failed attempt,
but much to gain from a success. With your design, there is a real cost to
every single attempt (transaction fees) and no evidence that the rate of
success would be higher (you still have to bet on the reorg not including
your transaction in the first few blocks). It sounds like this new system
would actually be less attractive to double spenders than the current model!

I also agree with Billy's idea for relay rules. We already have abusable
chain rules (e.g. a tx can be included in a block with 0 transaction fee
[spam?]) but we add protection with relay rules (e.g. minimum fee to
relay). I don't see how this would be any different, if the chain rules
only enforced the block height for confirmation and the relay rules forced
a minimum OP_BBV value in order to protect against reorg double spends.

James

On Fri, Jun 11, 2021 at 11:00 AM Billy Tetrud via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> > one can design a wallet to passively take advantage of reorgs
>
> It does sound like this is the central issue. I can certainly see that
> it's materially different than current double spending ability. Double
> spending via reorgs today requires either active participation and
> above-average connection to miners or luck.
>
> The easiest method of double spending I can think of is the following.
> Consider if a user broadcasts an RBF transaction as soon as the original
> transaction is mined. I assume the transaction won't propagate through the
> network because any node that has received the newest block will see it as
> an invalid transaction, is that right? Is there no significant possibility
> that enough of the network hasn't seen the block yet to transmit the RBF
> transaction widely enough to get incorporated into a reorg? This would
> certainly be something wallets could do automatically. It certainly does
> seem like at very least this would have a much lower success rate than your
> auto-double-spend wallet.
>
> In any case, what if we apply the same logic to non-monotonic
> transactions? What if we program nodes to reject such transactions that are
> too close to the borderline? For example, if nodes rejected transactions
> that could expire within 100 blocks, it would be much less likely for this
> kind of thing to be done at point of sale, and there would be a much higher
> chance that whatever recipient that's willing to wait 100 blocks would be
> willing to wait 6 blocks more to be sure no reorg happens. It would also be
> a lot more likely that the transaction is confirmed well before it might
> expire. Not a perfect solution, to be sure. But it could substantially
> limit the cases and likelihoods that passive double-spend attempts would
> succeed. But miners could still get and include transactions in blocks
> regardless of this, and they have an incentive to (to maximize the fees
> they collect). It at least seems plausible that those incentives would
> undermine this solution.
>
> But it seems like all this is only a problem for people who are
> considering 1 confirmation to be effectively finalized. Users and
> programmatic systems alike simply wait for some condition to be true to
> recognize payment as having completed. Systems could simply be programmed
> so the condition is at least 6 confirmations for any non-monotonic
> transaction, or all transactions. 6 confirmations is the accepted standard
> of finalization, isn't it? Users looking at their software should be able
> to see that a confirmation has happened but that this isn't enough to be
> considered finalized. As long as this is standard, no problem should really
> exist, right? Except within incorrectly written software or people taking
> it upon themselves to define finalization on their own. People who accept
> 0-conf transactions are similarly using a non-standard definition of
> finalization and are putting themselves at even greater risk for double
> spends. How would this be any different?
>
> > there is little point in addressing these lesser concerns if the main
> concern is outstanding
>
> I agree, it makes the most sense to discuss the above points rather than
> getting into the weeds about more minor issues.
>
> On Thu, Jun 10, 2021 at 4:20 PM Russell O'Connor <roconnor at blockstream.com>
> wrote:
>
>> As it stands today, in order to double spend a transaction during a
>> reorg, one must take an active role of recognizing that a reorg has
>> happened, hope that the new branch has completely omitted your spending
>> transaction, and then quickly broadcast a replacement transaction with a
>> higher fee to outbid your previous transaction.
>>
>> However with, pretty much any change to Bitcoin that leads to
>> non-monotonic validity rules, that is any rule where transactions that are
>> valid at one tip, can become invalid at a latter tip through some other
>> means than their inputs being spent, such as OP_BBV, one can design a
>> wallet to passively take advantage of reorgs by always spending through an
>> OP_BBV that is on the verge of becoming invalid. Then you just have to sit
>> back and wait for a suitable reorg to take back your UTXO for you without
>> any work. I would probably attempt to build such a wallet for myself
>> should any OP_BBV-like proposal be implemented. Think of it as an
>> auto-double spend wallet.
>>
>> Some people hold the opinion that there is no meaningful distinction
>> between the active and passive roles in these two scenarios. I'm not
>> convinced. I see a material difference between needing to actively
>> broadcast a replacement transaction and passively waiting for your
>> transaction to fall out of validity. I also see a material difference
>> between needing the transaction to be completely omitted from the reorging
>> chain versus just having the transaction fail a height qualification in the
>> reorging chain.
>>
>> (There are a few other lesser problems with an OP_BBV proposal, including
>> the fact that Bitcoin software tends to cache script validity so you'd want
>> to use the taproot annex instead of pure script; and a possible issue that
>> the proposal defeats limits on transaction replacement because now instead
>> of meeting minimum thresholds for fee bumping you can just let the previous
>> transaction expire and bump the fee by a fraction (though you are
>> effectively rate limited so maybe that is considered sufficiently
>> mitigated?). But there is little point in addressing these lesser concerns
>> if the main concern is outstanding.)
>>
>> On Thu, Jun 10, 2021 at 6:20 PM Billy Tetrud <billy.tetrud at gmail.com>
>> wrote:
>>
>>> @Russell In that thread, you quoted Satoshi there, but neither he nor
>>> you really deeply explained the concern. Would you mind elaborating on a
>>> situation that calls for concern here? Some deeper explanation of the
>>> "reorg safety" property would also be helpful. I'd very much like to know
>>> what your thoughts are on the specific points I brought up in the BIP as
>>> well.
>>>
>>> On Thu, Jun 10, 2021 at 11:35 AM Russell O'Connor <
>>> roconnor at blockstream.com> wrote:
>>>
>>>> This is a continuation of the thread at
>>>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-April/018760.html
>>>> on this topic.
>>>>
>>>> I still remain unconvinced that we ought to give up on the "reorg
>>>> safety" property that is explicitly part of Bitcoin's design.
>>>>
>>>> On Thu, Jun 10, 2021 at 1:56 PM Billy Tetrud via bitcoin-dev <
>>>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>>
>>>>> Hi Everyone,
>>>>>
>>>>> I'd like to open a discussion of an opcode I call OP_BEFOREBLOCKVERIFY
>>>>> (OP_BBV) which is similar to ones that have been discussed before (eg
>>>>> OP_BLOCKNUMBER). The opcode is very simple: the it takes as a
>>>>> parameter a number representing a block height, and marks the transaction
>>>>> invalid if the current block the transaction is being evaluated for is
>>>>> greater than or equal to that block height, the transaction is invalid. I
>>>>> wrote up a bip for OP_BBV here
>>>>> <https://github.com/fresheneesz/bip-efficient-bitcoin-vaults/blob/main/bbv/bip-beforeblockverify.md>;
>>>>> .
>>>>>
>>>>> The motivation for this opcode is primarily to do switch-off kinds of
>>>>> transactions. Eg, an output that contains both a spend path that uses
>>>>> OP_BBV and a spend path that uses OP_CHECKSEQUENCEVERIFY so that before a
>>>>> particular block one person can spend, and after that block a different
>>>>> person can spend. This can allow doing things like expiring payments or
>>>>> reversible payments in a cheaper way. Currently, things like that require a
>>>>> sequence of multiple transactions, however OP_BBV can do it in a single
>>>>> transaction, making these applications a lot more economically feasible.
>>>>>
>>>>> The particular application I'm most interested in is more efficient
>>>>> wallet vaults. However, wallet vaults requires other new opcodes, and I've
>>>>> been given the (good, I think) advice to start off this discussion with
>>>>> something a bit more bite sized and manageable. So I want to keep this
>>>>> discussion to OP_BBV and steer away from the specifics of the wallet vaults
>>>>> I'm thinking of (which are more involved, requiring other new opcodes that
>>>>> I think makes more sense to discuss in a different thread).
>>>>>
>>>>> The main thing I'd like to discuss is the historical avoidance of and
>>>>> stigma toward opcodes that can cause a valid transaction to become invalid.
>>>>>
>>>>> It seems there are two concerns:
>>>>>
>>>>> 1. that an opcode like might create a DOS vector where a malicious
>>>>> actor might be able to spam the mempool with transactions containing this
>>>>> opcode.
>>>>> 2. that an opcode like this could cause "bad" reorg behavior, where in
>>>>> a reorg, transactions that were spent become not spend and not spendable
>>>>> because they were mined too near their expiry point.
>>>>>
>>>>> While I don't want to claim anything about opcodes that can cause
>>>>> spend paths to expire in general, I do want to claim that *some* opcodes
>>>>> like that are safe - in particular OP_BBV. In the context of OP_BBV
>>>>> specifically, it seems to me like item 1 (mempool handling) is a solvable
>>>>> problem and that point 2 (reorg issues) is not really a problem since
>>>>> people should generally be waiting for 6 confirmations and software can
>>>>> warn the user to wait for 6 confirmations in relevant scenarios where a
>>>>> 6-block reorg might reverse the transaction. I discuss this in detail in
>>>>> the Design Tradeoffs and Risks
>>>>> <https://github.com/fresheneesz/bip-efficient-bitcoin-vaults/blob/main/bbv/bip-beforeblockverify.md#transaction-expiry>; section
>>>>> of the document I wrote for OP_BBV. I'd love to hear thoughts from others
>>>>> on here about these things and especially the discussion of these issues in
>>>>> the document I linked to.
>>>>>
>>>>> Thanks,
>>>>> BT
>>>>>
>>>>> _______________________________________________
>>>>> 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/20210611/65d0b138/attachment-0001.html>;

📅 Original date posted:2021-06-15 📝 Original message:@Lloyd ...

2023-06-07T22:54:15Z

In reply to nevent1q…k5ju
_________________________

📅 Original date posted:2021-06-15
📝 Original message:@Lloyd wrote:

Of course in reality no one wants to keep their coin holding keys online so
> in Alogorand you can authorize a set of "participation keys"[1] that will
> be used to create blocks on your coin holding key's behalf.
> Hopefully you've spotted the problem.
> You can send your participation keys to any malicious party with a nice
> website (see random example [2]) offering you a good return.
> Damn it's still Proof-of-SquareSpace!
>

I believe we are talking about a comparison to PoW, correct? If you want to
mine PoW, you need to buy expensive hardware and configure it to work, and
wait a long time to get any return by solo mining. Or you can join a mining
pool, which might use your hashing power for nefarious purposes. Or you
might skip the hardware all together and fall for some "cloud mining"
scheme with a pretty website and a high rate of advertised return. So as
you can see, Proof-of-SquareSpace exists in PoW as well!

The PoS equivalent of buying mining hardware is setting up your own
validator and not outsourcing that to anyone else. So both PoW and PoS have
the professional/expert way of participating, and the fraud-prone, amateur
way of participating. The only difference is, with PoS the
professional/expert way is accessible to anyone with a raspberry Pi and a
web connection, which is a much lower barrier to entry than PoW.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210615/b25a4a2e/attachment.html>;

📅 Original date posted:2019-03-05 📝 Original message:On ...

2023-06-07T18:16:39Z

In reply to nevent1q…0nqd
_________________________

📅 Original date posted:2019-03-05
📝 Original message:On Tue, Mar 5, 2019 at 4:39 PM Trey Del Bonis via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> Keeping 20 around is a little excessive but it gives 390700800 possible
> wallets. So security can be trivially parameterized based on how secure you
> want your wallet to be if someone finds your stash.
>

Mid-level hardware can check 50k addresses per second, which means it would
only take around 2 hours to check all possibilities. So please don't think
this presents any kind of challenge to someone who finds your 20 pieces of
paper and assumes you would only keep them if they are hiding your wallet ;)

Entropy-wise, simply using a strong RNG would provide a better result than
relying on the printing company. Maybe they only print 35 different
combinations and assume people don't eat Chinese food enough to notice?

If it's poor entropy and doesn't really provide any protection against
being brute forced if found, I'm not sure why you would want to go
this route :)

James
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190305/e39b7baf/attachment.html>;

📅 Original date posted:2019-02-07 📝 Original message:Oooh, ...

2023-06-07T18:16:19Z

In reply to nevent1q…es4s
_________________________

📅 Original date posted:2019-02-07
📝 Original message:Oooh, that's cool. I didn't realize Ian's support for cards looks so slick
now!

Thanks for the image.

James

On Wed, Feb 6, 2019 at 7:55 AM Alan Evans via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> Image didn't seem to attach:
> [image: image.png]
>
> On Wed, 6 Feb 2019 at 09:48, Alan Evans <thealanevans at gmail.com> wrote:
>
>> It's not quite enough to just do SHA512, you missed out this condition
>> (incredibly rare as it is):
>>
>> > In case IL is 0 or ≥n, the master key is invalid.
>>
>> Also I can't see how I would use this to seed a hardware wallet that
>> requires a BIP39 seed as mentioned in your abstract.
>>
>> For both of those reasons, you may want to just invent/formalize a scheme
>> that takes Cards -> Entropy.
>> From that Entropy one can generate BIP39, and non-BIP39 fans can just
>> continue, generate and store their root xprv.
>>
>> Prior art: Note that Ian Coleman's BIP39 site already supports Cards (and
>> Dice), see the logic here:
>> https://github.com/iancoleman/bip39/blob/master/src/js/entropy.js
>>
>> [image: image.png]
>>
>> Note it detected "full deck". It also calculates the Total Bits of
>> Entropy and can handle card replacement and multiple decks.
>>
>> PS, you're a bit out on your entropy calculation, log2(52!) ~= 225.58
>> bits, not 219.
>>
>>
>> On Tue, 5 Feb 2019 at 02:08, Devrandom via bitcoin-dev <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>>> I would suggest 50+ 6-sided dice rolls, giving about 128 bits of
>>> entropy. Compared to a shuffle, it's easier to be sure that you got the
>>> right amount of entropy, even if the dice are somewhat biased.
>>>
>>>
>>> On Mon, Feb 4, 2019 at 2:33 PM James MacWhyte via bitcoin-dev <
>>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>
>>>>
>>>> James
>>>>
>>>>
>>>> On Sun, Feb 3, 2019 at 10:27 AM Ryan Havar via bitcoin-dev <
>>>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>>
>>>>> Conveniently a shuffled deck of cards also can serve as a physical
>>>>> backup which is easy to hide in plain sight with great plausible
>>>>> deniability.
>>>>>
>>>>
>>>> To make sure someone doesn't play with your cards and mix up the order,
>>>> use a permanent marker to draw a diagonal line on the side of the deck from
>>>> corner to corner. If the cards ever get mixed up, you can put them back in
>>>> order by making sure the diagonal line matches up.
>>>> _______________________________________________
>>>> 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/20190206/8923303d/attachment-0001.html>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 176797 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190206/8923303d/attachment-0001.png>;

📅 Original date posted:2019-02-04 📝 Original message:James ...

2023-06-07T18:16:18Z

In reply to nevent1q…rr57
_________________________

📅 Original date posted:2019-02-04
📝 Original message:James

On Sun, Feb 3, 2019 at 10:27 AM Ryan Havar via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> Conveniently a shuffled deck of cards also can serve as a physical backup
> which is easy to hide in plain sight with great plausible deniability.
>

To make sure someone doesn't play with your cards and mix up the order, use
a permanent marker to draw a diagonal line on the side of the deck from
corner to corner. If the cards ever get mixed up, you can put them back in
order by making sure the diagonal line matches up.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190204/67e4ffe2/attachment.html>;

📅 Original date posted:2019-01-30 📝 Original message:On ...

2023-06-07T18:16:06Z

In reply to nevent1q…sp0d
_________________________

📅 Original date posted:2019-01-30
📝 Original message:On Tue, Jan 29, 2019 at 6:46 PM <rhavar at protonmail.com> wrote:

>
> If the sender refuses to sign the final transaction, the receiver just
> propagates the template transaction which pays the receiver! So it's a
> pretty weak attack.
>
> The only real attack is that the sender could double-spend the
> template-transaction before it's propagated, but the cost of doing this
> isn't free, as at the very least you need to pay the transaction fees of
> creating a double spend. It's not an amazingly good defence, but it's good
> enough that it's unlikely to get abused (and an attacker would only learn a
> single utxo of the receiver) .
>

Okay, I see what you mean. I better understand the weaknesses you've
identified, and I can't really think of a better solution than what you've
proposed. I also realized that implementors who aren't capable of
integrating signing and UTXO validation wouldn't be the ones trying to
implement this feature, so my concerns there are also moot. Carry on ;)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190130/f26a6e84/attachment.html>;

📅 Original date posted:2019-01-30 📝 Original message:James ...

2023-06-07T18:16:05Z

In reply to nevent1q…tx0n
_________________________

📅 Original date posted:2019-01-30
📝 Original message:James

On Sun, Jan 27, 2019 at 2:11 PM <rhavar at protonmail.com> wrote:

>
> It isn't passed "back and forth so many times".
>

You are right, I got the wrong impression the first time I read it.

> This is an important anti-DoS/anti-spy tactic, as it proves the sender
> actually owns those inputs and if the protocol is not followed to
> completion, the transaction can be dumped on the network.
>

I'm not convinced this is a valid concern, at least not valid enough to add
extra complications to the process. The sender could still refuse to sign
the final transaction after they see the recipient's in-/outputs; "show me
yours and I'll show you mine" isn't much of a spy deterrent, and nothing
here prevents a DOS attack.

As an implementor, I would suggest keeping the protocol as simple as
possible. By dropping the signing in the first step, the recipient doesn't
need to maintain the ability to lookup and verify unspent outputs. It also
would enforce the increased privacy, which the sender obviously wants if
they are going down this path (in other words, either have the process
complete or fail -- don't give the recipient the ability to broadcast the
not-private transaction against the wishes of the sender).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190129/e3d08376/attachment.html>;

📅 Original date posted:2019-01-27 📝 Original message:Why ...

2023-06-07T18:16:04Z

In reply to nevent1q…6p09
_________________________

📅 Original date posted:2019-01-27
📝 Original message:Why does the template transaction need to be signed in step one and passed
back and forth so many times? What is wrong with:

1. Sender creates unsigned tx with their relevant inputs and outputs. This
tx is passed to receiver.

2. Receiver adds their relevant inputs and outputs and signs their portion
before returning the tx to sender.

3. Sender confirms their inputs and outputs have not been modified, and
signs the remainder of the tx before broadcasting it (or sending it to the
recipient if you want to follow the payment protocol spec).

James

On Sun, Jan 27, 2019, 08:45 Adam Gibson via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org wrote:

>
>
> On 27. 01. 19 8:36, rhavar at protonmail.com wrote:
> > Thanks Adam,
> >
> > I have fixed the mistakes you have pointed out:
> https://github.com/bitcoin/bips/pull/754
> >
> > Thanks for the detailed look!
> >
> >> but its virtue of steganographic hiding means only minimal uptake
> >> is still enormously interesting and worth pursuing; that's my current
> feeling.
> >
> > I very much agree =) I really think anything that (silently) breaks the
> assumption of common ownership of transaction inputs offers outsized
> benefits for the whole ecosystem.
> >
> > One other idea I have is (way) better support for moving utxo's between
> wallets. The least controversial use case is moving funds between wallets
> you own. Like I might want to move *specific* utxo's from/to my joinmarket
> wallet, but not create a (privacy losing / expensive) transaction. Both
> core and joinmarket fail at this at a practical point of view.
>
> (tangential, but yes coin control in JM is an obviously necessary
> feature and will be done, I just don't have time).
>
> >
> > Like imho it'd be pretty cool having a standardized format for
> (txid:vout:privatekey) with wallets showing it as "External UTXO" and
> preferentially spending it (and wallet not automatically importing any
> other utxo from that address).
> >
> > Taken a bit further (this is the part which everyone hates) you could
> send someone money (or withdraw it from a service) by giving a person. It's
> not generally useful (for obvious reasons), but there's a lot of cases I
> think it's super cool.
>
> Is there a missing word. "by giving a person.."? Not actually sure what
> you're getting at here but I suspect it's again tangential to this BIP
> discussion.
>
> >
> > ---
> >
> > Getting back on topic, without trying to do a point-by-point reply, I
> agree with pretty much everything you said but I am reluctant to make any
> changes.
> >
> > I don't meant to be obtuse or anything, but I strongly believe the
> limiting factor to adoption to all these protocols is actually just getting
> people to implement it. I made multiple implementations of bustapay from
> both the sending/receiving end, so I could try develop the easiest to
> implement system that is still practical.
>
> You know, there's considerable evidence to the contrary, I'd argue: this
> idea *has* been implemented already three times: by yourself, by myself
> and by Samourai. And in fully incompatible ways :) So I think the
> limiting factor is in fact creating a standard that a reasonable number
> of people could agree with (and I like operational definitions, so
> subjective as it is, I like the goal of "good/clear enough that it could
> be incorporated into something like BtcPayServer")
>
> >
> > For instance I like PSBT and it's nice in theory. I actually had an
> original implementation using it, which is how I found some bugs in the
> core and golang version of PSBT). But in practice it's hugely overkill and
> significantly increases the implementation complexity complexity and is
> poorly supported. Switching to just a raw transaction actually made
> everything easier. (And that's not to criticise PSBT, I would definitely
> want to use it in other contexts).
>
> But this relates back to my first "generic" point that you haven't
> addressed here - protocol versioning and the possibility of more than
> one option. Perhaps more realistic (debatable): have the current version
> be non-PSBT but with a plan to have a version bump with PSBT in future.
> Stuff like that. It seems crazy to actually long term reject it.
>
> >
> > Anyway, a big motivation for me even writing it as a BIP was to
> formalize my little anti-DOS trick of privately creating a "template
> transaction" which can just be dumped on the network as punishment. So if
> nothing else, hopefully I'll have demonstrated it's a pretty practical way
> of doing things.
> >
>
> I don't want to be that guy, but this was a central part of the proposal
> that came of the meetup last summer and is in Haywood's blogpost. I mean
> if you came up it with separately, then cool :) But I was there, that
> was established immediately as the right way of doing this to avoid a
> trivial attack.
> What might have confused you is all that stuff about multiple candidates
> and even ZKP approaches - those were just extra ideas about making it
> really secure at large scale; but those ideas don't quite meet the goal
> (for various reasons); well, arguably. The basic anti-DOS of an initial
> non-coinjoin was sorta central.
> (Also I'm noting you didn't respond to my critique of your "always use
> the same contributions" defence; I mean, probably that's fine, it was
> only really saying it isn't perfect. Was just curious to hear
> your/others thoughts on it).
>
> > --
> >
> > Also your analysis on "Unnecessary Input Heuristic" is pretty cool, but
> I also don't like telling people to "avoid the UIH2" without providing the
> actual algo they should use. But really I think it's better off in a sort
> of article "how to pick contributed inputs" or something, as while it's
> nice it's not a huge deal and there's a lot of debatable tradeoffs that
> can/should be used. For instance the implementation I wrote for
> bustabit.com currently just heavily biases tainted inputs (e.g. ones
> associated with address reuse).
> >
>
> Good point about algo.
> I wrote my best effort at a procedure here:
>
> https://gist.github.com/AdamISZ/4551b947789d3216bacfcb7af25e029e#gistcomment-2799709
>
> I asked for comments on it but got none back so far (gists are terrible
> for this unfortunately, perhaps I'll have more luck on the list).
>
> I would argue that this issue *should* be mentioned on the BIP. A *huge*
> part of what makes PayJoin/BustaPay of interest is the steganographic
> feature, if you don't pay attention to this then it doesn't look like a
> payment (caveat.-->).
> The counterargument is Laurent's statistics which I previously linked,
> suggesting that maybe 30% of txs violate this anyway, today. I'm not
> sure about that, will need more analysis; Core's SRD algo may be one
> reason, but anyway ... better to make things look like payments.
>
> It doesn't hurt to prompt an implementer to do this; whether it's
> feasible in that specific wallet situation or not is up to them; whether
> they want to go hog wild and control percentages of UIH1 and UIH2 and
> whatnot is there business, or they can totally ignore it - but without
> it being mentioned in the BIP, they may not even think of it.
>
> A last point, you also don't see value in being more explicit about
> simple things like transaction version and locktime? Even if you think
> these things should *not* be controlled, e.g. the protocol should allow
> either transaction version, then it'd be better to explicitly say so.
> >
> >
> > -Ryan
> >
> > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> > On Friday, January 25, 2019 6:47 AM, Adam Gibson via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
> >
> >> Ryan and list,
> >> I want to add some commentary to this (BIP79) to see if we can get
> >> further in standardizing this idea.
> >>
> >> When I first mulled it over I thought it too impractical, but its virtue
> >> of steganographic hiding means only minimal uptake is still enormously
> >> interesting and worth pursuing; that's my current feeling. I've offered
> >> more detailed thoughts in my blog post[1] (def not required reading
> here).
> >>
> >> Both Joinmarket and Samourai have started implementing this kind of
> >> transaction. And while that's interesting experimentally, some kind of
> >> cross-wallet standard would be helpful, albeit there some differences
> >> between that and the merchant/centralized service use-case.
> >>
> >> We might imagine as a concrete goal for this BIP to create something
> >> that would be acceptable for inclusion into a project like BTCPayServer,
> >> so that it could be used in a realistic use case by smaller bitcoin
> >> accepting merchants.
> >>
> >> Comments to the BIP[2] as follows, with generic comments first, and then
> >> specific comments for existing points in the BIP:
> >>
> >> [1] https://joinmarket.me/blog/blog/payjoin
> >> [2] https://github.com/bitcoin/bips/blob/master/bip-0079.mediawiki
> >>
> >> Generic comments
> >>
> >>
> ==================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================
> >>
> >> - Protocol versioning. Since inevitably (even if only merchants), this
> >> must be implemented by multiple wallets to be useful, the
> communication
> >> protocol will need versioning (for example i have in my
> >> simple/experimental Joinmarket PayJoin that sender sends min and max
> >> supported version and receiver responds with a chosen protocol
> version
> >> so we can update). I do understand that as a client-server model can
> >> apply here, we can ditch a lot of the complexities around
> network/p2p
> >> interaction, but this much at least seems necessary.
> >>
> >> - Although it has its logic, I don't think "Bustapay" is a good name
> for
> >> this protocol. I prefer "PayJoin" which is neutral sounding and
> >> self-descriptive. Needless to say this is not a hill I intend to
> die on.
> >>
> >> - PSBT/BIP174. I realise this has already been discussed, but this is
> a
> >> good example of what this standardisation was designed for, so I'd
> be
> >> against not including it, even given the reality that, as you
> correctly
> >> observe, it is not yet implemented in the majority of wallets and
> >> libraries. One way round that is to make it optional (possibly
> combined
> >> with above point about versioning). Note that for example you were
> >> observing the necessity to check the sequence number was unchanged;
> that
> >> would be encapsulated by checking equality of PSBT Input
> objects/fields.
> >> While one can make such software architecture arguments, the really
> >> fundamental point is the need for standards for x-wallet
> compatibility.
> >>
> >> - Version, Locktime: Perhaps this is not needed; in a peer to peer
> >> wallet scenario I think there might be logic in trying to get cover
> >> traffic of (Core, Electrum, others), say, by using
> >> last-block-locktime-mostly, as they do. Version should be 2 and
> sequence
> >> is a function of your suggestion to use BIP125. Worth noting that
> BIP125
> >> is not currently widely used on the network, though (see
> >> https://p2sh.info/dashboard/db/replace-by-fee?orgId=1). For this
> reason
> >> it should perhaps be explicitly only optional.
> >>
> >> - Avoidance of non-payment "Unnecessary Input Heuristic" (1, 2). For
> >> reference, see the definition here
> >>
> https://gist.github.com/AdamISZ/4551b947789d3216bacfcb7af25e029e#gistcomment-2796539
> >> and some data here
> >>
> https://gist.github.com/AdamISZ/4551b947789d3216bacfcb7af25e029e#gistcomment-2800791
> >> (whole comment thread may be of interest) - note this UIH name is
> afaik
> >> Chris Belcher's invention, it seems useful as a categorisation.
> >> So, it seems that UIH2 is more important to avoid; while some more
> >> sophisticated wallet coin selection algorithms may occasionally pick
> >> an input set where one input is larger than any output, most won't,
> and
> >> some in particular never will. So I think the text here should
> indicate
> >> that *the receiver's contributed input(s) SHOULD be chosen to avoid
> >> triggering the UIH2 heuristic where possible, so that the final
> payjoin
> >> transaction is maximally plausible as an ordinary payment" or
> similar.
> >> UIH1 is a nice-to-have (meaning the plausibility extends to two
> >> different (both wrong) payment amounts, but it may not be necessary
> to
> >> mention it in the BIP.
> >>
> >> Specific comments
> >> =================
> >>
> >>
> >>>> ====Step 4. Receiver validates, re-signs, and propagates on the
> >>
> >> bitcoin network====
> >>
> >> I believe this should say "Sender" not Receiver. Also for the next
> >> sentence, s/receiver/sender/:
> >>
> >>>> The receiver MUST validate the ''partial transaction'' was changed
> >>
> >> correctly and non-maliciously (to allow using potentially untrusted
> >> communication channels), re-sign its original inputs and propagate the
> >> final transaction over the bitcoin network.
> >>
> >> Your very correct highlighting of the attack vector of "receiver gives
> >> sender other inputs belonging to sender to unwittingly sign (described
> >> below), should be highlighted here, perhaps with the phrase "re-sign its
> >> ORIGINAL inputs" (only!)".
> >>
> >>>> When the sender is creating a "template transaction" it is done
> >>
> >> almost identically to creating a normal send, with the exception that
> >> only segwit inputs may be used. The sender is also encouraged to use a
> >> slightly more aggressive feerate than usual as well as BIP125 (Opt-in
> >> Full Replace-by-Fee Signaling), but neither is strictly required.
> >>
> >> "slightly more aggressive feerate than usual" - this I understand is to
> >> make up for receiver contributed utxo, OK.
> >>
> >> "only segwit inputs" - it certainly makes things simpler. One can work
> >> with non-segwit inputs but especially considering (as mentioned below)
> >> we really ought to "MUST" the part about matching input types, I tend to
> >> agree that non-segwit should be disallowed.
> >>
> >>>> The receiver must add at least one input to the transaction (the
> >>
> >> "contributed inputs"). If the receiver has no inputs, it should use a
> >> 500 internal server error, so the client can send the transaction as per
> >> normal (or try again later).
> >>
> >> Would it not be much simpler for the server to return a different
> >> (non-error) response indicating that it will broadcast the template tx
> >> in this case?
> >>
> >>>> Its generally advised to only add a single contributed input, however
> >>
> >> they are circumstances where adding more than a single input can be
> useful.
> >>
> >> I don't see a good reason to advise the use of only 1 input? (but this
> >> will also connect with the above generic comment about "UIH"). I guess
> >> it's because of your approach to fees. I'd prefer not to create a
> >> limitation here.
> >>
> >>>> To prevent an attack where a receiver is continually sent variations
> >>
> >> of the same transaction to enumerate the receivers utxo set, it is
> >> essential that the receiver always returns the same contributed inputs
> >> when it's seen the same inputs.
> >>
> >> This is an approach to avoiding this problem which has the virtue of
> >> simplicity, but it seems a little problematic. (1) You must keep a
> >> mapping of proposed payment utxos to one's proposed contributed input
> >> utxos, but (2) how should this be updated if you need to spend the
> >> contribution mentioned in (1)? Ironically use of payjoin exacerbates
> >> this issue, because it results in a smaller number of utxos being held
> >> by the receiver at any one time :) All this considered, I still see the
> >> value in your approach, but it might end up with a re-attempted payment
> >> being rejected. Certainly the more complex suggested solutions coming
> >> out of the summer 2018 coinjoin workshop aren't as practical as this,
> >> and may be overkill for small merchants/receivers.
> >>
> >>>> It is strongly preferable that the receiver makes an effort to pick a
> >>
> >> contributed input of the same type as the other transaction inputs if
> >> possible.
> >>
> >> I have also thought about this and you could reasonably argue this
> >> should be a MUST section in the BIP, that is, if the receiver cannot use
> >> inputs of the same type, he should fall back to the template
> >> transaction. A mixed-input payjoin/coinjoin is essentially
> >> near-perfectly identifiable as such (there is almost zero other usage of
> >> multi-type-input transactions), which is a very different thing than a
> >> non-identifiable payjoin transaction. That may or may not be OK to the
> >> sender. This is debatable though, for sure.
> >>
> >>>> After adding inputs to the transaction, the receiver generally will
> >>
> >> want to adjust the output that pays himself by increasing it by the sum
> >> of the contributed input amounts (minus any fees he wants to
> >> contribute). However the only strict requirement is that the receiver
> >> must never add or remove inputs, and must not ever decrease any
> >> output amount.
> >>
> >> "must never add or remove inputs" - did you mean "must never remove
> >> inputs"? he surely has to add one! Or, perhaps you mean he must not
> >> alter the list of inputs provided by the sender (in which case it should
> >> be clarified).
> >>
> >> "must not decrease any output amount" - I initally disagreed with this
> >> but it is a better option than the one I currently chose in Joinmarket
> >> payjoin (sender pays all fee as long as receiver utxos are not too
> >> much). So this means that the receiver either consciously chooses to not
> >> increase the fee, meaning the fee rate may be a bit low (hence your
> >> earlier comment about being generous, got it), or contributes via the
> >> payout amount. I guess the latter might break merchant software
> >> expecting to have amount output fixed and fees determined by change.
> >>
> >> Regards,
> >> Adam Gibson/waxwing
> >>
> >> On 30. 08. 18 22:24, Ryan Havar via bitcoin-dev wrote:
> >>
> >>> I've just finished writing an implementing of this, and extremely happy
> >>> with how it turned out. So I'd like to go and try go down the path of
> >>> more formally describing it and getting some comments and ultimately
> >>> encourage its wide-spread use.
> >>> ==Abstract==
> >>> The way bitcoin transactions are overwhelming used is known to leak
> more
> >>> information than desirable. This has lead to fungibility concerns in
> bitcoin
> >>> and a raise of unreasonably effective blockchain analysis.
> >>> Bustapay proposes a simple, practical way to bust these assumptions to
> >>> immediate
> >>> benefit of the sender and recievers. Furthermore it does so in such a
> >>> way that
> >>> helps recievers avoid utxo bloat, a constant problem for bitcoin
> merchants.
> >>> ==Copyright==
> >>> This BIP is in the public domain.
> >>> ==Motivation==
> >>> One of the most powerful heuristic's employed by those whose goal is to
> >>> undermine
> >>> bitcoin's fungiblity has been to assume all inputs of a transaction are
> >>> signed by
> >>> a single party. In the few cases this assumption does not hold, it is
> >>> generally
> >>> readibly recognizable (e.g. traditional coinjoins have a very obvious
> >>> structure,
> >>> or multisig outputs are most frequently validated onchain).
> >>> Bustapay requires no changes to bitcoin and creates bitcoin
> transactions
> >>> that are
> >>> indistinguishable from normal ones.
> >>> It is worth noting that this specification has been intentionally kept
> >>> as simple
> >>> as possible to encourage adoption. There are almost an endless amount
> of
> >>> extensions
> >>> possible but the harder the implementation of clients/server the less
> >>> likely it
> >>> will ever be done. Should bustapay enjoy widespread adoption, a "v2"
> >>> specification
> >>> will be created with desired extensions.
> >>> ==Specification==
> >>> A bustapay payment is made from a sender to a receiver.
> >>> Step 1. Sender creates a bitcoin transaction paying the receiver
> >>> This transaction must be fully valid, signed and all inputs must use
> >>> segwit. This transaction is known as the "template transaction". This
> >>> transaction must not be propagated on the bitcoin network.
> >>> Step 2. Sender gives the "template transaction" to the receiver
> >>> This would generally be done as an HTTP POST. The exact URL to submit
> it
> >>> to could be specified with a bip21 encoded address. Such as
> >>> bitcoin:2NABbUr9yeRCp1oUCtVmgJF8HGRCo3ifpTT?bustapay=
> https://bp.bustabit.com/submit
> >>> and the HTTP body should be the raw transaction hex encoded as text.
> >>> Step 3. Receiver processes the transaction and returns a partially
> >>> signed coinjoin
> >>> The receiver validates the transaction is valid, pays himself and is
> >>> eligible for propation. The receiver then adds one of his own inputs
> >>> (known as the "contributed input") and increase the output that pays
> >>> himself by the contributed input amount. Doing so will invalidate the
> >>> "template transaction"'s original input signatures, so the sender needs
> >>> to return this "partial transaction" back to the receiver to sign. This
> >>> is returned as a hex-encoded raw transaction a response to the original
> >>> HTTP POST request.
> >>> Step 4. Receiver validates, re-signs, and propagates on the bitcoin
> network
> >>> The receiver is responsible in making sure the "partial transaction"
> >>> returned by the sender was changed correctly (it should assume the
> >>> connection has been MITM'd and act accordingly), resign its original
> >>> inputs and propagates this transaction over the bitcoin network. The
> >>> client must be aware that the server can reorder inputs and outputs.
> >>> Step 5. Receiver observes the finalized transaction on the bitcoin
> network
> >>> Once the receiver has seen the finalized transactions on the network
> >>> (and has enough confirmations) it can process it like a normal payment
> >>> for the sent amount (as opposed to the amount that it looks like on the
> >>> network). If the receiver does not see the finalized transaction after
> a
> >>> timeout will propagate the original "template transaction" to ensure
> the
> >>> payment happens and function a strong anti-DoS mechanism.
> >>> === Implementation Notes ===
> >>> For anyone wanting to implement bustapay payments, here are some notes
> >>> for receivers:
> >>>
> >>> - A transaction can easily be checked if it's suitable for the
> mempool
> >>> with testmempoolaccept in bitcoin core 0.17
> >>>
> >>> - Tracking transactions by txid is precarious. To keep your sanity
> make
> >>> sure all inputs are segwit. But remember segwit does not prevent
> txid
> >>> malleability unless you validate the transaction. So really make
> sure
> >>> you're using testmempoolaccept at the very least
> >>>
> >>> - Bustapay could be abused by a malicious party to query if you own a
> >>> deposit address or not. So never accept a bustapay transaction
> that pays
> >>> an already used deposit address
> >>>
> >>> - You will need to keep a mapping of which utxos people have showed
> you
> >>> and which you revealed. So if you see them again, you can reveal
> the
> >>> same one of your own
> >>>
> >>> - Check if the transaction was already sorted according to BIP69, if
> so
> >>> ensure the result stays that way. Otherwise probably just shuffle
> the
> >>> inputs/outpus
> >>>
> >>>
> >>> Notes for sending applications:
> >>>
> >>> - The HTTP response must not be trusted. It should be fully validated
> >>> that no unexpected changes have been made to the transaction.
> >>>
> >>> - The sender should be aware the original "template transaction" may
> be
> >>> propagated at any time, and in fact can intentionally be
> >>> done so for the purpose of RBF as it should have a slightly
> higher fee
> >>> rate.
> >>>
> >>>
> >>> == Credits ==
> >>> The idea is obviously based upon Dr. Maxwell's seminal CoinJoin
> >>> proposal, and reduced scope inspired by a simplification of the "pay 2
> >>> endpoint" (now offline) blog post by blockstream.
> >>> -Ryan
> >>>
> >>> 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/20190127/7a236457/attachment-0001.html>;

📅 Original date posted:2019-01-02 📝 Original message:On ...

2023-06-07T18:15:56Z

In reply to nevent1q…ndek
_________________________

📅 Original date posted:2019-01-02
📝 Original message:On Wed, Jan 2, 2019 at 3:40 AM Alan Evans via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

>
> I think any method that doesn't use real entropy, but some fake source of
> randomness, such as a book is asking to be hacked and so is not a
> reasonable idea.
>
> If an algorithm for book text to BIP39 sentence ever became well used,
> common books will be systematically searched for accounts. People will also
> choose their favourite passages, so I would expect to see collisions.
>
>
I tend to have this conversation a lot ;) I'm not sure what Aymeric has in
mind, but my suggestions are for use by the small few who properly
understand how these things work. I am not suggesting blockchain.info
require every user to choose a book passage to use as their backup phrase!

There are so many small things that could be done to make a text input
unique. Choose the X number of words from the start of the Nth sentence.
Replace all punctuation with exclamation points. Combine two sentences from
different pages. It would be nigh impossible to brute force any of these,
and would require hints/instructions from the owner to recover.

But I admit if this is not intended for standardization, discussing it on
this mailing list is probably unwarranted.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190102/c926eff7/attachment.html>;

📅 Original date posted:2018-12-26 📝 Original message:On ...

2023-06-07T18:15:52Z

In reply to nevent1q…yt0f
_________________________

📅 Original date posted:2018-12-26
📝 Original message:On Wed, Dec 26, 2018 at 11:33 AM Aymeric Vitte <vitteaymeric at gmail.com>
wrote:

> so, even with a tool like yours, they can be misleaded, for example trying
> a few words to replace the missing/incorrect one, get a valid seed and stay
> stuck with it forever trying to play with BIP44/49 to find their keys
>

Just a small detail, but my tool actually looks up all the possible
combinations and then finds which one has been used before by looking for
past transactions on the blockchain. Therefore, it won't tell you your
phrase is correct unless it is a phrase that has actually been used before
(preventing what you described).

Using some algorithm to take some input and generate a bip39 phrase that
you can use with any bip39 wallet sounds perfectly reasonable.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20181226/270226c7/attachment-0001.html>;

📅 Original date posted:2018-12-24 📝 Original message:On ...

2023-06-07T18:15:51Z

In reply to nevent1q…xg6f
_________________________

📅 Original date posted:2018-12-24
📝 Original message:On Mon, Dec 24, 2018 at 2:48 PM Aymeric Vitte via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

>
> I don't see very well why it's easier to write n words that you cannot
> choose rather than a 32B BIP32 hex seed, and I have seen many people
> completely lost with their wallets because of this
>

In practice it has quite a few qualities that make it a bit more resilient
for physical (written) storage.

If a few letters of a word get rubbed off or otherwise become illegible, it
is pretty easy for a native speaker to figure out what the word is supposed
to be. Even a non-native speaker could look through the word list and
figure out which word fits. Missing characters in a hex string require more
advanced brute force searching, which the average user isn't capable of.

Additionally, having the bits grouped into words makes a more serious
recovery easier. If you lose one entire word, it can be brute forced in
about 5 minutes on a normal pc, even if you don't know which position the
missing word is in (I have published a tool that does just this:
https://jmacwhyte.github.io/recovery-phrase-recovery). If you are missing
two words, you can brute force it in about a week (napkin math).

If you were missing a random chunk of a hex string, I don't know how you'd
go about brute forcing that in a timely manner.

As an aside, from a UX standpoint we've seen that the 12 words don't *look*
important so people don't take them seriously (and they get lost). A hex
string or equivalent would look more password-y, and therefore would most
likely be better protected by users.

James
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20181225/81287f18/attachment.html>;

📅 Original date posted:2018-12-04 📝 Original message:I ...

2023-06-07T18:15:29Z

In reply to nevent1q…tgt7
_________________________

📅 Original date posted:2018-12-04
📝 Original message:I agree with Joseph. If you want plausible deniability, it would be better
to simply hide the funds somewhere in the HD chain. Same if you want a
second vault tied to the same phrase.

You are reducing security by eliminating all entropy that doesn't fit the
reversible criteria, although in practice it doesn't make a difference
because the numbers are so big. However, it doesn't seem like a very useful
feature to have.

Thanks for doing all that work though, it was fun to read about your idea
and what you found out through experimenting!

James

On Mon, Dec 3, 2018 at 1:00 PM Joseph Gleason ⑈ via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> I have a suggestion. If you are concerned about plausible deniability,
> then it might make sense to just have the single mnemonic seed lead to a
> single xprv key (as usual) and then do a private key derivation from that
> based on a password string. The password can be simple, as it is based on
> the security of the seed, just as long as the user feels they need for
> deniability.
>
> A simple reverse scheme like you describe would just be another thing a
> person would know to check if given some seed so I don't see it as
> providing much value, but I could be missing something.
>
> On Mon, Dec 3, 2018 at 10:45 AM Steven Hatzakis via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> Hi All,
>>
>> I've developed a method to check if a mnemonic is also valid when the
>> words are put into reverse order (not the entropy), where a given 12 or
>> 24-word mnemonic could be valid both in little endian and big endian
>> format. I've coined these "Palindromic Mnemonics", but perhaps more
>> user-friendly is "reversible mnemonics."
>>
>> Purpose:
>> A checksum-valid reversible mnemonic allows two separate vaults to be
>> connected to the same mnemonic string of words, where all a users must do
>> is enter the words in reverse order (the last word becomes first, second to
>> last becomes second, and so on) to access the secondary (reversed words)
>> vault. This utility could provide multiple use-cases, including related to
>> combinations with passphrases and plausible deniability, as well as
>> conveniences for those wishing to use a separate vault tied to the same
>> string of words.
>>
>> Security:
>> For any randomly generated 12-word mnemonic (128-bits of security) the
>> chances of it also being reversible are 1/16 (I believe), as a total of 4
>> bit positions must be identical (4 bits from the normal mnemonic and
>> another 4 bits from the reversed string must match). For a 24-word
>> mnemonic, those values increase to 8 bits which need to match 8 bits from
>> the reversed string, leading to about 1 in every 256 mnemonics also being
>> reversible. While the message space of valid reversible mnemonics should be
>> 2^124 for 12 words, that search must still be conducted over a field of 2
>> ^128, as the hash-derived checksum values otherwise prevent a way to
>> deterministically find valid reversible mnemonics without first going
>> through invalid reversible ones to check. I think others should chime in on
>> whether they believe there is any security loss, in terms of entropy bits
>> (assuming the initial 128 bits were generated securely). I estimate at most
>> it would be 4-bits of loss for a 12-word mnemonic, but only if an attacker
>> had a way to search only the space of valid reversible mnemonics (2**124)
>> which I don't think is feasible (could be wrong?). There could also be
>> errors in my above assumptions, this is a work in progress and sharing it
>> here to solicit initial feedback/interest.
>>
>> I've already written the code that can be used for testing (on GitHub
>> user @hatgit), and when run from terminal/command prompt it is pretty fast
>> to find a valid reversible mnemonics, whereas on IDLE in Python on a 32-bit
>> and 64-bit machine it could take a few seconds for 12 words and sometimes
>> 10 minutes to find a valid 24-word reversible mnemonic.
>> Example 12 words reversible (with valid checksum each way):
>>
>> limit exact seven clarify utility road image fresh leg cabbage hint canoe
>>
>> And Reversed:
>>
>> canoe hint cabbage leg fresh image road utility clarify seven exact limit
>>
>>
>> Example 24 reversible:
>>
>> favorite uncover sugar wealth army shift goose fury market toe message
>> remain direct arrow duck afraid enroll salt knife school duck sunny grunt
>> argue
>>
>> And reversed:
>>
>> argue grunt sunny duck school knife salt enroll afraid duck arrow direct
>> remain message toe market fury goose shift army wealth sugar uncover
>> favorite
>>
>>
>> My two questions 1) are how useful could this be for
>> you/users/devs/service providers etc.. and 2) is any security loss
>> occurring and whether it is negligible or not?
>>
>> Best regards,
>>
>> Steven Hatzakis
>> _______________________________________________
>> 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/20181204/fbd20ae0/attachment.html>;

📅 Original date posted:2018-12-01 📝 Original message:Hi ...

2023-06-07T18:15:26Z

In reply to nevent1q…7arv
_________________________

📅 Original date posted:2018-12-01
📝 Original message:Hi Yuval!

Sorry for reviving an old email thread. Could you describe what the UX
would be like, or how a wallet developer might implement this? Is the
intention that someone would open their non-private wallet, and choose an
option that slowly siphons their funds into a different app? Why would
anyone want that feature?

If the user is privacy-conscious, why did they choose the non-private
wallet to begin with? Why wouldn't they just move all their funds to the
private wallet so they can continue to use just one app?

And if the user is not privacy-conscious, they would never choose to enable
this option, so why would the wallet developer even bother to implement it?

>From a product standpoint, I can't see how this would be useful, and
therefore I'm not sure why it needs to be a BIP. If I'm missing something,
please let me know!

Thanks,
James

On Tue, Nov 6, 2018 at 10:18 AM Yuval Kogman via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> Hello,
>
> I would like to propose a method based on BIP32 (and optionally BIP44) for
> improving fungibility and on chain privacy with wallets for which this is
> not a primary concern, requiring minimal changes to allow such wallets to
> safely forward change outputs to more specialized wallets. This is intended
> to complement more comprehensive proposals such as BIP79.
>
> Note that this draft is still incomplete, there are open questions about
> the particular format to use. In its current form it proposes two viable
> options (and two more are included completeness) and though I have a slight
> preference for the first option, I remain undecided given the tradeoffs,
> and so I am writing the mailing list to solicit inputs/criticism.
>
> https://gist.github.com/nothingmuch/652f3a98089a0600637eadab738b2d6a
>
> Thanks to SirMeow, Adam Ficsor, and Adam Gibson for reviewing earlier
> versions and providing valuable feedback and suggestions.
>
> Regards,
> Yuval
> _______________________________________________
> 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/20181130/36adb957/attachment-0001.html>;

📅 Original date posted:2018-12-01 📝 Original message:I ...

2023-06-07T18:15:25Z

In reply to nevent1q…y8cs
_________________________

📅 Original date posted:2018-12-01
📝 Original message:I liked the cheekiness of your summary, Adam ;)

I'm not sure why this needs to be a BIP. It is a UX detail--not really
related to bitcoin protocol or procedures. I wouldn't even call it a
description of best practices, since every product's use case is going to
be different.

If you think there is a compelling reason for why this needs to be a
documented standard, please elaborate!

Thanks,
James

On Sun, Nov 11, 2018 at 7:41 PM Adam Ficsor via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> Thank you for all your comments. To sum up:
>
> - There were no comments related to the implementation details.
> - There are concerns about this may incentivize users to use copypaste
> functionality extensively.
> - A counter argument was made that crypto hijackers use the clipboard,
> because that is the most convenient thing to hijack, not because they can
> only hijack that and, if Bitcoin users would move to other ways of
> specifying destinations, that may end up being just as an issue, too.
> - The rest of the conversation was about crypto hijackers, which I think
> is off topic in this thread.
>
> Finally I'd like to note, there's already a work in progress
> implementation in Wasabi:
> https://github.com/zkSNACKs/WalletWasabi/pull/825
>
> On Fri, Nov 9, 2018 at 1:14 AM Dmitry Petukhov via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>>
>> > > Do you know any reasonably convenient mechanism for end user to
>> > > transfer an address from, say, a web page to the wallet address
>> > > input field ?
>> >
>> > - QR code scanning of a Bitcoin URI
>> > - On Android: A "bitcoin:" URI intent or a BIP70 payment message
>> > intent
>> > - On desktop OSes there are similar mechanisms to launch Apps from the
>> > browser (e.g. for mailto: links)
>>
>> This works if the author of the web page thought about this, and
>> created appropriate liks/qr codes. In many cases, addresses are
>> just presented for users as text, to copy.
>>
>> People also send addresses in message apps and emails. Maybe if
>> applications start to autodetect bitcoin addresses and convert them to
>> bitcoin: links, there will be less need to copy-paste. But I suspect
>> that this feature will not be quickly adopted by applications.
>>
>> > For cases where the payee is a well-known entity the BIP70 payment
>> > protocol has authentication via certificates. That doesn't work for
>> > the "the person in front of you is the only trust anchor you have"
>> > usecase though.
>>
>> There are also BIP75 and BIP47 that may help, but the number of wallets
>> that support these protocols is small (I think in part because of
>> relative complexity of these protocols).
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
>
> --
> Best,
> Ádám
> _______________________________________________
> 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/20181130/37af33c4/attachment.html>;

📅 Original date posted:2018-10-08 📝 Original message:Hello! ...

2023-06-07T18:14:58Z

In reply to nevent1q…eqqu
_________________________

📅 Original date posted:2018-10-08
📝 Original message:Hello!

A URI is useful as a standard for one-way communication, but on-chain
multisig requires many steps. multiple parties need to provide signatures,
and one party needs to aggregate all the signatures and publish the
transaction. This URI scheme would allow one to pass along a raw
transaction in one direction, but once the signer has signed the
transaction, what are they supposed to do with it? You might be thinking
you could include a callback URL, like BIP72 does, so the signer can pass
the signed transaction back to the organizer. However, BIP72 was created as
a backwards-compatible extension to BIP70, which was designed for one-way
communication. Since there is no way to be backwards compatible here, there
is no need to limit yourself to the URI system. Instead of creating a new
URI and using it for something it is not suited for, it would be better (in
my opinion) to find a different method that is better suited for two-way
communication.

On Thu, Oct 4, 2018 at 3:52 PM おのかちお via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> Hi.
>
> I have an idea that subject.
>
> There are already BIP 21.
> But Multisig request URI is non exist.
>
> My idea is below:
>
> bitcoin-sigreq://{{rawtx}}?{{param}}
>
> rawtx: raw transaction (encoded by base64)
> param:
> - pubkey={{public key for sign key pair}}
> - hd_wallet_position={{path for HD wallet position}}
>
> This URI scheme is used for multisig request from website to user's local
> wallet.
>
> How do you think ?
> _______________________________________________
> 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/20181008/2520c954/attachment.html>;

📅 Original date posted:2017-05-30 📝 Original message:> ...

2023-06-07T18:01:50Z

In reply to nevent1q…wcql
_________________________

📅 Original date posted:2017-05-30
📝 Original message:> The 1MB classic block size prevents quadratic hashing
> problems from being any worse than they are today.
>
>
Add a transaction-size limit of, say, 10kb and the quadratic hashing
problem is a non-issue. Donezo.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170530/359bc4e6/attachment.html>;

📅 Original date posted:2017-01-06 📝 Original ...

2023-06-07T17:55:11Z

In reply to nevent1q…wu6p
_________________________

📅 Original date posted:2017-01-06
📝 Original message:It's my opinion that the purpose of this list and bitcoin protocol
development in general is to build the base functionality that other
companies and individuals require to provide usability to the end-user. The
0-conf debate is a UX issue. If end users shouldn't rely on 0-conf, it is
up to wallet developers to hide 0-conf transactions or mark them
appropriately. Instead of using this list to debate what wallet designers
should or shouldn't do, we should just provide the tools and "let the
market sort it out". If wallet developers start getting inundated with
complaints that 0-conf transactions are causing confusion and loss, they
will find a solution. If the tools they require for the solution don't
exist, they will come to this list to request action.

Am I wrong?

On Fri, Jan 6, 2017 at 12:16 PM Chris Priest via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> Its a method for determining the probability that a valid tx will be
> mined in a block before that tx actually gets mined, which is useful
> when accepting payments in situations when you can't wait for the full
> confirmation. No one is saying all tx validation should be performed
> by querying miners mempools, that's ridiculous. Obviously once the tx
> gets it's first confirmation, you go back to determining validity the
> way you always have. There is no "security catastrophe".
>
> Even if you're running a full node, you can't know for certain that
> any given tx will make it into a future block. You can't be certain
> the future miner who finally does mine that tx will mine your TXID or
> another TXID that spends the same inputs to another address (a double
> spend). The only way to actually know for certain is to query every
> single large hashpower mempool.
>
> On 1/4/17, Eric Voskuil <eric at voskuil.org> wrote:
> > On 01/04/2017 11:06 PM, Chris Priest via bitcoin-dev wrote:
> >> On 1/3/17, Jonas Schnelli via bitcoin-dev
> >> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> >>>
> >>> 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.
> >>
> >> The best way is to connect to the mempool of each miner and check to
> >> see if they have your txid in their mempool.
> >>
> >> https://www.antpool.com/api/is_in_mempool?txid=334847bb...
> >> https://www.f2pool.com/api/is_in_mempool?txid=334847bb...
> >> https://bw.com/api/is_in_mempool?txid=334847bb...
> >> https://bitfury.com/api/is_in_mempool?txid=334847bb...
> >> https://btcc.com/api/is_in_mempool?txid=334847bb...
> >>
> >> If each of these services return "True", and you know those services
> >> so not engage in RBF, then you can assume with great confidence that
> >> your transaction will be in the next block, or in a block very soon.
> >> If any one of those services return "False", then you must assume that
> >> it is possible that there is a double spend floating around, and that
> >> you should wait to see if that tx gets confirmed. The problem is that
> >> not every pool runs such a service to check the contents of their
> >> mempool...
> >>
> >> This is an example of mining centralization increasing the security of
> >> zero confirm.
> >
> > A world connected up to a few web services to determine payment validity
> > is an example of a bitcoin security catastrophe.
> >
> > e
> >
> >
> _______________________________________________
> 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/20170106/55cde129/attachment.html>;

📅 Original date posted:2016-12-18 📝 Original message:Hi ...

2023-06-07T17:54:51Z

In reply to nevent1q…p6ap
_________________________

📅 Original date posted:2016-12-18
📝 Original message:Hi All,

I'm coming late to the party. I like the Block75 proposal.

Multiple people have said miners would/could stuff blocks with insincere
transactions to increase the block size, but it was never adequately
explained what they would gain from this. If there aren't enough legitimate
transactions to fill up the block, where do you plan to earn extra income
once the block is bigger?

Miners would be incentivized to include as many legitimate transactions as
possible, but if propagation time is as big an issue as some of you have
said it is, miners would also be incentivized to keep their blocks small
enough to propagate. So why not give them the choice? Once the block size
gets too big to propagate effectively, miners would be naturally
incentivized to limit how much data they put in each block, finding the
perfect balance.

In my opinion, none of the downsides presented so far have been a good
argument. Risk of a 51% attack is not unique to this proposal, saying "we
could also do that with hardcoded limits" doesn't actually point out any
problem with this proposal, and miners already have the ability to add or
withhold transactions from their blocks.

We trust our miners to serve us by acting in their own best interests, and
this proposal simply gives them more options for doing that. If anyone can
make a strong argument against that would earn top marks in a high school
debate class, I'd love to hear it!

James

On Sun, Dec 11, 2016 at 3:23 PM s7r via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> Andrew Johnson wrote:
> > "You miss something obvious that makes this attack actually free of cost.
> > Nothing will "cost them more in transaction fees". A miner can create
> > thousands of transactions paying to himself, and not broadcast them to
> > the network, but hold them and include them in the blocks he mines. The
> > fees are collected by him because transactions are included in a block
> > that he mined and the left amount is in another wallet of the same
> > person. Repeat this continuously to fill blocks."
> >
> > This is easily detectable as long as the network isn't heavily
> > partitioned(which is an assumption we make today in order for
> > transaction propagation to work reliably as well as for xThin and
> > CompactBlocks to work effectively to reduce block transmission time).
> > Other miners would have an incentive to intentionally orphan blocks that
> > contained a large number of transactions that their nodes were unaware
> of.
> >
> > I don't think this sort of attack would last long. Even later when
> > subsidies are drastically reduced, you would still lose out on
> > significant genuine fee revenue if your orphan rate increased even
> > 10%(one out of ten of your poison blocks intentionally orphaned by
> > another miner).
> >
>
> I disagree.
>
> I didn't say this is impossible to detect, but it is hard to act against
> it. One miner orphaning the block intentionally is very unlikely if that
> miner acts rationally. It would only make sense if 51% of the hash rate
> would intentionally orphan it. Otherwise the miner who intentionally
> orphans a valid block, let's say block X, has to continue to mine one in
> its place on top of block X-1, and by the time he finds one:
>
> a) his block X' is rejected by other miners because they already have a
> valid block X on top of which they already started to mine;
>
> b) block X+1 was already found and broadcasted, so the miner who
> orphaned X intentionally is on the shorter chain ignored by the network.
>
> So, one miner cannot do anything about it. Even a pool cannot do
> anything about it, because the loss is greater. You need 51% of the hash
> rate to intentionally orphan it, and all the miners forming 51% need to
> be colluding and know for sure that every one will intentionally orphan
> the said block, otherwise there's a huge risk of loss for who does it.
> Nobody would gamble to do this (I am not sure if gambling is the right
> word, since the loss is 100% sure here). But, we are not discussing 51%
> attacks because those are a different topic.
>
> _______________________________________________
> 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/20161218/f08a63d8/attachment-0001.html>;

📅 Original date posted:2016-08-31 📝 Original message:Hello ...

2023-06-07T17:53:12Z

In reply to nevent1q…xkur
_________________________

📅 Original date posted:2016-08-31
📝 Original message:Hello all,

Today we are submitting some updates to BIP75:

-- Example use cases have been reworded to more accurately describe the
goal of this BIP and how the technology works.
-- ECDSA and PGP have been added to the supported public key infrastructure
(PKI) types to increase flexibility and use cases.
-- Versioning has been added to make future changes and backwards
compatibility easy to manage.
-- Other minor, technical details have been added or changed to improve
performance and reduce ambiguity during implementation.

You can see the PR here: https://github.com/bitcoin/bips/pull/439

Thank you,
James
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160831/87e4cd0e/attachment.html>;

📅 Original date posted:2016-08-31 📝 Original message:> ...

2023-06-07T17:53:10Z

In reply to nevent1q…n572
_________________________

📅 Original date posted:2016-08-31
📝 Original message:>
> >I've always assumed honeypots were meant to look like regular, yet
> >poorly-secured, assets.
>
> Not at all. Most servers have zero reason to have any Bitcoin's accessible
> via them, so the presence of BTC privkeys is a gigantic red flag that they
> are part of a honeypot.
>

I was talking about the traditional concept. From Wikipedia: "Generally, a
honeypot consists of data (for example, in a network site) that appears to
be a legitimate part of the site but is actually isolated and monitored,
and that seems to contain information or a resource of value to attackers,
which are then blocked."

I would argue there are ways to make it look like it is not a honeypot
(plenty of bitcoin services have had their hot wallets hacked before, and
if the intruder only gains access to one server they wouldn't know that all
the servers have the same honeypot on them). But I was just confirming that
the proposal is for an obvious honeypot.

> Re-read my last section on the "scorched earth" disincentive to
> doublespend the intruder.
>
> The first time I read it I didn't realize that the second transaction the
intruder has is designed to waste the honeypot AND additional funds
belonging to the honeypot creator. That's pretty good, from a game theory
perspective.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160831/fe3096c6/attachment.html>;

📅 Original date posted:2016-08-27 📝 Original message:Why ...

2023-06-07T17:53:10Z

In reply to nevent1q…y3l5
_________________________

📅 Original date posted:2016-08-27
📝 Original message:Why not just have a single 1-of-m multisig transaction, with one key on
each server? Based on which key is used you would know which server is
compromised, and (in my opinion) it wouldn't look nearly as suspicious.

On Thu, Aug 25, 2016 at 11:26 AM Gregory Maxwell via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> On Thu, Aug 25, 2016 at 2:27 PM, Christian Decker via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> > If however
> > he is planning to use it as a foothold to further compromise your
> > company, send spam or similar, he will likely try to avoid these
> > tripwires. [...]
>
> Depends on the value of their activity compared to the value of the coins.
> Spamming doesn't pay much.
>
> Covert tripwires would obviously be better, but if shared tripwires
> allow you to have 100x the funds available it could be a good
> trade-off.
> _______________________________________________
> 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/20160828/5d9952ea/attachment.html>;

📅 Original date posted:2016-08-24 📝 Original ...

2023-06-07T17:53:09Z

In reply to nevent1q…ahmt
_________________________

📅 Original date posted:2016-08-24
📝 Original message:I've always assumed honeypots were meant to look like regular, yet
poorly-secured, assets. If the intruder could identify this as a honeypot
by the strange setup (presigned, non-standard transactions lying around)
and was aware that the creator intended to doublespend as soon as the
transaction was discovered, wouldn't they instead prefer to not touch
anything and wait for a non-bait target to appear? Is the assumption here
that the intruder wouldn't know this is a honeypot, or that they would know
and it's just assumed that they would rather take their chances on this
instead of causing some other trouble?

On Tue, Aug 23, 2016 at 6:47 PM Peter Todd via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> Bitcoin-based honeypots incentivise intruders into revealing the fact they
> have
> broken into a server by allowing them to claim a reward based on secret
> information obtained during the intrusion. Spending a bitcoin can only be
> done
> by publishing data to a public place - the Bitcoin blockchain - allowing
> detection of the intrusion.
>
> The simplest way to achieve this is with one private key per server, with
> each
> server associated with one transaction output spendable by that key.
> However
> this isn't capital efficient if you have multiple servers to protect: if we
> have N servers and P bitcoins that we can afford to lose in the
> compromise, one
> key per server gives the intruder only N/P incentive.
>
> Previously Piete Wuille proposed(1) tree signatures for honeypots, with a
> single txout protected by a 1-N tree of keys, with each server assigned a
> specific key. Unfortunately though, tree signatures aren't yet implemented
> in
> the Bitcoin protocol.
>
> However with a 2-of-2 multisig and the SIGHASH_SINGLE feature we can
> implement
> this functionality with the existing Bitcoin protocol using the following
> script:
>
> 2 <honeypot-pubkey> <distriminator-pubkey> 2 CHECKMULTISIG
>
> The honeypot secret key is shared among all N servers, and left on them.
> The
> distriminator secret key meanwhile is kept secret, however for each server
> a
> unique signature is created with SIGHASH_SINGLE, paying a token amount to a
> notification address. For each individual server a pre-signed signature
> created
> with the distriminator secret key is then left on the associated server
> along
> with the honeypot secret key.
>
> Recall the SIGHASH_SINGLE flag means that the signature only signs a single
> transaction input and transaction output; the transaction is allowed to
> have
> additional inputs and outputs added. This allows the thief to use the
> honeypot
> key to construct a claim transaction with an additional output added that
> pays
> an address that they own with the rest of the funds.
>
> Equally, we could also use SIGHASH_NONE, with the per-server discriminator
> being the K value used in the pre-signed transaction.
>
> Note that Jeff Coleman deserves credit as co-inventor of all the above.
>
>
> Censorship Resistance
> =====================
>
> A potential disadvantage of using non-standard SIGHASH flags is that the
> transactions involved are somewhat unusual, and may be flagged by
> risk analysis at exchanges and the like, a threat to the fungibility of the
> reward.
>
> We can improve on the above concept from Todd/Coleman by using a pre-signed
> standard transaction instead. The pre-signed transaction spends the
> honeypot
> txout to two addresses, a per-server canary address, and a change address.
> The
> private key associated with the change addres is also left on the server,
> and
> the intruder can then spend that change output to finally collect their
> reward.
>
> To any external observer the result looks like two normal transactions
> created
> in the process of someone with a standard wallet sending a small amount of
> funds to an address, followed by sending a larger amount.
>
>
> Doublespending
> ==============
>
> A subtlety in the the two transactions concept is that the intruder doesn't
> have the necessary private keys to modify the first transaction, which
> means
> that the honeypot owner can respond to the compromise by doublespending
> that
> transaction, potentially recovering the honeypot while still learning
> about the
> compromise. While this is possible with all honeypots, if the first
> transaction
> is signed with the opt-in RBF flags, and CPFP-aware transaction
> replacement is
> not implemented by miners, the mechanics are particularly disadvantageous
> to
> the intruder, as the honeypot owner only needs to increase the first
> transaction's fee slightly to have a high chance of recovering their funds.
> With CPFP-aware transaction replacement the intruder could in-turn respond
> with
> a high-fee CPFP second transaction, but currently no such implementation is
> known.
>
>
> Scorched Earth
> ==============
>
> We can use the "scorched earth" concept to improve the credibility of the
> honeypot reward by making it costly for the honeypot owner to doublespend.
> Here
> a second version of the honeypot pre-signed transaction would also be
> provided
> which sepnds the entirety of the honeypot output to fees, and additionally
> spends a second output to fees. An economically rational intruder will
> publish
> the first version, which maximizes the funds they get out of the honeypot.
> If
> the owner tries to dishonestly doublespend, they can respond by publishing
> the
> "scorched earth" transaction, encouraging the honeypot owner's honesty and
> making CPFP-aware transaction replacement irrelevant.
>
> Of course, miner centralization adds complexity to the above: in many
> instances
> honeypot owners and/or intruders will be able to recover funds from
> altruistic
> miners. Equally, the additional complexity may discourage intruders from
> making
> use of the honeypot entirely.
>
> Note that as an implementation consideration CHECKSEQUENCEVERIFY can be
> used to
> ensure the honeypot output can only be spent with transaction replacement
> enabled, as CSV requires nSequence to be set in specific ways in any
> transation
> spending the output.
>
>
> References
> ==========
>
> 1) https://blockstream.com/2015/08/24/treesignatures/
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
> _______________________________________________
> 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/20160825/52443c18/attachment.html>;

📅 Original date posted:2016-08-12 📝 Original message:For ...

2023-06-07T17:52:39Z

In reply to nevent1q…yeph
_________________________

📅 Original date posted:2016-08-12
📝 Original message:For reasons others have pointed out, it's not really plausible.

Either way, this has nothing to do with transmitting data over audio.
Please start a new thread if you want to discuss your idea instead of
hijacking this one. Thanks ;)

On Fri, Aug 12, 2016, 05:36 Erik Aronesty via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> I'm imagining a "publishable seed" such that:
>
> - someone can derive a random bitcoin address from it - and send funds
> to it.
> - the possible derived address space is large enough that generating all
> possible addresses would be a barrier
> - the receiver, however, knowing the private key, can easily scan the
> blockchain fairly efficiently and determine which addresses he has the keys
> to
> - another interested party cannot easily do so
>
> Perhaps homomorphic encryption may need to be involved?
>
>
> On Thu, Aug 11, 2016 at 8:36 PM, Gregory Maxwell <greg at xiph.org> wrote:
>
>> On Thu, Aug 11, 2016 at 8:37 PM, Erik Aronesty via bitcoin-dev
>> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> > Still not sure how you can take a BIP32 public seed and figure out if an
>> > address was derived from it though. I mean, wouldn't I have to
>> compute all
>> > 2^31 possible public child addresses?
>>
>> Which would take a quad core laptop about 8 hours with competent software
>>
>> And presumably you're not using the whole 2^31 space else the receiver
>> also has to do that computation...
>>
>
> _______________________________________________
> 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/20160812/e916cf2b/attachment-0001.html>;

📅 Original date posted:2016-08-10 📝 Original message:I ...

2023-06-07T17:52:37Z

In reply to nevent1q…gq4u
_________________________

📅 Original date posted:2016-08-10
📝 Original message:I agree, audio-based transference isn't really great for a podcast or radio
ad. It could be used to transmit payment details between phones that don't
have cameras, though. I think it would be better to define a standard for
transmitting information over audio, but not define what information is to
be conveyed so people could use the method for sending pub keys, payment
protocol requests, or anything else developers might want to make use of.

I'm guessing some sort of data-over-audio standard already exists? In which
case the bip could just say "we use [standard] to convey any
bitcoin-related data".

On Wed, Aug 10, 2016, 10:55 Daniel Hoffman via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> thats how i thought it worked originally, but im not well versed on that,
> so i took his word for it
>
> On Aug 10, 2016 12:38 PM, "Pieter Wuille via bitcoin-dev" <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> On Wed, Aug 10, 2016 at 7:28 PM, Erik Aronesty via bitcoin-dev
>> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> > By sending a public seed, there's no way for someone to use the
>> transmitted
>> > address and trace the total amount of payments to it.
>>
>> Worse. By revealing a public seed, anyone who has seen it (= anyone
>> who ever pays you through it) can identity all payments to _any_
>> address derived from that seed.
>>
>> --
>> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160810/115775e9/attachment-0001.html>;

📅 Original date posted:2016-08-10 📝 Original message:Signed ...

2023-06-07T17:52:29Z

In reply to nevent1q…24h5
_________________________

📅 Original date posted:2016-08-10
📝 Original message:Signed by the key pair that was referenced in the output of the on-chain
transaction? (Bob in my example, actually) Doesn't that mean it's easy to
follow who is paying whom, you just can't see how much is going to reach
recipient?

On Tue, Aug 9, 2016, 04:40 Tony Churyumoff <tony991 at gmail.com> wrote:

> This troll is harmless. A duplicate spend proof should also be signed
> by the same user (Alice, in your example) to be considered a double
> spend.
>
> 2016-08-09 3:18 GMT+03:00 James MacWhyte <macwhyte at gmail.com>:
> > One more thought about why verification by miners may be needed.
> >
> > Let's say Alice sends Bob a transaction, generating output C.
> >
> > A troll, named Timothy, broadcasts a transaction with a random hash,
> > referencing C's output as its spend proof. The miners can't tell if it's
> > valid or not, and so they include the transaction in a block. Now Bob's
> > money is useless, because everyone can see the spend proof referenced and
> > thinks it has already been spent, even though the transaction that
> claims it
> > isn't valid.
> >
> > Did I miss something that protects against this?
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160810/718af0de/attachment.html>;

📅 Original date posted:2016-08-08 📝 Original message:That ...

2023-06-07T17:52:28Z

In reply to nevent1q…5726
_________________________

📅 Original date posted:2016-08-08
📝 Original message:That is a good point. As you said, it puts a lot more burden on the coin
holders. One big downside would be data management. Instead of simply
backing up a single HD private key, the user would have to back up entire
histories of every output that has been sent to them if they want to secure
their funds.

It also requires them to be online to receive payments, and I think finding
a method of sending the private message containing the coin's history is
going to be a bit of a challenge. If you connect directly to the recipient
to convey the information through traditional channels, anonymity is lost.
Sending messages through the bitcoin network is one option to protect
anonymity, but without active pathfinding there's no guarantee the payee
will even get the message. I'm assuming you'd have to essentially replace
tx messages with encrypted BBC histories, and mempools are quite full as it
is.

Tony, do you have any more thoughts on exactly how users would convey the
private messages to payees?

On Mon, Aug 8, 2016 at 4:42 PM Tony Churyumoff <tony991 at gmail.com> wrote:

> The whole point is in preventing every third party, including miners, from
> seeing the details of what is being spent and how. The burden of
> verification is shifted to the owners of the coin (which is fair).
>
> In fact we could have miners recognize spend proofs and check that the
> same spend proof is not entered into the blockchain more than once (which
> would be a sign of double spend), but it is not required. The coin owners
> can already do that themselves.
>
> 2016-08-09 0:41 GMT+03:00 James MacWhyte <macwhyte at gmail.com>:
>
>> Wouldn't you lose the ability to assume transactions in the blockchain
>> are verified as valid, since miners can't see the details of what is being
>> spent and how? I feel like this ability is bitcoin's greatest asset, and by
>> removing it you're creating an altcoin different enough to not be connected
>> to/supported by the main bitcoin project.
>>
>> On Mon, Aug 8, 2016, 09:13 Tony Churyumoff via bitcoin-dev <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>>> Hi Henning,
>>>
>>> 1. The fees are paid by the enclosing BTC transaction.
>>> 2. The hash is encoded into an OP_RETURN.
>>>
>>> > Regarding the blinding factor, I think you could just use HMAC.
>>> How exactly?
>>>
>>> Tony
>>>
>>>
>>> 2016-08-08 18:47 GMT+03:00 Henning Kopp <henning.kopp at uni-ulm.de>:
>>>
>>>> Hi Tony,
>>>>
>>>> I see some issues in your protocol.
>>>>
>>>> 1. How are mining fees handled?
>>>>
>>>> 2. Assume Alice sends Bob some Coins together with their history and
>>>> Bob checks that the history is correct. How does the hash of the txout
>>>> find its way into the blockchain?
>>>>
>>>> Regarding the blinding factor, I think you could just use HMAC.
>>>>
>>>> All the best
>>>> Henning
>>>>
>>>>
>>>> On Mon, Aug 08, 2016 at 06:30:21PM +0300, Tony Churyumoff via
>>>> bitcoin-dev wrote:
>>>> > This is a proposal about hiding the entire content of bitcoin
>>>> > transactions. It goes farther than CoinJoin and ring signatures,
>>>> which
>>>> > only obfuscate the transaction graph, and Confidential Transactions,
>>>> which
>>>> > only hide the amounts.
>>>> >
>>>> > The central idea of the proposed design is to hide the entire inputs
>>>> and
>>>> > outputs, and publish only the hash of inputs and outputs in the
>>>> > blockchain. The hash can be published as OP_RETURN. The plaintext of
>>>> > inputs and outputs is sent directly to the payee via a private
>>>> message, and
>>>> > never goes into the blockchain. The payee then calculates the hash
>>>> and
>>>> > looks it up in the blockchain to verify that the hash was indeed
>>>> published
>>>> > by the payer.
>>>> >
>>>> > Since the plaintext of the transaction is not published to the public
>>>> > blockchain, all validation work has to be done only by the user who
>>>> > receives the payment.
>>>> >
>>>> > To protect against double-spends, the payer also has to publish
>>>> another
>>>> > hash, which is the hash of the output being spent. We’ll call this
>>>> hash *spend
>>>> > proof*. Since the spend proof depends solely on the output being
>>>> spent,
>>>> > any attempt to spend the same output again will produce exactly the
>>>> same
>>>> > spend proof, and the payee will be able to see that, and will reject
>>>> the
>>>> > payment. If there are several outputs consumed by the same
>>>> transaction,
>>>> > the payer has to publish several spend proofs.
>>>> >
>>>> > To prove that the outputs being spent are valid, the payer also has
>>>> to send
>>>> > the plaintexts of the earlier transaction(s) that produced them, then
>>>> the
>>>> > plaintexts of even earlier transactions that produced the outputs
>>>> spent in
>>>> > those transactions, and so on, up until the issue (similar to
>>>> coinbase)
>>>> > transactions that created the initial private coins. Each new owner
>>>> of the
>>>> > coin will have to store its entire history, and when he spends the
>>>> coin, he
>>>> > forwards the entire history to the next owner and extends it with his
>>>> own
>>>> > transaction.
>>>> >
>>>> > If we apply the existing bitcoin design that allows multiple inputs
>>>> and
>>>> > multiple outputs per transaction, the history of ownership transfers
>>>> would
>>>> > grow exponentially. Indeed, if we take any regular bitcoin output
>>>> and try
>>>> > to track its history back to coinbase, our history will branch every
>>>> time
>>>> > we see a transaction that has more than one input (which is not
>>>> uncommon).
>>>> > After such a transaction (remember, we are traveling back in time),
>>>> we’ll
>>>> > have to track two or more histories, for each respective input. Those
>>>> > histories will branch again, and the total number of history entries
>>>> grows
>>>> > exponentially. For example, if every transaction had exactly two
>>>> inputs,
>>>> > the size of history would grow as 2^N where N is the number of steps
>>>> back
>>>> > in history.
>>>> >
>>>> > To avoid such rapid growth of ownership history (which is not only
>>>> > inconvenient to move, but also exposes too much private information
>>>> about
>>>> > previous owners of all the contributing coins), we will require each
>>>> > private transaction to have exactly one input (i.e. to consume
>>>> exactly one
>>>> > previous output). This means that when we track a coin’s history
>>>> back in
>>>> > time, it will no longer branch. It will grow linearly with the
>>>> number of
>>>> > transfers of ownership. If a user wants to combine several inputs,
>>>> he will
>>>> > have to send them as separate private transactions (technically,
>>>> several
>>>> > OP_RETURNs, which can be included in a single regular bitcoin
>>>> transaction).
>>>> >
>>>> > Thus, we are now forbidding any coin merges but still allowing coin
>>>> > splits. To avoid ultimate splitting into the dust, we will also
>>>> require
>>>> > that all private coins be issued in one of a small number of
>>>> > denominations. Only integer number of “banknotes” can be
>>>> transferred, the
>>>> > input and output amounts must therefore be divisible by the
>>>> denomination.
>>>> > For example, an input of amount 700, denomination 100, can be split
>>>> into
>>>> > outputs 400 and 300, but not into 450 and 250. To send a payment, the
>>>> > payer has to pick the unspent outputs of the highest denomination
>>>> first,
>>>> > then the second highest, and so on, like we already do when we pay in
>>>> cash.
>>>> >
>>>> > With fixed denominations and one input per transaction, coin histories
>>>> > still grow, but only linearly, which should not be a concern in
>>>> regard to
>>>> > scalability given that all relevant computing resources still grow
>>>> > exponentially. The histories need to be stored only by the current
>>>> owner
>>>> > of the coin, not every bitcoin node. This is a fairer allocation of
>>>> > costs. Regarding privacy, coin histories do expose private
>>>> transactions
>>>> > (or rather parts thereof, since a typical payment will likely consist
>>>> of
>>>> > several transactions due to one-input-per-transaction rule) of past
>>>> coin
>>>> > owners to the future ones, and that exposure grows linearly with
>>>> time, but
>>>> > it is still much much better than having every transaction
>>>> immediately on
>>>> > the public blockchain. Also, the value of this information for
>>>> potential
>>>> > adversaries arguably decreases with time.
>>>> >
>>>> > There is one technical nuance that I omitted above to avoid
>>>> distraction.
>>>> > Unlike regular bitcoin transactions, every output in a private
>>>> payment
>>>> > must also include a blinding factor, which is just a random string.
>>>> When
>>>> > the output is spent, the corresponding spend proof will therefore
>>>> depend on
>>>> > this blinding factor (remember that spend proof is just a hash of the
>>>> > output). Without a blinding factor, it would be feasible to
>>>> pre-image the
>>>> > spend proof and reveal the output being spent as the search space of
>>>> all
>>>> > possible outputs is rather small.
>>>> >
>>>> > To issue the new private coin, one can burn regular BTC by sending it
>>>> to
>>>> > one of several unspendable bitcoin addresses, one address per
>>>> denomination.
>>>> > Burning BTC would entitle one to an equal amount of the new private
>>>> coin,
>>>> > let’s call it *black bitcoin*, or *BBC*.
>>>> >
>>>> > Then BBC would be transferred from user to user by:
>>>> > 1. creating a private transaction, which consists of one input and
>>>> several
>>>> > outputs;
>>>> > 2. storing the hash of the transaction and the spend proof of the
>>>> consumed
>>>> > output into the blockchain in an OP_RETURN (the sender pays the
>>>> > corresponding fees in regular BTC)
>>>> > 3. sending the transaction, together with the history leading to its
>>>> input,
>>>> > directly to the payee over a private communication channel. The first
>>>> > entry of the history must be a bitcoin transaction that burned BTC to
>>>> issue
>>>> > an equal amount of BCC.
>>>> >
>>>> > To verify the payment, the payee:
>>>> > 1. makes sure that the amount of the input matches the sum of
>>>> outputs, and
>>>> > all are divisible by the denomination
>>>> > 2. calculates the hash of the private transaction
>>>> > 3. looks up an OP_RETURN that includes this hash and is signed by the
>>>> > payee. If there is more than one, the one that comes in the earlier
>>>> block
>>>> > prevails.
>>>> > 4. calculates the spend proof and makes sure that it is included in
>>>> the
>>>> > same OP_RETURN
>>>> > 5. makes sure the same spend proof is not included anywhere in the
>>>> same or
>>>> > earlier blocks (that is, the coin was not spent before). Only
>>>> transactions
>>>> > by the same author are searched.
>>>> > 6. repeats the same steps for every entry in the history, except the
>>>> first
>>>> > entry, which should be a valid burning transaction.
>>>> >
>>>> > To facilitate exchange of private transaction data, the bitcoin
>>>> network
>>>> > protocol can be extended with a new message type. Unfortunately, it
>>>> lacks
>>>> > encryption, hence private payments are really private only when
>>>> bitcoin is
>>>> > used over tor.
>>>> >
>>>> > There are a few limitations that ought to be mentioned:
>>>> > 1. After user A sends a private payment to user B, user A will know
>>>> what
>>>> > the spend proof is going to be when B decides to spend the coin.
>>>> > Therefore, A will know when the coin was spent by B, but nothing
>>>> more.
>>>> > Neither the new owner of the coin, nor its future movements will be
>>>> known
>>>> > to A.
>>>> > 2. Over time, larger outputs will likely be split into many smaller
>>>> > outputs, whose amounts are not much greater than their denominations.
>>>> > You’ll have to combine more inputs to send the same amount. When you
>>>> want
>>>> > to send a very large amount that is much greater than the highest
>>>> available
>>>> > denomination, you’ll have to send a lot of private transactions, your
>>>> > bitcoin transaction with so many OP_RETURNs will stand out, and their
>>>> > number will roughly indicate the total amount. This kind of privacy
>>>> > leakage, however it applies to a small number of users, is easy to
>>>> avoid by
>>>> > using multiple addresses and storing a relatively small amount on each
>>>> > address.
>>>> > 3. Exchanges and large merchants will likely accumulate large coin
>>>> > histories. Although fragmented, far from complete, and likely
>>>> outdated, it
>>>> > is still something to bear in mind.
>>>> >
>>>> > No hard or soft fork is required, BBC is just a separate privacy
>>>> preserving
>>>> > currency on top of bitcoin blockchain, and the same private keys and
>>>> > addresses are used for both BBC and the base currency BTC. Every BCC
>>>> > transaction must be enclosed into by a small BTC transaction that
>>>> stores
>>>> > the OP_RETURNs and pays for the fees.
>>>> >
>>>> > Are there any flaws in this design?
>>>> >
>>>> > Originally posted to BCT
>>>> https://bitcointalk.org/index.php?topic=1574508.0,
>>>> > but got no feedback so far, apparently everybody was consumed with
>>>> bitfinex
>>>> > drama and now mimblewimble.
>>>> >
>>>> > Tony
>>>>
>>>> > _______________________________________________
>>>> > bitcoin-dev mailing list
>>>> > bitcoin-dev at lists.linuxfoundation.org
>>>> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>>
>>>>
>>>> --
>>>> Henning Kopp
>>>> Institute of Distributed Systems
>>>> Ulm University, Germany
>>>>
>>>> Office: O27 - 3402
>>>> Phone: +49 731 50-24138
>>>> Web: http://www.uni-ulm.de/in/vs/~kopp
>>>>
>>>
>>> _______________________________________________
>>> 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/20160809/00d83f50/attachment-0001.html>;

📅 Original date posted:2016-08-08 📝 Original message:One ...

2023-06-07T17:52:28Z

In reply to nevent1q…e5xz
_________________________

📅 Original date posted:2016-08-08
📝 Original message:One more thought about why verification by miners may be needed.

Let's say Alice sends Bob a transaction, generating output C.

A troll, named Timothy, broadcasts a transaction with a random hash,
referencing C's output as its spend proof. The miners can't tell if it's
valid or not, and so they include the transaction in a block. Now Bob's
money is useless, because everyone can see the spend proof referenced and
thinks it has already been spent, even though the transaction that claims
it isn't valid.

Did I miss something that protects against this?

On Mon, Aug 8, 2016 at 4:42 PM Tony Churyumoff <tony991 at gmail.com> wrote:

> The whole point is in preventing every third party, including miners, from
> seeing the details of what is being spent and how. The burden of
> verification is shifted to the owners of the coin (which is fair).
>
> In fact we could have miners recognize spend proofs and check that the
> same spend proof is not entered into the blockchain more than once (which
> would be a sign of double spend), but it is not required. The coin owners
> can already do that themselves.
>
> 2016-08-09 0:41 GMT+03:00 James MacWhyte <macwhyte at gmail.com>:
>
>> Wouldn't you lose the ability to assume transactions in the blockchain
>> are verified as valid, since miners can't see the details of what is being
>> spent and how? I feel like this ability is bitcoin's greatest asset, and by
>> removing it you're creating an altcoin different enough to not be connected
>> to/supported by the main bitcoin project.
>>
>> On Mon, Aug 8, 2016, 09:13 Tony Churyumoff via bitcoin-dev <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>>> Hi Henning,
>>>
>>> 1. The fees are paid by the enclosing BTC transaction.
>>> 2. The hash is encoded into an OP_RETURN.
>>>
>>> > Regarding the blinding factor, I think you could just use HMAC.
>>> How exactly?
>>>
>>> Tony
>>>
>>>
>>> 2016-08-08 18:47 GMT+03:00 Henning Kopp <henning.kopp at uni-ulm.de>:
>>>
>>>> Hi Tony,
>>>>
>>>> I see some issues in your protocol.
>>>>
>>>> 1. How are mining fees handled?
>>>>
>>>> 2. Assume Alice sends Bob some Coins together with their history and
>>>> Bob checks that the history is correct. How does the hash of the txout
>>>> find its way into the blockchain?
>>>>
>>>> Regarding the blinding factor, I think you could just use HMAC.
>>>>
>>>> All the best
>>>> Henning
>>>>
>>>>
>>>> On Mon, Aug 08, 2016 at 06:30:21PM +0300, Tony Churyumoff via
>>>> bitcoin-dev wrote:
>>>> > This is a proposal about hiding the entire content of bitcoin
>>>> > transactions. It goes farther than CoinJoin and ring signatures,
>>>> which
>>>> > only obfuscate the transaction graph, and Confidential Transactions,
>>>> which
>>>> > only hide the amounts.
>>>> >
>>>> > The central idea of the proposed design is to hide the entire inputs
>>>> and
>>>> > outputs, and publish only the hash of inputs and outputs in the
>>>> > blockchain. The hash can be published as OP_RETURN. The plaintext of
>>>> > inputs and outputs is sent directly to the payee via a private
>>>> message, and
>>>> > never goes into the blockchain. The payee then calculates the hash
>>>> and
>>>> > looks it up in the blockchain to verify that the hash was indeed
>>>> published
>>>> > by the payer.
>>>> >
>>>> > Since the plaintext of the transaction is not published to the public
>>>> > blockchain, all validation work has to be done only by the user who
>>>> > receives the payment.
>>>> >
>>>> > To protect against double-spends, the payer also has to publish
>>>> another
>>>> > hash, which is the hash of the output being spent. We’ll call this
>>>> hash *spend
>>>> > proof*. Since the spend proof depends solely on the output being
>>>> spent,
>>>> > any attempt to spend the same output again will produce exactly the
>>>> same
>>>> > spend proof, and the payee will be able to see that, and will reject
>>>> the
>>>> > payment. If there are several outputs consumed by the same
>>>> transaction,
>>>> > the payer has to publish several spend proofs.
>>>> >
>>>> > To prove that the outputs being spent are valid, the payer also has
>>>> to send
>>>> > the plaintexts of the earlier transaction(s) that produced them, then
>>>> the
>>>> > plaintexts of even earlier transactions that produced the outputs
>>>> spent in
>>>> > those transactions, and so on, up until the issue (similar to
>>>> coinbase)
>>>> > transactions that created the initial private coins. Each new owner
>>>> of the
>>>> > coin will have to store its entire history, and when he spends the
>>>> coin, he
>>>> > forwards the entire history to the next owner and extends it with his
>>>> own
>>>> > transaction.
>>>> >
>>>> > If we apply the existing bitcoin design that allows multiple inputs
>>>> and
>>>> > multiple outputs per transaction, the history of ownership transfers
>>>> would
>>>> > grow exponentially. Indeed, if we take any regular bitcoin output
>>>> and try
>>>> > to track its history back to coinbase, our history will branch every
>>>> time
>>>> > we see a transaction that has more than one input (which is not
>>>> uncommon).
>>>> > After such a transaction (remember, we are traveling back in time),
>>>> we’ll
>>>> > have to track two or more histories, for each respective input. Those
>>>> > histories will branch again, and the total number of history entries
>>>> grows
>>>> > exponentially. For example, if every transaction had exactly two
>>>> inputs,
>>>> > the size of history would grow as 2^N where N is the number of steps
>>>> back
>>>> > in history.
>>>> >
>>>> > To avoid such rapid growth of ownership history (which is not only
>>>> > inconvenient to move, but also exposes too much private information
>>>> about
>>>> > previous owners of all the contributing coins), we will require each
>>>> > private transaction to have exactly one input (i.e. to consume
>>>> exactly one
>>>> > previous output). This means that when we track a coin’s history
>>>> back in
>>>> > time, it will no longer branch. It will grow linearly with the
>>>> number of
>>>> > transfers of ownership. If a user wants to combine several inputs,
>>>> he will
>>>> > have to send them as separate private transactions (technically,
>>>> several
>>>> > OP_RETURNs, which can be included in a single regular bitcoin
>>>> transaction).
>>>> >
>>>> > Thus, we are now forbidding any coin merges but still allowing coin
>>>> > splits. To avoid ultimate splitting into the dust, we will also
>>>> require
>>>> > that all private coins be issued in one of a small number of
>>>> > denominations. Only integer number of “banknotes” can be
>>>> transferred, the
>>>> > input and output amounts must therefore be divisible by the
>>>> denomination.
>>>> > For example, an input of amount 700, denomination 100, can be split
>>>> into
>>>> > outputs 400 and 300, but not into 450 and 250. To send a payment, the
>>>> > payer has to pick the unspent outputs of the highest denomination
>>>> first,
>>>> > then the second highest, and so on, like we already do when we pay in
>>>> cash.
>>>> >
>>>> > With fixed denominations and one input per transaction, coin histories
>>>> > still grow, but only linearly, which should not be a concern in
>>>> regard to
>>>> > scalability given that all relevant computing resources still grow
>>>> > exponentially. The histories need to be stored only by the current
>>>> owner
>>>> > of the coin, not every bitcoin node. This is a fairer allocation of
>>>> > costs. Regarding privacy, coin histories do expose private
>>>> transactions
>>>> > (or rather parts thereof, since a typical payment will likely consist
>>>> of
>>>> > several transactions due to one-input-per-transaction rule) of past
>>>> coin
>>>> > owners to the future ones, and that exposure grows linearly with
>>>> time, but
>>>> > it is still much much better than having every transaction
>>>> immediately on
>>>> > the public blockchain. Also, the value of this information for
>>>> potential
>>>> > adversaries arguably decreases with time.
>>>> >
>>>> > There is one technical nuance that I omitted above to avoid
>>>> distraction.
>>>> > Unlike regular bitcoin transactions, every output in a private
>>>> payment
>>>> > must also include a blinding factor, which is just a random string.
>>>> When
>>>> > the output is spent, the corresponding spend proof will therefore
>>>> depend on
>>>> > this blinding factor (remember that spend proof is just a hash of the
>>>> > output). Without a blinding factor, it would be feasible to
>>>> pre-image the
>>>> > spend proof and reveal the output being spent as the search space of
>>>> all
>>>> > possible outputs is rather small.
>>>> >
>>>> > To issue the new private coin, one can burn regular BTC by sending it
>>>> to
>>>> > one of several unspendable bitcoin addresses, one address per
>>>> denomination.
>>>> > Burning BTC would entitle one to an equal amount of the new private
>>>> coin,
>>>> > let’s call it *black bitcoin*, or *BBC*.
>>>> >
>>>> > Then BBC would be transferred from user to user by:
>>>> > 1. creating a private transaction, which consists of one input and
>>>> several
>>>> > outputs;
>>>> > 2. storing the hash of the transaction and the spend proof of the
>>>> consumed
>>>> > output into the blockchain in an OP_RETURN (the sender pays the
>>>> > corresponding fees in regular BTC)
>>>> > 3. sending the transaction, together with the history leading to its
>>>> input,
>>>> > directly to the payee over a private communication channel. The first
>>>> > entry of the history must be a bitcoin transaction that burned BTC to
>>>> issue
>>>> > an equal amount of BCC.
>>>> >
>>>> > To verify the payment, the payee:
>>>> > 1. makes sure that the amount of the input matches the sum of
>>>> outputs, and
>>>> > all are divisible by the denomination
>>>> > 2. calculates the hash of the private transaction
>>>> > 3. looks up an OP_RETURN that includes this hash and is signed by the
>>>> > payee. If there is more than one, the one that comes in the earlier
>>>> block
>>>> > prevails.
>>>> > 4. calculates the spend proof and makes sure that it is included in
>>>> the
>>>> > same OP_RETURN
>>>> > 5. makes sure the same spend proof is not included anywhere in the
>>>> same or
>>>> > earlier blocks (that is, the coin was not spent before). Only
>>>> transactions
>>>> > by the same author are searched.
>>>> > 6. repeats the same steps for every entry in the history, except the
>>>> first
>>>> > entry, which should be a valid burning transaction.
>>>> >
>>>> > To facilitate exchange of private transaction data, the bitcoin
>>>> network
>>>> > protocol can be extended with a new message type. Unfortunately, it
>>>> lacks
>>>> > encryption, hence private payments are really private only when
>>>> bitcoin is
>>>> > used over tor.
>>>> >
>>>> > There are a few limitations that ought to be mentioned:
>>>> > 1. After user A sends a private payment to user B, user A will know
>>>> what
>>>> > the spend proof is going to be when B decides to spend the coin.
>>>> > Therefore, A will know when the coin was spent by B, but nothing
>>>> more.
>>>> > Neither the new owner of the coin, nor its future movements will be
>>>> known
>>>> > to A.
>>>> > 2. Over time, larger outputs will likely be split into many smaller
>>>> > outputs, whose amounts are not much greater than their denominations.
>>>> > You’ll have to combine more inputs to send the same amount. When you
>>>> want
>>>> > to send a very large amount that is much greater than the highest
>>>> available
>>>> > denomination, you’ll have to send a lot of private transactions, your
>>>> > bitcoin transaction with so many OP_RETURNs will stand out, and their
>>>> > number will roughly indicate the total amount. This kind of privacy
>>>> > leakage, however it applies to a small number of users, is easy to
>>>> avoid by
>>>> > using multiple addresses and storing a relatively small amount on each
>>>> > address.
>>>> > 3. Exchanges and large merchants will likely accumulate large coin
>>>> > histories. Although fragmented, far from complete, and likely
>>>> outdated, it
>>>> > is still something to bear in mind.
>>>> >
>>>> > No hard or soft fork is required, BBC is just a separate privacy
>>>> preserving
>>>> > currency on top of bitcoin blockchain, and the same private keys and
>>>> > addresses are used for both BBC and the base currency BTC. Every BCC
>>>> > transaction must be enclosed into by a small BTC transaction that
>>>> stores
>>>> > the OP_RETURNs and pays for the fees.
>>>> >
>>>> > Are there any flaws in this design?
>>>> >
>>>> > Originally posted to BCT
>>>> https://bitcointalk.org/index.php?topic=1574508.0,
>>>> > but got no feedback so far, apparently everybody was consumed with
>>>> bitfinex
>>>> > drama and now mimblewimble.
>>>> >
>>>> > Tony
>>>>
>>>> > _______________________________________________
>>>> > bitcoin-dev mailing list
>>>> > bitcoin-dev at lists.linuxfoundation.org
>>>> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>>
>>>>
>>>> --
>>>> Henning Kopp
>>>> Institute of Distributed Systems
>>>> Ulm University, Germany
>>>>
>>>> Office: O27 - 3402
>>>> Phone: +49 731 50-24138
>>>> Web: http://www.uni-ulm.de/in/vs/~kopp
>>>>
>>>
>>> _______________________________________________
>>> 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/20160809/09443165/attachment-0001.html>;

📅 Original date posted:2016-08-08 📝 Original ...

2023-06-07T17:52:25Z

In reply to nevent1q…wnxx
_________________________

📅 Original date posted:2016-08-08
📝 Original message:Wouldn't you lose the ability to assume transactions in the blockchain are
verified as valid, since miners can't see the details of what is being
spent and how? I feel like this ability is bitcoin's greatest asset, and by
removing it you're creating an altcoin different enough to not be connected
to/supported by the main bitcoin project.

On Mon, Aug 8, 2016, 09:13 Tony Churyumoff via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> Hi Henning,
>
> 1. The fees are paid by the enclosing BTC transaction.
> 2. The hash is encoded into an OP_RETURN.
>
> > Regarding the blinding factor, I think you could just use HMAC.
> How exactly?
>
> Tony
>
>
> 2016-08-08 18:47 GMT+03:00 Henning Kopp <henning.kopp at uni-ulm.de>:
>
>> Hi Tony,
>>
>> I see some issues in your protocol.
>>
>> 1. How are mining fees handled?
>>
>> 2. Assume Alice sends Bob some Coins together with their history and
>> Bob checks that the history is correct. How does the hash of the txout
>> find its way into the blockchain?
>>
>> Regarding the blinding factor, I think you could just use HMAC.
>>
>> All the best
>> Henning
>>
>>
>> On Mon, Aug 08, 2016 at 06:30:21PM +0300, Tony Churyumoff via bitcoin-dev
>> wrote:
>> > This is a proposal about hiding the entire content of bitcoin
>> > transactions. It goes farther than CoinJoin and ring signatures, which
>> > only obfuscate the transaction graph, and Confidential Transactions,
>> which
>> > only hide the amounts.
>> >
>> > The central idea of the proposed design is to hide the entire inputs and
>> > outputs, and publish only the hash of inputs and outputs in the
>> > blockchain. The hash can be published as OP_RETURN. The plaintext of
>> > inputs and outputs is sent directly to the payee via a private message,
>> and
>> > never goes into the blockchain. The payee then calculates the hash and
>> > looks it up in the blockchain to verify that the hash was indeed
>> published
>> > by the payer.
>> >
>> > Since the plaintext of the transaction is not published to the public
>> > blockchain, all validation work has to be done only by the user who
>> > receives the payment.
>> >
>> > To protect against double-spends, the payer also has to publish another
>> > hash, which is the hash of the output being spent. We’ll call this
>> hash *spend
>> > proof*. Since the spend proof depends solely on the output being spent,
>> > any attempt to spend the same output again will produce exactly the same
>> > spend proof, and the payee will be able to see that, and will reject the
>> > payment. If there are several outputs consumed by the same transaction,
>> > the payer has to publish several spend proofs.
>> >
>> > To prove that the outputs being spent are valid, the payer also has to
>> send
>> > the plaintexts of the earlier transaction(s) that produced them, then
>> the
>> > plaintexts of even earlier transactions that produced the outputs spent
>> in
>> > those transactions, and so on, up until the issue (similar to coinbase)
>> > transactions that created the initial private coins. Each new owner of
>> the
>> > coin will have to store its entire history, and when he spends the
>> coin, he
>> > forwards the entire history to the next owner and extends it with his
>> own
>> > transaction.
>> >
>> > If we apply the existing bitcoin design that allows multiple inputs and
>> > multiple outputs per transaction, the history of ownership transfers
>> would
>> > grow exponentially. Indeed, if we take any regular bitcoin output and
>> try
>> > to track its history back to coinbase, our history will branch every
>> time
>> > we see a transaction that has more than one input (which is not
>> uncommon).
>> > After such a transaction (remember, we are traveling back in time),
>> we’ll
>> > have to track two or more histories, for each respective input. Those
>> > histories will branch again, and the total number of history entries
>> grows
>> > exponentially. For example, if every transaction had exactly two
>> inputs,
>> > the size of history would grow as 2^N where N is the number of steps
>> back
>> > in history.
>> >
>> > To avoid such rapid growth of ownership history (which is not only
>> > inconvenient to move, but also exposes too much private information
>> about
>> > previous owners of all the contributing coins), we will require each
>> > private transaction to have exactly one input (i.e. to consume exactly
>> one
>> > previous output). This means that when we track a coin’s history back
>> in
>> > time, it will no longer branch. It will grow linearly with the number
>> of
>> > transfers of ownership. If a user wants to combine several inputs, he
>> will
>> > have to send them as separate private transactions (technically, several
>> > OP_RETURNs, which can be included in a single regular bitcoin
>> transaction).
>> >
>> > Thus, we are now forbidding any coin merges but still allowing coin
>> > splits. To avoid ultimate splitting into the dust, we will also require
>> > that all private coins be issued in one of a small number of
>> > denominations. Only integer number of “banknotes” can be transferred,
>> the
>> > input and output amounts must therefore be divisible by the
>> denomination.
>> > For example, an input of amount 700, denomination 100, can be split into
>> > outputs 400 and 300, but not into 450 and 250. To send a payment, the
>> > payer has to pick the unspent outputs of the highest denomination first,
>> > then the second highest, and so on, like we already do when we pay in
>> cash.
>> >
>> > With fixed denominations and one input per transaction, coin histories
>> > still grow, but only linearly, which should not be a concern in regard
>> to
>> > scalability given that all relevant computing resources still grow
>> > exponentially. The histories need to be stored only by the current
>> owner
>> > of the coin, not every bitcoin node. This is a fairer allocation of
>> > costs. Regarding privacy, coin histories do expose private transactions
>> > (or rather parts thereof, since a typical payment will likely consist of
>> > several transactions due to one-input-per-transaction rule) of past coin
>> > owners to the future ones, and that exposure grows linearly with time,
>> but
>> > it is still much much better than having every transaction immediately
>> on
>> > the public blockchain. Also, the value of this information for
>> potential
>> > adversaries arguably decreases with time.
>> >
>> > There is one technical nuance that I omitted above to avoid distraction.
>> > Unlike regular bitcoin transactions, every output in a private payment
>> > must also include a blinding factor, which is just a random string.
>> When
>> > the output is spent, the corresponding spend proof will therefore
>> depend on
>> > this blinding factor (remember that spend proof is just a hash of the
>> > output). Without a blinding factor, it would be feasible to pre-image
>> the
>> > spend proof and reveal the output being spent as the search space of all
>> > possible outputs is rather small.
>> >
>> > To issue the new private coin, one can burn regular BTC by sending it to
>> > one of several unspendable bitcoin addresses, one address per
>> denomination.
>> > Burning BTC would entitle one to an equal amount of the new private
>> coin,
>> > let’s call it *black bitcoin*, or *BBC*.
>> >
>> > Then BBC would be transferred from user to user by:
>> > 1. creating a private transaction, which consists of one input and
>> several
>> > outputs;
>> > 2. storing the hash of the transaction and the spend proof of the
>> consumed
>> > output into the blockchain in an OP_RETURN (the sender pays the
>> > corresponding fees in regular BTC)
>> > 3. sending the transaction, together with the history leading to its
>> input,
>> > directly to the payee over a private communication channel. The first
>> > entry of the history must be a bitcoin transaction that burned BTC to
>> issue
>> > an equal amount of BCC.
>> >
>> > To verify the payment, the payee:
>> > 1. makes sure that the amount of the input matches the sum of outputs,
>> and
>> > all are divisible by the denomination
>> > 2. calculates the hash of the private transaction
>> > 3. looks up an OP_RETURN that includes this hash and is signed by the
>> > payee. If there is more than one, the one that comes in the earlier
>> block
>> > prevails.
>> > 4. calculates the spend proof and makes sure that it is included in the
>> > same OP_RETURN
>> > 5. makes sure the same spend proof is not included anywhere in the same
>> or
>> > earlier blocks (that is, the coin was not spent before). Only
>> transactions
>> > by the same author are searched.
>> > 6. repeats the same steps for every entry in the history, except the
>> first
>> > entry, which should be a valid burning transaction.
>> >
>> > To facilitate exchange of private transaction data, the bitcoin network
>> > protocol can be extended with a new message type. Unfortunately, it
>> lacks
>> > encryption, hence private payments are really private only when bitcoin
>> is
>> > used over tor.
>> >
>> > There are a few limitations that ought to be mentioned:
>> > 1. After user A sends a private payment to user B, user A will know what
>> > the spend proof is going to be when B decides to spend the coin.
>> > Therefore, A will know when the coin was spent by B, but nothing more.
>> > Neither the new owner of the coin, nor its future movements will be
>> known
>> > to A.
>> > 2. Over time, larger outputs will likely be split into many smaller
>> > outputs, whose amounts are not much greater than their denominations.
>> > You’ll have to combine more inputs to send the same amount. When you
>> want
>> > to send a very large amount that is much greater than the highest
>> available
>> > denomination, you’ll have to send a lot of private transactions, your
>> > bitcoin transaction with so many OP_RETURNs will stand out, and their
>> > number will roughly indicate the total amount. This kind of privacy
>> > leakage, however it applies to a small number of users, is easy to
>> avoid by
>> > using multiple addresses and storing a relatively small amount on each
>> > address.
>> > 3. Exchanges and large merchants will likely accumulate large coin
>> > histories. Although fragmented, far from complete, and likely
>> outdated, it
>> > is still something to bear in mind.
>> >
>> > No hard or soft fork is required, BBC is just a separate privacy
>> preserving
>> > currency on top of bitcoin blockchain, and the same private keys and
>> > addresses are used for both BBC and the base currency BTC. Every BCC
>> > transaction must be enclosed into by a small BTC transaction that stores
>> > the OP_RETURNs and pays for the fees.
>> >
>> > Are there any flaws in this design?
>> >
>> > Originally posted to BCT
>> https://bitcointalk.org/index.php?topic=1574508.0,
>> > but got no feedback so far, apparently everybody was consumed with
>> bitfinex
>> > drama and now mimblewimble.
>> >
>> > Tony
>>
>> > _______________________________________________
>> > bitcoin-dev mailing list
>> > bitcoin-dev at lists.linuxfoundation.org
>> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>> --
>> Henning Kopp
>> Institute of Distributed Systems
>> Ulm University, Germany
>>
>> Office: O27 - 3402
>> Phone: +49 731 50-24138
>> Web: http://www.uni-ulm.de/in/vs/~kopp
>>
>
> _______________________________________________
> 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/20160808/0bfeb179/attachment-0001.html>;

📅 Original date posted:2016-08-03 📝 Original message:> ...

2023-06-07T17:52:10Z

In reply to nevent1q…y84f
_________________________

📅 Original date posted:2016-08-03
📝 Original message:> Most people?

I'm talking about services that are built to handle multiple accounts, like
exchanges and payment processors.

> You realize that you need to set up bitcoind to make an
> external request on every reception of funds on any address in the whole
> system.
>
No, you don't. You can write a script that repeatedly asks bitcoind for the
block height, and when it increments you know a new block has been
confirmed. So then you request the transaction list from the latest block,
and check each confirmed transaction against your database of receive/watch
addresses. If there is a match, you record the transaction info in your
database so you can use it as an input later to create a spend transaction.

You could also use something like Bitpay's Insight to make interfacing with
bitcoind easier.

> It can't possibly scale, also we don't have the time to build an account
> system for every bitcoind service. Imagine the loss of time, it's huge and
> grows exponentially with adoption, or rather there is no adoption!
>
What are you trying to build?

> Also external systems are not be trusted, specially not bitgo, did you
> read any news in the last 24 hours?
>
I prefer to wait until all facts are in before I pass judgement. I think
BitGo is an excellent company with a great track record. If used properly,
they are extremely secure. If you are worried about storing funds there
long time, don't--just use them to detect incoming payments and move your
funds elsewhere for long term storage.

> /m
>
> On Wed, 3 Aug 2016, James MacWhyte wrote:
>
> >
> > From what I've seen, most people build their own account system
> separately
> > (including fee management) and just use bitcoind to send, receive, and
> > verify transactions. It's not meant to be a drop-in solution for running
> an
> > entire bitcoin deposit and withdrawal system, it just provides the bare
> > tools required to build your own. If you need a pre-built solution, there
> > are companies that provide those types of services as a platform (BitGo,
> for
> > example).
> >
> >
> > On Wed, Aug 3, 2016, 11:25 Marc Larue via bitcoin-dev
> > <bitcoin-dev at lists.linuxfoundation.org> wrote:
> > Hi,
> >
> > I have 2 problems with bitcoind that separately are not a
> > problem but
> > together they make the platform unusable for many projects.
> >
> > If I have accounts I need to make sure the account holders do
> > not
> > overcharge their account. To do this I can now use
> > "createrawtransaction()
> > + fundrawtransaction() + signrawtransaction()" and then make
> > sure the
> > transaction can be paid by an account.
> >
> > But since you deprecated the accounts and there is no
> > sendrawtransactionfrom() method; I either have to build my own
> > account
> > system (this is no picknick btw, since you need to track all
> > incoming
> > funds to all addresses and having an integrated account system
> > in bitcoind
> > is 100% necessary to do this effectively).
> >
> > Or I might be able to go ahead and speculate that you will not
> > be able to
> > untangle the account code and hack my bitcoind to have a
> > sendfrom with a
> > fixed fee parameter that overrides the size multiplication and I
> > just do
> > the math before I send hoping that the transactions go through
> > (this is
> > bad but better than having accounts overcharge because they send
> > dust that
> > induce high fees).
> >
> > I understand the privacy problems with using accounts for
> > off-chain
> > microstransactions but currently it's the best workable option.
> >
> > I hope you understand that I'm not trolling here, I have been
> > mining since
> > 2011 on FPGAs and built bitcoinbankbook.com 2 years ago. When I
> > descovered
> > that once transactions will require fees (back then they didn't)
> > and that
> > your system is not able to handle fees with accounts, I stopped
> > developing
> > everything related to bitcoin.
> >
> > There are probably 100s if not 1000s of developers in the same
> > situation.
> >
> > You can't just deprecate accounts like that because nobody likes
> > the code.
> > Without accounts bitcoind is only a person-to-person manual
> > client.
> >
> > To build many-to-many automatic "organisations" on top of
> > bitcoind you
> > need accounts and you need fees that are predictable.
> >
> > Kind Regards,
> >
> > /marc
> > _______________________________________________
> > 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/20160804/f3ae45ea/attachment.html>;

📅 Original date posted:2016-08-03 📝 Original ...

2023-06-07T17:52:10Z

In reply to nevent1q…hkah
_________________________

📅 Original date posted:2016-08-03
📝 Original message:>From what I've seen, most people build their own account system separately
(including fee management) and just use bitcoind to send, receive, and
verify transactions. It's not meant to be a drop-in solution for running an
entire bitcoin deposit and withdrawal system, it just provides the bare
tools required to build your own. If you need a pre-built solution, there
are companies that provide those types of services as a platform (BitGo,
for example).

On Wed, Aug 3, 2016, 11:25 Marc Larue via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> Hi,
>
> I have 2 problems with bitcoind that separately are not a problem but
> together they make the platform unusable for many projects.
>
> If I have accounts I need to make sure the account holders do not
> overcharge their account. To do this I can now use "createrawtransaction()
> + fundrawtransaction() + signrawtransaction()" and then make sure the
> transaction can be paid by an account.
>
> But since you deprecated the accounts and there is no
> sendrawtransactionfrom() method; I either have to build my own account
> system (this is no picknick btw, since you need to track all incoming
> funds to all addresses and having an integrated account system in bitcoind
> is 100% necessary to do this effectively).
>
> Or I might be able to go ahead and speculate that you will not be able to
> untangle the account code and hack my bitcoind to have a sendfrom with a
> fixed fee parameter that overrides the size multiplication and I just do
> the math before I send hoping that the transactions go through (this is
> bad but better than having accounts overcharge because they send dust that
> induce high fees).
>
> I understand the privacy problems with using accounts for off-chain
> microstransactions but currently it's the best workable option.
>
> I hope you understand that I'm not trolling here, I have been mining since
> 2011 on FPGAs and built bitcoinbankbook.com 2 years ago. When I descovered
> that once transactions will require fees (back then they didn't) and that
> your system is not able to handle fees with accounts, I stopped developing
> everything related to bitcoin.
>
> There are probably 100s if not 1000s of developers in the same situation.
>
> You can't just deprecate accounts like that because nobody likes the code.
> Without accounts bitcoind is only a person-to-person manual client.
>
> To build many-to-many automatic "organisations" on top of bitcoind you
> need accounts and you need fees that are predictable.
>
> Kind Regards,
>
> /marc
> _______________________________________________
> 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/20160803/dce3245a/attachment.html>;

📅 Original date posted:2016-07-05 📝 Original ...

2023-06-07T17:51:54Z

In reply to nevent1q…ak2w
_________________________

📅 Original date posted:2016-07-05
📝 Original message:I'm curious to hear the answers to the questions Luke asked earlier. I also
read through the documentation and wasn't convinced it was thought out well
enough to actually build something on top of, but there's no reason it
can't get a number as a work-in-progress.

I hope it does continue to get worked on, though. The lack of response or
discussion worries me that it might become an abandoned project.

On Tue, Jul 5, 2016, 18:32 Luke Dashjr via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> On Tuesday, July 05, 2016 5:46:36 PM Peter Todd wrote:
> > On Thu, May 26, 2016 at 03:53:04AM +0000, Luke Dashjr via bitcoin-dev
> wrote:
> > > On Thursday, May 26, 2016 2:50:26 AM Nicolas Dorier via bitcoin-dev
> wrote:
> > > > Author: Flavien Charlon <flavien at charlon.net>
> >
> > What's the status of this BIP? Will it be assigned?
>
> I was waiting for clarification on the Author thing, but Nicholas hasn't
> responded yet. I am unaware of any reason NOT to assign it, and there
> appear
> to be no objections, so let's call it BIP 160.
>
> 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/20160706/bbb89dc6/attachment.html>;

📅 Original date posted:2016-06-22 📝 Original ...

2023-06-07T17:51:29Z

In reply to nevent1q…vqht
_________________________

📅 Original date posted:2016-06-22
📝 Original message:Thomas,

I like your idea about expanding Bitcoin URI's to include signatures. For
BIP75 store and forward servers we are already thinking the DNS record
would have the user's public key as well as the URL of their store and
forward endpoint, so as soon as that becomes a standard you could use it
just for the public key part. Expanding the Bitcoin URI should be done as
well, for people who want to go the simpler route and not rely on servers.

Erik, Andy, everyone else,

I don't understand why subscriptions would need to be built into the
protocol. With BIP75 the merchant could automatically issue a
PaymentRequest message every X amount of time, and the customer's wallet
would either display the request like normal or be set to pre-authorize
requests from the merchant. If the merchant goes out of business, the
requests would stop coming. This sounds like a UI issue and not a
protocol-level requirement.

If you think I'm wrong, please explain why :)

On Wed, Jun 22, 2016 at 12:35 PM Erik Aronesty via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> - Payment channels seem clearly inappropriate for things like monthly
> subscriptions, the use of nlocktime, etc.
>
> - Merchants cannot send requests to users for future payments, because
> users don't run servers that they can connect to. That's why BIP0070 works
> the way it does.
>
> - Need to have an interval for subscriptions, at a minimum, and stored in
> the wallet so next months payment can go out on time
>
> - Support for varying currency conversion needs to be baked in to
> wallets. Fortunately, by adding advisory subscription info to the
> paymentrequest, this is left up to the wallet to
> secure/validate/repeat/convert/etc. as needed for each subscription.
>
> - The UI you describe is nice - but not unique to the solution.
>
>
>
>
> On Wed, Jun 22, 2016 at 12:20 PM, Andy Schroder <info at andyschroder.com>
> wrote:
>
>> I understand the need for people to make repeated payments to individuals
>> in real life that they know, without the payee every even taking the effort
>> to make a formal payment request (say you're just paying a family member of
>> friend back for picking something up for you at the store, and you've
>> already payed them many times before).
>>
>> For a subscription, wouldn't it be better to promote payment channels or
>> just send another payment request? I've been brainstorming recently about a
>> model where service providers could deliver invoices, receipts, and payment
>> requests in a standardized and secure way. In addition to having a send,
>> receive, and transaction history tab in your bitcoin wallet, you'd also
>> have an open payment channels tab (which would include all applications on
>> your computer that have an open real time payment channel, such as a wifi
>> access point, web browser, voip provider, etc.), as well as a "bills to
>> pay" tab. Since everything would be automated and consolidated locally, you
>> wouldn't have to deal with logging into a million different websites to get
>> the bills and then pay them. If it were this easy, why would you ever want
>> to do a recurring payment from a single payment request? I understand why
>> you may think you want to given current work flows, but I'm wondering if it
>> may be better to just skip over to a completely better way of doing things.
>>
>>
>> Andy Schroder
>>
>>
>> On 06/22/2016 11:30 AM, Erik Aronesty wrote:
>>
>>> My conclusion at the bottom of that post was to keep BIP 75 the same,
>>> don't change a bit, and stick any subscription information (future payment
>>> schedule) in the PaymentACK. Then the wallet then re-initiates an invoice
>>> (unattended or attended.. up to the user), after the subscription interval
>>> is passed. Subscriptions are pretty important for Bitcoin to be used as a
>>> real payment system.
>>>
>>
>>
>>
> _______________________________________________
> 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/20160622/ebc7af2e/attachment-0001.html>;

📅 Original date posted:2016-06-24 📝 Original message:> ...

2023-06-07T17:51:26Z

In reply to nevent1q…nrrx
_________________________

📅 Original date posted:2016-06-24
📝 Original message:> Clearly the primary purpose of BIP0075 is to enshrine a DNSSEC protocol
> for giving wallet addresses memorable names.
>
>
I can't tell if you're being sarcastic or not, but if you aren't, I don't
think this is an accurate description at all. BIP75 is, at its most
simplest, nothing more than an encrypted/encapsulated version of BIP70. All
we did was make it safe for people to exchange BIP70 messages through an
intermediary.

The only identity information included in BIP75 is the pki_data field,
which wasn't even introduced in BIP75--it was already in BIP70. I'm
guessing Peter would also have us remove BIP70 altogether?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160624/4fda853a/attachment.html>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PastedGraphic-1.tiff
Type: image/tiff
Size: 10972 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160624/4fda853a/attachment.tiff>;

📅 Original date posted:2016-06-21 📝 Original message:> ...

2023-06-07T17:51:21Z

In reply to nevent1q…a7k6
_________________________

📅 Original date posted:2016-06-21
📝 Original message:> Note that "client supplied identification" is being pushed for AML/KYC
> compliance, e.g. Netki's AML/KYC compliance product:
>
>
> http://www.coindesk.com/blockchain-identity-company-netki-launch-ssl-certificate-blockchain/
>
> This is an extremely undesirable feature to be baking into standards given
> it's
> negative impact on fungibility and privacy; we should not be adopting
> standards
> with AML/KYC support, for much the same reasons that the W3C should not be
> standardizing DRM.
>
>
KYC isn't the only use case. There are other situations in which you would
want to confirm who is sending you money. Making it *required* would of
course be a horrible idea, but allowing people to identify themselves, in
many cases with an online-only identity that isn't tied to their real world
identity, will be very useful to newly-developing use cases.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160621/6984221f/attachment.html>;

📅 Original date posted:2016-06-21 📝 Original message:Thanks ...

2023-06-07T17:51:20Z

In reply to nevent1q…nymc
_________________________

📅 Original date posted:2016-06-21
📝 Original message:Thanks for starting this discussion, Erik.

> Should this be a new BIP? I know netki's BIP75 is out there - but I think
> it's too specific and too reliant on the domain name system.
>

This is not quite accurate. BIP75 is designed to be independent of any name
resolution system. You could use it with a static URL that you share, for
example, or even use it to implement a mesh-network payment system over
bluetooth. Netki's wallet names do use DNS, but that isn't related to this
discussion.

What BIP75 *does* do is provide a way for a client to get a new payment
address for every payment. I personally think it is better than BIP47 for
the uses you mentioned (subscriptions, etc).

I'm glad you brought up identity methods other than x509. At breadwallet we
are thinking about how to establish the most universal system, and letting
users identify themselves with any of a selection of identity systems is
ideal. I think the pki_data slot should be constantly expanded to allow new
identity types, but they should be explained/standardized in the BIPs that
add them and use universal names. "netki://" wouldn't be appropriate, for
example, if their method is open sourced and possibly used by others--it
should instead be given a product name like "dnswallet://" or something
more clever.

James
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160621/316a6995/attachment.html>;

📅 Original date posted:2016-05-20 📝 Original ...

2023-06-07T17:50:55Z

In reply to nevent1q…mrkt
_________________________

📅 Original date posted:2016-05-20
📝 Original message:Matthew,

Other than gambling, do you have any specific examples of how this could be
useful?

On Fri, May 20, 2016, 20:34 Johnson Lau via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> Using the hash of multiple blocks does not make it any safer. The miner of
> the last block always determines the results, by knowing the hashes of all
> previous blocks.
>
>
> == Security
>
> Pay-to-script-hash can be used to protect the details of contracts that
> use OP_PRANDOM from the prying eyes of miners. However, since there is also
> a non-zero risk that a participant in a contract may attempt to bribe a
> miner the inclusion of multiple block hashes as a source of randomness is a
> must. Every miner would effectively need to be bribed to ensure control
> over the results of the random numbers, which is already very unlikely. The
> risk approaches zero as N goes up.
>
>
> _______________________________________________
> 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/20160520/5a5078fc/attachment.html>;

📅 Original date posted:2016-05-06 📝 Original message:Hi ...

2023-06-07T17:50:24Z

In reply to nevent1q…xda0
_________________________

📅 Original date posted:2016-05-06
📝 Original message:Hi all,

We've made some significant changes to BIP75 which we think simplify things
greatly:

Instead of introducing encrypted versions of all BIP70 messages
(EncryptedPaymentRequest, EncryptedPayment, etc), we have defined a generic
EncryptedProtocolMessage type which is essentially a wrapper that enables
encryption for all existing BIP70 messages. This reduces the number of new
messages we are defining and makes it easier to add new message types in
the future.

We've also decided to use AES-GCM instead of AES-CBC, which eliminates the
need for the verification hash.

A pull request has been submitted, which can be seen here:
https://github.com/bitcoin/bips/pull/385

All comments are welcome. Thank you!

James
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160506/ff43d148/attachment.html>;

📅 Original date posted:2016-03-27 📝 Original message:On ...

2023-06-07T17:49:59Z

In reply to nevent1q…mytg
_________________________

📅 Original date posted:2016-03-27
📝 Original message:On Sun, Mar 27, 2016 at 5:49 AM Jonas Schnelli via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

>
> > I guess my question didn't get across.
> >
> > Why would you want to make your usecase do connections over the
> > peer2peer
> > (net.cpp) connection at all?
> >
> > Mixing messages that are being sent to everyone and encrypted
> > messages is
> > asking for trouble.
> > Making your private connection out-of-band would work much better.
> >
> >
> > I agree doing it out-of-band is the easiest solution for people who need
> > this privacy right now, but I do like the idea of adding this feature as
> > the number of SPV wallets is going to increase. I think the best way to
> > organize things would be to give encrypted messages their own port
> > number, similar to how http vs. https works.
>
> I'm not sure if different ports would make sense. I can't see a benefit
> (happy if someone can convince me).
> How would this affect p2p address management (address relay)? Wouldn't
> this require to extend the current address message to support two port
> numbers?
>
> I'm assuming clients that connect with encryption don't want to use
unencrypted connections, and are only interested in other peers that
support encryption. From their perspective, it is quite inefficient to get
a generic list of peers and then have to connect to each one searching for
those that accept encryption. If we use port numbers, we can assume any
connection that comes on the encrypted port is only interested in encrypted
communication, so a getaddr to an encrypted port would only return a list
of other encryption-capable peers.

This isn't an issue if the plan is to require all peers to support
encryption, and we assume the majority of the network will upgrade before
too long.

>
> > We don't want two networks to develop, separated by which nodes support
> > encryption and which don't, so ideally nodes would rebroadcast messages
> > they receive on both (encrypted and non-encrypted) channels. This would
> > essentially double the required bandwidth of the network, which is
> > something to think about.
>
> It can be the same "p2p network". The only difference would be, that
> once two peers has negotiated encryption, the whole traffic between
> _these two peers_, and _only_ these two pears, would be encrypted (would
> _not_ affect traffic to/from other peers).
>
>
You're right, there would not be an increase in bandwidth. Please forget I
said that :) But following the logic I wrote above, it would be possible
for peers to become segregated (those who require encryption would only
connect to each other). It wouldn't be a problem as long as there are
enough peers that provide both encrypted and non-encrypted connections; or,
as I said above, if we can assume every peer will support it. Maybe the
issues I'm thinking of are just growing pains that will be solved once the
majority of people upgrade?

> A simplified example:
> 1. Peer Alice connects to peer Bob
> 2. Alice asks Bob: "lets do encrypted communication, here is my session
> pubkey"
> 3. Bob also supports encryption and answers "Yes, let's do this, here is
> my session pubkey"
> 4. Alice tells Bob (encrypted now): "Perfect. Here I prove that I'm
> Alice by signing the session ID with my identity pubkey"
> 5. Bob checks his "authorized-peers" database and look-up Alices pubkey
> and verifies the signatures.
> 6. Bob tells Alice: "Good! I trust you now Alice, here is my identity
> pubkey with a signature of our session-ID"
> 7. Alice looks up Bobs pubkey in her "known-peers" database and verifies
> the signature.
> 8. Alice response to bob: "Perfect. Indeed, you are Bob!"
> ---
> At this point, the communication is encrypted and the identities has
> been verified (MITM protection).
>
>
> (simplified negotiation [only one-way, missing dh explanation, missing
> KDF, session-ID, cipher suite nego., missing re-keying, etc.])
>
>
> </jonas>
>
> _______________________________________________
> 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/20160327/30bc800e/attachment.html>;

📅 Original date posted:2016-03-26 📝 Original message:On ...

2023-06-07T17:49:58Z

In reply to nevent1q…gk5g
_________________________

📅 Original date posted:2016-03-26
📝 Original message:On Sat, Mar 26, 2016 at 1:34 AM Tom via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> On Friday 25 Mar 2016 19:43:00 Jonas Schnelli via bitcoin-dev wrote:
> > An encrypted channel together with a trusted full node would finally
> > allow to have a secure and save SPV communication.
>
> I guess my question didn't get across.
>
> Why would you want to make your usecase do connections over the peer2peer
> (net.cpp) connection at all?
>
> Mixing messages that are being sent to everyone and encrypted messages is
> asking for trouble.
> Making your private connection out-of-band would work much better.
>
>
I agree doing it out-of-band is the easiest solution for people who need
this privacy right now, but I do like the idea of adding this feature as
the number of SPV wallets is going to increase. I think the best way to
organize things would be to give encrypted messages their own port number,
similar to how http vs. https works.

We don't want two networks to develop, separated by which nodes support
encryption and which don't, so ideally nodes would rebroadcast messages
they receive on both (encrypted and non-encrypted) channels. This would
essentially double the required bandwidth of the network, which is
something to think about.

> > > Also, you didn't actually address the attack-vector.
> >
> > Which attack-vector?
>
> The statistical attack I mentioned earlier. Which comes from knowing which
> plain text messages are being sent over the encrypted channel, So as long
> as
> you keep saying you want to encrypt data that identical copies of are being
> sent to other nodes at practically the same time, you will keep being
> vulnerable to that.
>
>
> _______________________________________________
> 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/20160326/e2a0f1f0/attachment.html>;

📅 Original date posted:2016-03-16 📝 Original message:We ...

2023-06-07T17:49:52Z

In reply to nevent1q…q7d4
_________________________

📅 Original date posted:2016-03-16
📝 Original message:We have removed the BIP70 field extensions from this BIP and will save that
for another time. A PR to add our documentation to the main repo has been
submitted.

James

On Sat, Mar 12, 2016 at 8:36 AM Andreas Schildbach via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> Replying to the "fee" part of BIP75 (which as already noted should go to
> a different BIP number imho):
>
> It makes to sense to let the payee define a fee *rate*. The payee
> doesn't know anything about how the payer's wallet is structured. In
> extreme cases, as a payer I would keep all my tiny UTXOs (which would be
> unspendable in a economic way) for the one payee who is willing to pay a
> high enough rate...
>
> Rather, I propose an absolute amount that the payee is willing to cover
> should be declared.
>
> Also, in order to avoid disputes I suggest the amount should be deducted
> from the BIP70 payment message amount already. A wallet which
> understands BIP75fee would add these two up for *display* puposes only.
> The wallet should continue to use the existing fee policies. If it can
> send the amount as specified by BIP70 and the fee is below the BIP75fee
> amount, it would not mention any fees to the user. If it exceeds, it
> would display just the exceeding amount.
>
>
>
>
> On 03/11/2016 11:43 PM, Justin Newton via bitcoin-dev wrote:
> > I think we would be open to either leaving them in, or doing a separate
> > BIP. What do others think? I’d prefer to keep them together if the
> > changes are non-controversial just to cut down on #of BIP’s, but thats
> > not a strong preference.
> >
> > On Fri, Mar 11, 2016 at 3:54 AM, Andreas Schildbach via bitcoin-dev
> > <bitcoin-dev at lists.linuxfoundation.org
> > <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
> >
> > I think it's a bad idea to pollute the original idea of this BIP with
> > other extensions. Other extensions should go to separate BIPs,
> > especially since methods to clarify the fee have nothing to do with
> > secure and authenticated bi-directional BIP70 communication.
> >
> >
> > On 03/10/2016 10:43 PM, James MacWhyte via bitcoin-dev wrote:
> > > Hi everyone,
> > >
> > > Our BIP (officially proposed on March 1) has tentatively been
> assigned
> > > number 75. Also, the title has been changed to "Out of Band Address
> > > Exchange using Payment Protocol Encryption" to be more accurate.
> > >
> > > We thought it would be good to take this opportunity to add some
> > > optional fields to the BIP70 paymentDetails message. The new
> > fields are:
> > > subtractable fee (give permission to the sender to use some of the
> > > requested amount towards the transaction fee), fee per kb (the
> minimum
> > > fee required to be accepted as zeroconf), and replace by fee
> > (whether or
> > > not a transaction with the RBF flag will be accepted with
> zeroconf). I
> > > know it doesn't make much sense for merchants to accept RBF with
> > > zeroconf, so that last one might be used more to explicitly refuse
> RBF
> > > transactions (and allow the automation of choosing a setting based
> on
> > > who you are transacting with).
> > >
> > > I see BIP75 as a general modernization of BIP70, so I think it
> > should be
> > > fine to include these extensions in the new BIP, even though these
> > > fields are not specific to the features we are proposing. Please
> > take a
> > > look at the relevant section and let me know if anyone has any
> > concerns:
> > >
> >
> https://github.com/techguy613/bips/blob/master/bip-0075.mediawiki#Extending_BIP70_PaymentDetails
> > >
> > > The BIP70 extensions page in our fork has also been updated.
> > >
> > > Thanks!
> > >
> > > James
> > >
> > >
> > > _______________________________________________
> > > bitcoin-dev mailing list
> > > bitcoin-dev at lists.linuxfoundation.org
> > <mailto:bitcoin-dev at lists.linuxfoundation.org>
> > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> > >
> >
> >
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev at lists.linuxfoundation.org
> > <mailto:bitcoin-dev at lists.linuxfoundation.org>
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
> >
> >
> >
> > --
> >
> > Justin W. Newton
> > Founder/CEO
> > Netki, Inc.
> >
> > justin at netki.com <mailto:justin at netki.com>
> > +1.818.261.4248 <tel:+1.818.261.4248>
> >
> >
> >
> >
> > _______________________________________________
> > 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/20160317/240febd4/attachment-0001.html>;

📅 Original date posted:2016-03-11 📝 Original ...

2023-06-07T17:49:51Z

In reply to nevent1q…jkvu
_________________________

📅 Original date posted:2016-03-11
📝 Original message:That's a valid point, and one we had thought of, which is why I wanted to
get everyone's opinion. I agree the proposed field extensions have nothing
to do with encryption, but does it make sense to propose a completely
separate BIP for such a small thing? If that is the accepted way to go, we
can split it into two and make a separate proposal.

On Fri, Mar 11, 2016 at 5:48 AM Andreas Schildbach via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> I think it's a bad idea to pollute the original idea of this BIP with
> other extensions. Other extensions should go to separate BIPs,
> especially since methods to clarify the fee have nothing to do with
> secure and authenticated bi-directional BIP70 communication.
>
>
> On 03/10/2016 10:43 PM, James MacWhyte via bitcoin-dev wrote:
> > Hi everyone,
> >
> > Our BIP (officially proposed on March 1) has tentatively been assigned
> > number 75. Also, the title has been changed to "Out of Band Address
> > Exchange using Payment Protocol Encryption" to be more accurate.
> >
> > We thought it would be good to take this opportunity to add some
> > optional fields to the BIP70 paymentDetails message. The new fields are:
> > subtractable fee (give permission to the sender to use some of the
> > requested amount towards the transaction fee), fee per kb (the minimum
> > fee required to be accepted as zeroconf), and replace by fee (whether or
> > not a transaction with the RBF flag will be accepted with zeroconf). I
> > know it doesn't make much sense for merchants to accept RBF with
> > zeroconf, so that last one might be used more to explicitly refuse RBF
> > transactions (and allow the automation of choosing a setting based on
> > who you are transacting with).
> >
> > I see BIP75 as a general modernization of BIP70, so I think it should be
> > fine to include these extensions in the new BIP, even though these
> > fields are not specific to the features we are proposing. Please take a
> > look at the relevant section and let me know if anyone has any concerns:
> >
> https://github.com/techguy613/bips/blob/master/bip-0075.mediawiki#Extending_BIP70_PaymentDetails
> >
> > The BIP70 extensions page in our fork has also been updated.
> >
> > Thanks!
> >
> > James
> >
> >
> > _______________________________________________
> > 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/20160311/12e2977c/attachment.html>;

📅 Original date posted:2016-03-10 📝 Original message:Hi ...

2023-06-07T17:49:50Z

In reply to nevent1q…tp06
_________________________

📅 Original date posted:2016-03-10
📝 Original message:Hi everyone,

Our BIP (officially proposed on March 1) has tentatively been assigned
number 75. Also, the title has been changed to "Out of Band Address
Exchange using Payment Protocol Encryption" to be more accurate.

We thought it would be good to take this opportunity to add some optional
fields to the BIP70 paymentDetails message. The new fields are:
subtractable fee (give permission to the sender to use some of the
requested amount towards the transaction fee), fee per kb (the minimum fee
required to be accepted as zeroconf), and replace by fee (whether or not a
transaction with the RBF flag will be accepted with zeroconf). I know it
doesn't make much sense for merchants to accept RBF with zeroconf, so that
last one might be used more to explicitly refuse RBF transactions (and
allow the automation of choosing a setting based on who you are transacting
with).

I see BIP75 as a general modernization of BIP70, so I think it should be
fine to include these extensions in the new BIP, even though these fields
are not specific to the features we are proposing. Please take a look at
the relevant section and let me know if anyone has any concerns:
https://github.com/techguy613/bips/blob/master/bip-0075.mediawiki#Extending_BIP70_PaymentDetails

The BIP70 extensions page in our fork has also been updated.

Thanks!

James
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160310/f5ce8ae6/attachment.html>;

📅 Original date posted:2016-03-08 📝 Original message:Our ...

2023-06-07T17:49:26Z

In reply to nevent1q…n75r
_________________________

📅 Original date posted:2016-03-08
📝 Original message:Our BIP just defines protocol definitions, and doesn't really dictate how
people use them (we're coming up with a new title for the BIP, by the way,
to more accurately convey that). Using our definitions as building blocks,
someone could definitely accomplish what you described. For example, Joe
Mobile Wallet User's wallet could upload a slew of generic PaymentRequest
messages with signatures to prove his identity, and the server could then
create encryptedPaymentRequest messages using the server's key for
encryption and communication with the other party. In this case the server
would essentially be a proxy for the user without having actual access to
the user's private keys.

My personal goal with the protocol was to keep it extremely flexible so
developers could use it to build all different types of schemes while
keeping standard messages that could be forwarded between services if
needed. Does the above make sense?

James

On Tue, Mar 8, 2016 at 2:55 PM Luke Dashjr via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> Is there a way for Joe Mobile Wallet User to upload a set of N
> PaymentRequests
> authenticated by his key to an untrusted server, which encrypts and passes
> them on in response to InvoiceRequests? Or does this necessarily require
> the
> recipient to be online?
>
> On Tuesday, March 01, 2016 6:58:16 PM Justin Newton via bitcoin-dev wrote:
> > The following draft BIP proposes an update to the Payment Protocol.
> >
> > Motivation:
> >
> > The motivation for defining this extension to the BIP70 Payment Protocol
> is
> > to allow 2 parties to exchange payment information in a permissioned and
> > encrypted way such that wallet address communication can become a more
> > automated process. Additionally, this extension allows for the requestor
> of
> > a PaymentRequest to supply a certificate and signature in order to
> > facilitate identification for address release. This also allows
> > for automated creation of off blockchain transaction logs that are human
> > readable, containing who you transacted with, in addition to the
> > information that it contains today.
> >
> > The motivation for this extension to BIP70 is threefold:
> >
> > 1. Ensure that the payment details can only be seen by the participants
> in
> > the transaction, and not by any third party.
> > 2. Enhance the Payment Protocol to allow for store and forward servers in
> > order to allow, for example, mobile wallets to sign and serve
> > Payment Requests.
> > 3. Allow a sender of funds the option of sharing their identity with the
> > receiver. This information could then be used to:
> >
> > * Make bitcoin logs more human readable
> > * Give the user the ability to decide who to release payment
> > details to
> > * Allow an entity such as a political campaign to ensure donors
> > match regulatory and legal requirements
> > * Allow for an open standards based way for regulated financial
> > entities to meet regulatory requirements
> > * Automate the active exchange of payment addresses, so static
> > addresses and BIP32 X-Pubs can be avoided to maintain privacy
> > and convenience
> >
> > In short we wanted to make bitcoin more human, while at the same time
> > improving transaction privacy.
> >
> > Full proposal here:
> >
> >
> https://github.com/techguy613/bips/blob/master/bip-invoicerequest-extension
> > .mediawiki
> >
> > We look forward to your thoughts and feedback on this proposal!
> >
> > Justin
> _______________________________________________
> 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/20160308/069639e0/attachment-0001.html>;

📅 Original date posted:2016-03-08 📝 Original message:I ...

2023-06-07T17:49:26Z

In reply to nevent1q…9prk
_________________________

📅 Original date posted:2016-03-08
📝 Original message:I accidentally replied to Luke off-list, and this was his reply to my last
message:

"But wouldn't the server be a trusted third-party in this case?
I'm thinking it's very close to being possible for an untrusted server to do
this..."

If you are okay with anyone being able to view your PaymentRequest
messages, then you wouldn't need to encrypt them. Just upload them to the
server and let it give them away--no trust needed as long as you include a
signature. If you want only certain people to be able to see your messages,
then you need to denote those people in some way. In this situation, you
would do that by trading public keys and uploading encryptedPaymentRequest
messages to the server that only those people could read.

Using the encrypted method doesn't require the devices to be online, but it
does require at least one of the parties to know the other party's public
key. Do you have a specific use case in mind?

James

On Tue, Mar 8, 2016 at 3:07 PM James MacWhyte <macwhyte at gmail.com> wrote:

> Our BIP just defines protocol definitions, and doesn't really dictate how
> people use them (we're coming up with a new title for the BIP, by the way,
> to more accurately convey that). Using our definitions as building blocks,
> someone could definitely accomplish what you described. For example, Joe
> Mobile Wallet User's wallet could upload a slew of generic PaymentRequest
> messages with signatures to prove his identity, and the server could then
> create encryptedPaymentRequest messages using the server's key for
> encryption and communication with the other party. In this case the server
> would essentially be a proxy for the user without having actual access to
> the user's private keys.
>
> My personal goal with the protocol was to keep it extremely flexible so
> developers could use it to build all different types of schemes while
> keeping standard messages that could be forwarded between services if
> needed. Does the above make sense?
>
> James
>
> On Tue, Mar 8, 2016 at 2:55 PM Luke Dashjr via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> Is there a way for Joe Mobile Wallet User to upload a set of N
>> PaymentRequests
>> authenticated by his key to an untrusted server, which encrypts and passes
>> them on in response to InvoiceRequests? Or does this necessarily require
>> the
>> recipient to be online?
>>
>> On Tuesday, March 01, 2016 6:58:16 PM Justin Newton via bitcoin-dev wrote:
>> > The following draft BIP proposes an update to the Payment Protocol.
>> >
>> > Motivation:
>> >
>> > The motivation for defining this extension to the BIP70 Payment
>> Protocol is
>> > to allow 2 parties to exchange payment information in a permissioned and
>> > encrypted way such that wallet address communication can become a more
>> > automated process. Additionally, this extension allows for the
>> requestor of
>> > a PaymentRequest to supply a certificate and signature in order to
>> > facilitate identification for address release. This also allows
>> > for automated creation of off blockchain transaction logs that are human
>> > readable, containing who you transacted with, in addition to the
>> > information that it contains today.
>> >
>> > The motivation for this extension to BIP70 is threefold:
>> >
>> > 1. Ensure that the payment details can only be seen by the participants
>> in
>> > the transaction, and not by any third party.
>> > 2. Enhance the Payment Protocol to allow for store and forward servers
>> in
>> > order to allow, for example, mobile wallets to sign and serve
>> > Payment Requests.
>> > 3. Allow a sender of funds the option of sharing their identity with the
>> > receiver. This information could then be used to:
>> >
>> > * Make bitcoin logs more human readable
>> > * Give the user the ability to decide who to release payment
>> > details to
>> > * Allow an entity such as a political campaign to ensure donors
>> > match regulatory and legal requirements
>> > * Allow for an open standards based way for regulated financial
>> > entities to meet regulatory requirements
>> > * Automate the active exchange of payment addresses, so static
>> > addresses and BIP32 X-Pubs can be avoided to maintain privacy
>> > and convenience
>> >
>> > In short we wanted to make bitcoin more human, while at the same time
>> > improving transaction privacy.
>> >
>> > Full proposal here:
>> >
>> >
>> https://github.com/techguy613/bips/blob/master/bip-invoicerequest-extension
>> > .mediawiki
>> >
>> > We look forward to your thoughts and feedback on this proposal!
>> >
>> > Justin
>> _______________________________________________
>> 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/20160309/bc71ef82/attachment.html>;