Re: [bitcoin-dev] Security problems with relying on transaction fees for security

[James MacWhyte via bitcoin-dev]

On Tue, Jul 12, 2022 at 12:26 AM Peter Todd  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?
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Security problems with relying on transaction fees for security

[James MacWhyte via bitcoin-dev]

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@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@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] No Order Mnemonic

[James MacWhyte via bitcoin-dev]

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  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@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@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] No Order Mnemonic

[James MacWhyte via bitcoin-dev]

> 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@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Covenant opcode proposal OP_CONSTRAINDESTINATION (an alternative to OP_CTV)

[James MacWhyte via bitcoin-dev]

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
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Opinion on proof of stake in future

[James MacWhyte via bitcoin-dev]

@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.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] OP_BEFOREBLOCKVERIFY - discussing and opcode that invalidates a spend path after a certain block

[James MacWhyte via bitcoin-dev]

@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@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 

Re: [bitcoin-dev] Fortune Cookies to Bitcoin Seed

[James MacWhyte via bitcoin-dev]

On Tue, Mar 5, 2019 at 4:39 PM Trey Del Bonis via bitcoin-dev <
bitcoin-dev@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
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Card Shuffle To Bitcoin Seed

[James MacWhyte via bitcoin-dev]

James


On Sun, Feb 3, 2019 at 10:27 AM Ryan Havar via bitcoin-dev <
bitcoin-dev@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@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] bustapay BIP :: a practical sender/receiver coinjoin protocol

[James MacWhyte via bitcoin-dev]

On Tue, Jan 29, 2019 at 6:46 PM  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 ;)
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] bustapay BIP :: a practical sender/receiver coinjoin protocol

[James MacWhyte via bitcoin-dev]

James


On Sun, Jan 27, 2019 at 2:11 PM  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).
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] bustapay BIP :: a practical sender/receiver coinjoin protocol

[James MacWhyte via bitcoin-dev]

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@lists.linuxfoundation.org wrote:

>
>
> On 27. 01. 19 8:36, rha...@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 

Re: [bitcoin-dev] BIP39 seeds

[James MacWhyte via bitcoin-dev]

On Wed, Jan 2, 2019 at 3:40 AM Alan Evans via bitcoin-dev <
bitcoin-dev@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.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP39 seeds

[James MacWhyte via bitcoin-dev]

On Wed, Dec 26, 2018 at 11:33 AM Aymeric Vitte 
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.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP39 seeds

[James MacWhyte via bitcoin-dev]

On Mon, Dec 24, 2018 at 2:48 PM Aymeric Vitte via bitcoin-dev <
bitcoin-dev@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
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Proposal for Palindromic (Reversible) Mnemonics

[James MacWhyte via bitcoin-dev]

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@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@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@lists.linuxfoundation.org
>> 

Re: [bitcoin-dev] draft proposal: change forwarding (improved fungibility through wallet interoperability)

[James MacWhyte via bitcoin-dev]

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@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@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP Proposal - Address Paste Improvement

[James MacWhyte via bitcoin-dev]

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@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@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@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
>
> --
> Best,
> Ádám
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] MultiSig request URI proposal

[James MacWhyte via bitcoin-dev]

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@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@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Hypothetical 2 MB hardfork to follow BIP148

[James MacWhyte via bitcoin-dev]

>  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.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Committed bloom filters for improved wallet performance and SPV security

[James MacWhyte via bitcoin-dev]

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@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  wrote:
> > On 01/04/2017 11:06 PM, Chris Priest via bitcoin-dev wrote:
> >> On 1/3/17, Jonas Schnelli via bitcoin-dev
> >>  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@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Managing block size the same way we do difficulty (aka Block75)

[James MacWhyte via bitcoin-dev]

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@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@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Capital Efficient Honeypots w/ "Scorched Earth" Doublespending Protection

[James MacWhyte via bitcoin-dev]

>
> >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.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Capital Efficient Honeypots w/ "Scorched Earth" Doublespending Protection

[James MacWhyte via bitcoin-dev]

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@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   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 

Re: [bitcoin-dev] BIP Number Request: Addresses over Audio

[James MacWhyte via bitcoin-dev]

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@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  wrote:
>
>> On Thu, Aug 11, 2016 at 8:37 PM, Erik Aronesty via bitcoin-dev
>>  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@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP Number Request: Addresses over Audio

[James MacWhyte via bitcoin-dev]

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@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@lists.linuxfoundation.org> wrote:
>
>> On Wed, Aug 10, 2016 at 7:28 PM, Erik Aronesty via bitcoin-dev
>>  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@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Hiding entire content of on-chain transactions

[James MacWhyte via bitcoin-dev]

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  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 :
> > 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?
> >
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Hiding entire content of on-chain transactions

[James MacWhyte via bitcoin-dev]

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  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 :
>
>> 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@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 :
>>>
 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 

Re: [bitcoin-dev] Hiding entire content of on-chain transactions

[James MacWhyte via bitcoin-dev]

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  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 :
>
>> 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@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 :
>>>
 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
 

Re: [bitcoin-dev] Hiding entire content of on-chain transactions

[James MacWhyte via bitcoin-dev]

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@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 :
>
>> 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 

Re: [bitcoin-dev] Fees and Accounts

[James MacWhyte via bitcoin-dev]

> 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
> >  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@lists.linuxfoundation.org
> >   https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
> >
> >
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org

Re: [bitcoin-dev] Fees and Accounts

[James MacWhyte via bitcoin-dev]

>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@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@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP Number Request: Open Asset

[James MacWhyte via bitcoin-dev]

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@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 +, Luke Dashjr via bitcoin-dev
> wrote:
> > > On Thursday, May 26, 2016 2:50:26 AM Nicolas Dorier via bitcoin-dev
> wrote:
> > > >   Author: Flavien Charlon 
> >
> > 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@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Even more proposed BIP extensions to BIP 0070

[James MacWhyte via bitcoin-dev]

> 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?
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Even more proposed BIP extensions to BIP 0070

[James MacWhyte via bitcoin-dev]

> 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.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Even more proposed BIP extensions to BIP 0070

[James MacWhyte via bitcoin-dev]

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
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] BIP75 update & PR - Simplification

[James MacWhyte via bitcoin-dev]

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
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP75 - Out of Band Address Exchange

[James MacWhyte via bitcoin-dev]

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@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@lists.linuxfoundation.org
> > <mailto:bitcoin-dev@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@lists.linuxfoundation.org
> > <mailto:bitcoin-dev@lists.linuxfoundation.org>
> > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> > >
> >
> >
> > ___
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > <mailto:bitcoin-dev@lists.linuxfoundation.org>
> > 

Re: [bitcoin-dev] BIP75 - Out of Band Address Exchange

[James MacWhyte via bitcoin-dev]

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@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@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
>
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Proposed BIP extension to BIP 0070

[James MacWhyte via bitcoin-dev]

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  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@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@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Proposed BIP extension to BIP 0070

[James MacWhyte via bitcoin-dev]

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@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@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev