Re: [Bitcoin-development] Reusable payment codes

[odinn]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Peter, my response below

On 06/16/2015 10:46 AM, Peter Todd wrote:
> On Tue, Jun 16, 2015 at 09:26:07AM -0700, odinn wrote:
>> This is very well done.
>>
>> Have you seen this discussion that I started regarding BIP 63?
>>
>> https://bitcointalk.org/index.php?topic=1083961.0
>>
>> I have no response from Peter Todd back on it other than "my time is
>> better spent focusing on more fundemental issues" and "I've also got
>> no-one interested in funding stealth address development right now,"
>> when several people (myself included) offered to send donations to se
e
>> the BIP (63) advance, no donation address was posted, so... waiting
>> for him to act on that.
> 
> Sorry, but I'm looking at the huge amount of work that I'll likely hav
e
> responding to the blocksize issue, so I think I'm inclined to shelve
> work on BIP63 for now.


I seriously find this pretty sad... you said that paying rent was an
issue and your time was better spent on "more fundamental issues..." but
the very least you could do is post a donation address... Is there
someone who was working with you closely on the concept who could take
it up since you are not going to be working on it?

> 
> Feel free to take it up; a (>=2)-part standard describing the resuable
> codes aspect, and separately how the ephemeral key is transmitted to t
he
> recipient makes sense to me.
> 

I don't want to camp on Justus's thread on reusable payment codes ~ but
on the subject of BIP 63, it just did make sense to mention... so if
someone does have interest in working on it... please go to
https://bitcointalk.org/index.php?topic=1083961.0
and reply there.


- -- 
http://abis.io ~
"a protocol concept to enable decentralization
and expansion of a giving economy, and a new social good"
https://keybase.io/odinn
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJVgQbMAAoJEGxwq/inSG8CD8gH/3jV+mLO9qv3t6JFxIvLMPtr
slGbymQtuqfAC09b6ybx3p6u9I1o1Nb3IgK1riu/Z3AzHxlnuYVUxN3N5ns0zGnx
F2WXs2suEa20YJkQ6dxZWLdNBjnUIEGGgXAit8X21LqVsqPfeZcocOWSeRDlePhk
/HRFLVtMehqfqjbuFAaAewVZUyT4Bn+3IU74krqR3e3YA00/ym1C5xCE3/kHvKIL
UF8EW9GgVYKuoyQdH3ICDwjiudwPOwIC4Ry0huaJgla43122RkwqYB+5kVr1583u
dx3VW8vW8HyQZJF+vb8d3F57R6FC6zYtFhCe0IzDIh+6xQxStk5zosMNIrtPKp4=
=h8Ib
-END PGP SIGNATURE-

--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] questions about bitcoin-XT code fork & non-consensus hard-fork

[Peter Todd]

On Tue, Jun 16, 2015 at 09:55:13PM +0800, Pindar Wong wrote:
> > Agreed. Pieter Wuille's recent work is a great example of the kind of
> > science-driven investigations that need to be done - and haven't been
> > done very much - to get us some hard data to make decisions on.
> >
> 
> Thank you very much Peter for pointing this out! That is very kind of you.
> 
> It would be great to work with Constance Choi, Primavera De Filippi, your
> goodself and others to make this happen.

Great! They're excited to see this happen. I'm in London right now
actually for the conference they were holding this week; the blocksize
issue was being discussed a fair bit there among attendees. (notably,
with rather different views than seen on reddit!)

> As you may know, the Hong Kong Monetary Authority considers bitcoin a
> virtual 'commodity' and not a currency per se.

Yup, though keep in mind the regulatory question is more than just how
your local jurisdiction views Bitcoin, but rather how your customers'
jurisdictions view Bitcoin.

Of course, when I say "customers" above, I mean the entire Bitcoin
community that is ultimately buying the new coins produced by miners and
paying fees to them!

-- 
'peter'[:-1]@petertodd.org
127ab1d576dc851f374424f1269c4700ccaba2c42d97e778


signature.asc
Description: Digital signature
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] questions about bitcoin-XT code fork & non-consensus hard-fork

[Troy Benjegerdes]

> - How do you propose to deal with the extra risks that come from
> non-consensus hard-forks?  Hard-forks themselves are quite risky, but
> non-consensus ones are extremely dangerous for consensus.

This is a non-issue.

If the hard-fork is not a consensus, then those of us that don't consent
ignore the fool that tried to hard-fork.

If a fool attempting a non-consensus hard-fork actually breaks something,
then you have a fragile system that needs some serious re-thinking.

I think a non-consensus hard-fork would be the best thing that could 
happen to the bitcoin ecosystem long-term, because it would force some
re-examination of some very bad assumptions.

-- 

Troy Benjegerdes 'da hozer'  ho...@hozed.org
7 elements  earth::water::air::fire::mind::spirit::soulgrid.coop

  Never pick a fight with someone who buys ink by the barrel,
 nor try buy a hacker who makes money by the megahash


--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] questions about bitcoin-XT code fork & non-consensus hard-fork

[Peter Todd]

On Mon, Jun 15, 2015 at 09:00:19PM -0700, Aaron Voisine wrote:
> Thanks Alex, the work you've pointed out is helpful. Limiting mempool size
> should at least prevent nodes from crashing. When I looked a few days ago I
> only found a few old PRs that seemed to have fallen by the wayside, so this
> new one is encouraging.

BTW it's worth working out how many $ in fees you need for a given
amount of MB worth of mempool.

At the current 10uBTC/KB minimim relay fee 1MB of txs requires just $2.5
worth of fees - kinda ridiculous when a block earns a miner $6250 in
revenue. Pretty much all txs pay significantly higher rates - more like
100uBTC/KB, or $25/MB. At that rate the 288MB max mempool size proposed
by Patrick Strateman's pull-req requires at least $7.2k worth of BTC to
fill to pay the fees, and in practice will probably quickly get higher.

https://github.com/bitcoin/bitcoin/pull/6281

> I can respond in the PR comments if it's more appropriate there, but I
> believe ejecting tx from mempools rather than preemptively refusing them
> according to standard network wide propagation rules will result in spotty,
> inconsistent tx propagation, and possibly a large increase in tx
> re-broadcasts, so if those haven't been addressed they will need to be. It
> would also be prudent to run some simulations to see what other issues are
> going to pop-up.

See above - filling the mempool like that will be both a slow process,
and require lots of funds. Equally, once full, the sensible thing to do
is raise the minimum relay fee appropriately, so those transactions that
pay too low a fee will simply be rejected.

It'd be reasonable to tell peers that, and what the minimum fee needed
for acceptance would be for that particular node.

> We're currently using CPFP already in breadwallet when spending unconfirmed
> non-change inputs. A small percentage of hashing power is using it, but
> enough to get a transaction unstuck assuming breadwallet's fee calculation
> is better than the sender's.

> The problem with RBF is that there's currently no way to tell if your tx
> has been picked up by miners or not in order to know if you need to replace
> it. Miners broadcasting partial block solutions would be helpful in this
> regard, but only for tx in the currently-being-worked-on block, not for tx
> that won't be picked up until the block after. If miners were to eject tx
> that were previously being worked on in favor of higher fee tx, then that
> causes another set of problems for wallets that thought their tx was going
> to get in but then it doesn't. The other problem with RBF is that users
> don't know up front what fee they're actually going to pay which is a big
> blow to real world usability. Also mobile wallets will have to sign lots of
> tx up front and rely on a service to replace as necessary. And this is all
> just on the send side.

For an interactive, mobile wallet, the best thing to do is estimate the
fee correctly the first time, using RBF as a follow up mechanism only if
needed. For other users - e.g. exchanges handling customer withdrawals -
using RBF more agressively to get the minimum possible fee may make
sense.

> On the receive side it's much worse since you can't
> rely on the sender to do the replacing. The real problem seems to be the
> fact that RBF is an interactive iterative process rather than a
> send-and-forget one.

In any case, the *existance* of RBF makes no difference to any of these
problems; RBF does make solving the easier. You can always choose to not
use it after all, resulting in the same "send-and-forget" process.
Having it available allows mistakes to be fixed after the fact, always
an improved user experience over not being able to re-bid for block
space.


Incidentally, if my FSS-RBF bug bounty isn't collected in the next week
or two, we'll likely have a major double-digits % of hashing power
mining FSS-RBF soon after.

http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg08122.html

> What you really need is some way to tell up-front, is a transaction going
> to get mined with a high probability? That problem seems really difficult
> to solve with fixed-size blocks that are full.

Have you looked at the fee estimation code in Bitcoin Core? I have no
reason to think it doesn't basically speaking work. Of course, SPV
wallets will need a semi-trusted third party to securely get that data,
but this seems to be a fundemental problem in a decentralized network -
the purpose of the blockchain itself is to prove that some data was
published to some audience, an analogous problem to proving to the SPV
wallet that their transaction actually reached miners and they actually
are considering it for inclusion.

Guaranteed reliable transaction processing is only possible in
centralized environments that can make service guarantees.

> If the goal is simply to
> reduce or limit the growth of the blockchain, then there are much simpler
> solutions, which is why I've advocated for 

Re: [Bitcoin-development] Proposal: Move Bitcoin Dev List to a Neutral Competent Entity

[grarpamp]

Please no GoogleGroups. Stick with mailman or some other open
source thing you can move around from place to place as needed.

Also, online third party archives die, their web interfaces suck
ass, they're bloated, don't export, aren't offline capable or
authoritative, etc.

You need to make the raw archives (past and future) downloadable
in mbox format and updated daily, with full unobfuscated headers
for threading and replying, with signatures and attachments.
Commonly for newcomers wishing to seed their own MUA's and archives,
mirrors, search, and so on.

One such breakage of archives by mailman defaults was discussed and
corrected here:
https://cpunks.org/pipermail/cypherpunks/

You also need to get rid of the tag in the subject, it wastes
valuable space and mail filters work just the same without it.

Please no "forums" (see suck above). Unless they have bidirectional
realtime message copying between list and forum. Or at least make
available exports of their message database.

Further, when will the crypto P2P communities develop and use
distributed messaging systems... bitmessage, blockchain, etc as
rough examples... to avoid old centralized issues. At some point you
have to start eating your own dog food and make people run the
clients and come to you instead. Disruptive tech is the new good.

--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] [BIP draft] Consensus-enforced transaction replacement signalled via sequence numbers

[Gregory Maxwell]

On Wed, Jun 17, 2015 at 1:00 AM, Mark Friedenbach  wrote:
> Given that we have had more than two weeks of public discussion, code is
> available and reviewed, and several community identified issues resolved, I
> would like to formally request a BIP number be assigned for this work. Will
> the BIP editor be so kind as to do so to allow the BIP consensus process to
> proceed?

BIP 68, unless you have objections.

--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] [BIP draft] Consensus-enforced transaction replacement signalled via sequence numbers

[Mark Friedenbach]

Given that we have had more than two weeks of public discussion, code is
available and reviewed, and several community identified issues resolved, I
would like to formally request a BIP number be assigned for this work. Will
the BIP editor be so kind as to do so to allow the BIP consensus process to
proceed?

Thank you,
Mark Friedenbach

On Mon, Jun 1, 2015 at 6:49 PM, Mark Friedenbach 
wrote:

> I have written a reference implementation and BIP draft for a soft-fork
> change to the consensus-enforced behaviour of sequence numbers for the
> purpose of supporting transaction replacement via per-input relative
> lock-times. This proposal was previously discussed on the mailing list in
> the following thread:
>
> http://sourceforge.net/p/bitcoin/mailman/message/34146752/
>
> In short summary, this proposal seeks to enable safe transaction
> replacement by re-purposing the nSequence field of a transaction input to
> be a consensus-enforced relative lock-time.
>
> The advantages of this approach is that it makes use of the full range of
> the 32-bit sequence number which until now has rarely been used for
> anything other than a boolean control over absolute nLockTime, and it does
> so in a way that is semantically compatible with the originally envisioned
> use of sequence numbers for fast mempool transaction replacement.
>
> The disadvantages are that external constraints often prevent the full
> range of sequence numbers from being used when interpreted as a relative
> lock-time, and re-purposing nSequence as a relative lock-time precludes its
> use in other contexts. The latter point has been partially addressed by
> having the relative lock-time semantics be enforced only if the
> most-significant bit of nSequence is set. This preserves 31 bits for
> alternative use when relative lock-times are not required.
>
> The BIP draft can be found at the following gist:
>
> https://gist.github.com/maaku/be15629fe64618b14f5a
>
> The reference implementation is available at the following git repository:
>
> https://github.com/maaku/bitcoin/tree/sequencenumbers
>
> I request that the BIP editor please assign a BIP number for this work.
>
> Sincerely,
> Mark Friedenbach
>
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Proposal: Move Bitcoin Dev List to a Neutral Competent Entity

[Warren Togami Jr.]

On Sun, Jun 14, 2015 at 5:19 PM, Warren Togami Jr. 
wrote:

>
> *List Name?*  Would people prefer "bitcoin-development" for he new list
> name instead of a shorter name like "bitcoin-dev"?  I personally like the
> shorter name, but either is fine.
> https://lists.linuxfoundation.org/mailman/listinfo currently has
> "sidechains-dev", and "lightning-dev" is moving there sometime soon.
>

We're going ahead with "bitcoin-dev".  A request for creation is now
pending.


>
> *Proposed Cut-Off Date?*  Then we also need to agree on a date to cut off
> the old list.  Their sysadmin said we could have the new list auto-post
> from the old list for a short while.  I wonder how well that works ... if
> that will result in double posting if people write to the new and CC the
> old list.  Needs a little research how well it would behave to have both
> lists operating during a transition period.  I think we should announce a
> cut-off date when posts to the old list is shut off, July 15th, one month
> from now.  Thoughts?
>

Off-list I heard a suggestion to make the cut-off date as short as one week
after the new list is announced and people are given the option to
subscribe.  Could people please post feelings about this?

It seems most everyone agreed not to auto-subscribe everyone onto the new
list as that tends to be upsetting.

There is clarity if subscribing the old list to the new list is a good
idea.  Is anyone familiar with Mailman, is it smart enough to somehow
prevent double-posts if someone writes to both the old and new address?

Warren Togami
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Lost proposals from FellowTraveler/Monetas

[Justus Ranvier]

-BEGIN PGP SIGNED MESSAGE-

Hash: SHA512


On 2015-06-16 23:32, Gregory Maxwell wrote:

> Is there any discussion thats been had relating to the BIP-drafts at:

>

> https://github.com/Open-Transactions/rfc/tree/master/bips

>

> Fellow Traveler has apparently been waiting 9 months for progress on

> these proposals and I'm trying to find out where the breakdown

> happened. While do not doubt that I am somehow at fault, I can't

> figure out how.

>

> Searching my email and this list archive for "Base58 Serialization for

> Transaction-Based Color Descriptors" or "Order-based Smart Property

> Coloring" or the draft names bip-ccids, etc. turn up no hits at all.

> I've asked several other people and there list archives show nothing.


The only two proposals we sent to the mailing list were attached to this
post:


http://sourceforge.net/p/bitcoin/mailman/message/32736455/


The rest of the proposals in that respository, as well as those the fork
here:


https://github.com/Monetas/rfc/tree/master/bips


were never submitted because we decided to use alternative identifiers in
leiu of BIP numbers to serve as the purpose code in the HD path.

-BEGIN PGP SIGNATURE-

Version: GnuPG v2


iQIcBAEBCgAGBQJVgLRaAAoJECpf2nDq2eYjw7YQAJYrciEZZeasEJRR7XwZ5AWQ

9e/pz1SV2hoRs7TqHgHoXGINLbG9LwlXFmnoG14z+vwKvheJxlC6gOQCRIRwPfrR

zwuQWyoONHn82XL44ABqjnu0fmeh7egx3FIzsgDUxUgiP5dA0BuQvrT1+DptfJ+p

5sM7ZvRqfZJbek4AHk9Y4kERQYsP4HKgC1W3Acr1In9WPSj5TRtYz7tUK+SFcO+m

A3Ny5dUiAmmf5mfLZiWrEmCG34n+cCJZEU2hlQqH5ZuAHPmeTLuar91MLj/1Xltf

OFlMGhmUPy1alTx8o39nwRjfXIVQLk7/D5YB3gB2CUuXd+sWbY+6LUyniOKtQK3C

EmEDOUFSNm4JV1AmM+ea1HUufCJfkg1VHko4hsIyc1e7ztdECIzPQKAy7DAcu1YS

BhbkxNyaUqoF+J/ggrXhT/r5oVpWsifdj4IEzaMvmOxu+p+hTkzzwitLuyknEBZE

b2KWRMWNOheVpDp7RmrcTPqa4S1N8XcfJazDyigIhl0E/Bjk+pC1SHo7IIEMZMQ+

Fz7JaALd8XK0l7HBvvJnZmYwVLnQyB01B6n7z8eTTAneHhSXxa7Z1aFTkYU8Wp9o

L5nb1K7gJtjBFqhLi3PMLRhARao1Q/CK5bDt9Mb3VMy9jAIr9X9/NcL473cbHtQH

/h91bhkL9bvvkeCl5yQk

=NgfK

-END PGP SIGNATURE-
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

[Bitcoin-development] Lost proposals from FellowTraveler/Monetas

[Gregory Maxwell]

Is there any discussion thats been had relating to the BIP-drafts at:

https://github.com/Open-Transactions/rfc/tree/master/bips

Fellow Traveler has apparently been waiting 9 months for progress on
these proposals and I'm trying to find out where the breakdown
happened. While do not doubt that I am somehow at fault, I can't
figure out how.

Searching my email and this list archive for "Base58 Serialization for
Transaction-Based Color Descriptors" or "Order-based Smart Property
Coloring" or the draft names bip-ccids, etc. turn up no hits at all.
I've asked several other people and there list archives show nothing.

Has anyone else taken part in discussions related to these proposals
(or seen them all before)? If so, please point me to the discussion.

Otherwise I'll just go ahead and create threads for each under the
assumption that there is yet another mailing list screwup. :(

--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] [RFC] Canonical input and output ordering in transactions

[Rusty Russell]

Jorge Timón  writes:
> On Jun 15, 2015 11:43 PM, "Rusty Russell"  wrote:
>
>> Though Peter Todd's more general best-effort language might make more
>> sense.  It's not like you can hide an OP_RETURN transaction to make it
>> look like something else, so that transaction not going to be
>> distinguished by non-canonical ordering.
>
> What about commitments that don't use op_return (ie pay2contract
> commitments)?

I have no idea what they are? :)

> In any case, if the motivation is ordering in multi-party transactions
> there should be ways to do it without any consequences for other
> transaction types' privacy. For example you could have a deterministic
> method that depends on a random seed all parties in the transaction
> previously share. That way the ordering is deterministic for all parties
> involved in the transaction (which can use whatever channel they're using
> to send the parts to also send this random seed) while at the same time the
> order looks random (or at least not cannonical in a recognisable way) to
> everyone else.

Yes, my plan B would be an informational bip with simple code,
suggesting a way to permute a transaction based on some secret.  No
point everyone reinventing the wheel, badly.

Cheers,
Rusty.

--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] BIP for Proof of Payment

[Pieter Wuille]

I don't see why existing software could create a 40-byte OP_RETURN but not
larger? The limitation comes from a relay policy in full nodes, not a
limitation is wallet software... and PoPs are not relayed on the network.

Regarding sharing, I think you're talking about a different use case. Say
you want to pay for 1-week valid entrance to some venue. I thought the
purpose of the PoP was to be sure that only the person who paid for it, and
not anyone else can use it during that week.

My argument against that is that the original payer can also hand the
private keys in his wallet to someone else, who would then become able to
create PoPs for the service. He does not lose anything by this, assuming
the address is not reused.

So, using a token does not change anything, except it can be provided to
the payer - instead of relying on creating an implicit identity based on
who seems to have held particular private keys in the past.
On Jun 16, 2015 9:41 PM, "Kalle Rosenbaum"  wrote:

> 2015-06-16 21:25 GMT+02:00 Pieter Wuille :
> > You can't avoid sharing the token, and you can't avoid sharing the
> private
> > keys used for signing either. If they are single use, you don't lose
> > anything by sharing them.
>
> Forwarding the PoP request would be a way to avoid sharing keys, as
> suggested above.
>
> >
> > Also you are not creating a real transaction. Why does the OP_RETURN
> > limitation matter?
>
> This was discussed in the beginning of this thread: "The idea is to
> simplify implementation. Existing software can be used as is to sign
> and validate PoPs"
>
> Regards,
> Kalle
>
> >
> > On Jun 16, 2015 9:22 PM, "Kalle Rosenbaum"  wrote:
> >>
> >> Thank you for your comments Pieter! Please find my answers below.
> >>
> >> 2015-06-16 16:31 GMT+02:00 Pieter Wuille :
> >> > On Mon, Jun 15, 2015 at 1:59 PM, Kalle Rosenbaum 
> >> > wrote:
> >> >>
> >> >> 2015-06-15 12:00 GMT+02:00 Pieter Wuille :
> >> >> I'm not sure if we will be able to support PoP with CoinJoin. Maybe
> >> >> someone with more insight into CoinJoin have some input?
> >> >
> >> >
> >> > Not really. The problem is that you assume a transaction corresponds
> to
> >> > a
> >> > single payment. This is true for simple wallet use cases, but not
> >> > compatible
> >> > with CoinJoin, or with systems that for example would want to combine
> >> > multiple payments in a single transaction.
> >> >
> >>
> >> Yes, you are right. It's not compatible with CoinJoin and the likes.
> >>
> >> >
> >> > 48 bits seems low to me, but it does indeed solve the problem. Why not
> >> > 128
> >> > or 256 bits?
> >>
> >> The nonce is limited because of the OP_RETURN output being limited to
> >> 40 bytes of data: 2 bytes version, 32 bytes txid, 6 bytes nonce.
> >>
> >> >
> >> >> > Why does anyone care who paid? This is like walking into a
> coffeshop,
> >> >> > noticing I don't have money with me, let me friend pay for me, and
> >> >> > then
> >> >> > have
> >> >> > the shop insist that I can't drink it because I'm not the buyer.
> >> >>
> >> >> If you pay as you use the service (ie pay for coffee upfront),
> there's
> >> >> no need for PoP. Please see the Motivation section. But you are right
> >> >> that you must have the wallet(s) that paid at hand when you issue a
> >> >> PoP.
> >> >>
> >> >> >
> >> >> > Track payments, don't try to assign identities to payers.
> >> >>
> >> >> Please elaborate, I don't understand what you mean here.
> >> >
> >> >
> >> > I think that is a mistake. You should not assume that the wallet who
> >> > held
> >> > the coins is the payer/buyer. That's what I said earlier; you're
> >> > implicitly
> >> > creating an identity (the one who holds these keys) based on the
> >> > transaction. This seems fundamentally wrong to me, and not necessary.
> >> > The
> >> > receiver should not care who paid or how, he should care what was
> payed
> >> > for.
> >>
> >> You are saying that it's a problem that the wallet used to pay, must
> >> also be used to issue the PoP? That may very well be a problem in some
> >> cases. People using PoP should of course be aware of it's limitations
> >> and act accordingly, i.e. don't pay for concert tickets for a friend
> >> and expect your friend to be able to enter the arena with her wallet.
> >> As Tom Harding noted, it is possible to transfer keys to your friend's
> >> wallet, but that might not be desirable if those keys are also used
> >> for other payments. Also that would weaken the security of an HD
> >> wallet, since a chain code along with a private key would reveal all
> >> keys in that tree. Another solution is that your friend forwards the
> >> PoP request to your wallet, through twitter or SMS, and you send the
> >> PoP for her. Maybe that forwarding mechanism can be built into wallets
> >> and automated so that the wallet automatically suggests to sign the
> >> PoP for your friend. This is probably something to investigate
> >> further, but not within the scope of this BIP.
> >>
> >> Of course the simplest solu

Re: [Bitcoin-development] BIP for Proof of Payment

[Pieter Wuille]

You can't avoid sharing the token, and you can't avoid sharing the private
keys used for signing either. If they are single use, you don't lose
anything by sharing them.

Also you are not creating a real transaction. Why does the OP_RETURN
limitation matter?
On Jun 16, 2015 9:22 PM, "Kalle Rosenbaum"  wrote:

> Thank you for your comments Pieter! Please find my answers below.
>
> 2015-06-16 16:31 GMT+02:00 Pieter Wuille :
> > On Mon, Jun 15, 2015 at 1:59 PM, Kalle Rosenbaum 
> wrote:
> >>
> >> 2015-06-15 12:00 GMT+02:00 Pieter Wuille :
> >> I'm not sure if we will be able to support PoP with CoinJoin. Maybe
> >> someone with more insight into CoinJoin have some input?
> >
> >
> > Not really. The problem is that you assume a transaction corresponds to a
> > single payment. This is true for simple wallet use cases, but not
> compatible
> > with CoinJoin, or with systems that for example would want to combine
> > multiple payments in a single transaction.
> >
>
> Yes, you are right. It's not compatible with CoinJoin and the likes.
>
> >
> > 48 bits seems low to me, but it does indeed solve the problem. Why not
> 128
> > or 256 bits?
>
> The nonce is limited because of the OP_RETURN output being limited to
> 40 bytes of data: 2 bytes version, 32 bytes txid, 6 bytes nonce.
>
> >
> >> > Why does anyone care who paid? This is like walking into a coffeshop,
> >> > noticing I don't have money with me, let me friend pay for me, and
> then
> >> > have
> >> > the shop insist that I can't drink it because I'm not the buyer.
> >>
> >> If you pay as you use the service (ie pay for coffee upfront), there's
> >> no need for PoP. Please see the Motivation section. But you are right
> >> that you must have the wallet(s) that paid at hand when you issue a
> >> PoP.
> >>
> >> >
> >> > Track payments, don't try to assign identities to payers.
> >>
> >> Please elaborate, I don't understand what you mean here.
> >
> >
> > I think that is a mistake. You should not assume that the wallet who held
> > the coins is the payer/buyer. That's what I said earlier; you're
> implicitly
> > creating an identity (the one who holds these keys) based on the
> > transaction. This seems fundamentally wrong to me, and not necessary. The
> > receiver should not care who paid or how, he should care what was payed
> for.
>
> You are saying that it's a problem that the wallet used to pay, must
> also be used to issue the PoP? That may very well be a problem in some
> cases. People using PoP should of course be aware of it's limitations
> and act accordingly, i.e. don't pay for concert tickets for a friend
> and expect your friend to be able to enter the arena with her wallet.
> As Tom Harding noted, it is possible to transfer keys to your friend's
> wallet, but that might not be desirable if those keys are also used
> for other payments. Also that would weaken the security of an HD
> wallet, since a chain code along with a private key would reveal all
> keys in that tree. Another solution is that your friend forwards the
> PoP request to your wallet, through twitter or SMS, and you send the
> PoP for her. Maybe that forwarding mechanism can be built into wallets
> and automated so that the wallet automatically suggests to sign the
> PoP for your friend. This is probably something to investigate
> further, but not within the scope of this BIP.
>
> Of course the simplest solution would be to send money to your friend
> first so that she can pay for the ticket from her own wallet, but
> that's not always feasible.
>
> >
> > The easiest solution to this IMHO would be an extension to the payment
> > protocol that gives you (or your wallet) a token in return for paying,
> and
> > that knowledge of that token is used to gain access to the services you
> > provide.
> >
>
> That token would then be reusable. Someone stealing it would be able
> to use it as much as she wants. That is what I want to avoid with PoP.
> The BIP proposal briefly mentions something like this in the
> rationale. I also had a discussion about this with Mike Hearn on this
> list on Mars 13 that I think covers most pros and cons of the
> different approaches.
>
> While your suggestion does indeed separate the transaction from the
> proof of payment, it also assumes that the token is held in the wallet
> that pays. Otherwise you would need to keep it in another safe place,
> remember it's reusable. Where would that be? How would you transfer
> that token to your friend?
>
> Thank you again for your comments. I appreciate it.
>
> Best regards,
> Kalle
>
> > --
> > Pieter
> >
>
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] BIP for Proof of Payment

[Kalle Rosenbaum]

Thank you for your comments Pieter! Please find my answers below.

2015-06-16 16:31 GMT+02:00 Pieter Wuille :
> On Mon, Jun 15, 2015 at 1:59 PM, Kalle Rosenbaum  wrote:
>>
>> 2015-06-15 12:00 GMT+02:00 Pieter Wuille :
>> I'm not sure if we will be able to support PoP with CoinJoin. Maybe
>> someone with more insight into CoinJoin have some input?
>
>
> Not really. The problem is that you assume a transaction corresponds to a
> single payment. This is true for simple wallet use cases, but not compatible
> with CoinJoin, or with systems that for example would want to combine
> multiple payments in a single transaction.
>

Yes, you are right. It's not compatible with CoinJoin and the likes.

>
> 48 bits seems low to me, but it does indeed solve the problem. Why not 128
> or 256 bits?

The nonce is limited because of the OP_RETURN output being limited to
40 bytes of data: 2 bytes version, 32 bytes txid, 6 bytes nonce.

>
>> > Why does anyone care who paid? This is like walking into a coffeshop,
>> > noticing I don't have money with me, let me friend pay for me, and then
>> > have
>> > the shop insist that I can't drink it because I'm not the buyer.
>>
>> If you pay as you use the service (ie pay for coffee upfront), there's
>> no need for PoP. Please see the Motivation section. But you are right
>> that you must have the wallet(s) that paid at hand when you issue a
>> PoP.
>>
>> >
>> > Track payments, don't try to assign identities to payers.
>>
>> Please elaborate, I don't understand what you mean here.
>
>
> I think that is a mistake. You should not assume that the wallet who held
> the coins is the payer/buyer. That's what I said earlier; you're implicitly
> creating an identity (the one who holds these keys) based on the
> transaction. This seems fundamentally wrong to me, and not necessary. The
> receiver should not care who paid or how, he should care what was payed for.

You are saying that it's a problem that the wallet used to pay, must
also be used to issue the PoP? That may very well be a problem in some
cases. People using PoP should of course be aware of it's limitations
and act accordingly, i.e. don't pay for concert tickets for a friend
and expect your friend to be able to enter the arena with her wallet.
As Tom Harding noted, it is possible to transfer keys to your friend's
wallet, but that might not be desirable if those keys are also used
for other payments. Also that would weaken the security of an HD
wallet, since a chain code along with a private key would reveal all
keys in that tree. Another solution is that your friend forwards the
PoP request to your wallet, through twitter or SMS, and you send the
PoP for her. Maybe that forwarding mechanism can be built into wallets
and automated so that the wallet automatically suggests to sign the
PoP for your friend. This is probably something to investigate
further, but not within the scope of this BIP.

Of course the simplest solution would be to send money to your friend
first so that she can pay for the ticket from her own wallet, but
that's not always feasible.

>
> The easiest solution to this IMHO would be an extension to the payment
> protocol that gives you (or your wallet) a token in return for paying, and
> that knowledge of that token is used to gain access to the services you
> provide.
>

That token would then be reusable. Someone stealing it would be able
to use it as much as she wants. That is what I want to avoid with PoP.
The BIP proposal briefly mentions something like this in the
rationale. I also had a discussion about this with Mike Hearn on this
list on Mars 13 that I think covers most pros and cons of the
different approaches.

While your suggestion does indeed separate the transaction from the
proof of payment, it also assumes that the token is held in the wallet
that pays. Otherwise you would need to keep it in another safe place,
remember it's reusable. Where would that be? How would you transfer
that token to your friend?

Thank you again for your comments. I appreciate it.

Best regards,
Kalle

> --
> Pieter
>

--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Scaling Bitcoin with Subchains

[Andrew]

Actually, I have to think about this merge-mining thing a bit more. I'm
starting to think it's better to do without merge-mining at all. As I
explained in the forum post, the parent will put the hashes of its children
headers as transactions inside its blocks. Thus parents will have an
incentive to validate the children not by merge mining, but by collecting
fees from the children for putting those transactions inside (fees that can
be spent at the children chains). So, ya no merge mining needed for my
proposal. But I will think about it a bit more :)

On Tue, Jun 16, 2015 at 6:43 PM, Andrew  wrote:

>
>
> On Tue, Jun 16, 2015 at 6:17 PM, Peter Todd  wrote:
>
>> Merge-mined sidechains are not a scaling solution any more than SPV is a
>> scaling solution because they don't solve the scaling problem for
>> miners.
>>
>> Some kind of treechain like sidechain / subchains where what part of the
>> tree miners can mine is constrained to preserve fairness could be both a
>> scaling solution, and decentralized, but no-one has come up with a solid
>> design yet that's ready for production. (my treechains don't qualify for
>> transactions yet; maybe for other proof-of-publication uses)
>>
>>
> Well doesn't my proposal solve the miner decentralization problem. Only
> the direct parent and children chains are merge mined. To be more clear,
> let the top chain to have level 1. Each chain that is a child of a chain of
> level n has level n+1. For any chain C, a block is accepted if the hash of
> its header has an appropriate number of trailing zeros (as usual). It can
> also be accepted with special transactions as I will explain. Let C be a
> chain of level n. Let C0,C1,,C9 be its children (each of level n+1).
> For any i in {0,1,...,9}, any solution to the mining problem of C can be
> inserted as a special transaction inside Ci and this enables the block to
> be accepted in Ci (so C and C0,C1,...,C9 are merge mined. But, for any i in
> {0,1,...,9} and any j in {0,1,...,9}, any solution to the mining problem of
> C cannot be inserted as a special transaction inside of child Cij of Ci. So
> that means all of the chains are not merge mined, only localised parts,
> right?
>
> By the way, we can eventually get rid of the block size 1 MB limit by
> requiring more than just the header to be hashed, but that can be done in
> the future as soft fork with sidechains, and is a side topic.
>
>
> --
> PGP: B6AC 822C 451D 6304 6A28  49E9 7DB7 011C D53B 5647
>



-- 
PGP: B6AC 822C 451D 6304 6A28  49E9 7DB7 011C D53B 5647
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Scaling Bitcoin with Subchains

[Andrew]

On Tue, Jun 16, 2015 at 6:17 PM, Peter Todd  wrote:

> Merge-mined sidechains are not a scaling solution any more than SPV is a
> scaling solution because they don't solve the scaling problem for
> miners.
>
> Some kind of treechain like sidechain / subchains where what part of the
> tree miners can mine is constrained to preserve fairness could be both a
> scaling solution, and decentralized, but no-one has come up with a solid
> design yet that's ready for production. (my treechains don't qualify for
> transactions yet; maybe for other proof-of-publication uses)
>
>
Well doesn't my proposal solve the miner decentralization problem. Only the
direct parent and children chains are merge mined. To be more clear, let
the top chain to have level 1. Each chain that is a child of a chain of
level n has level n+1. For any chain C, a block is accepted if the hash of
its header has an appropriate number of trailing zeros (as usual). It can
also be accepted with special transactions as I will explain. Let C be a
chain of level n. Let C0,C1,,C9 be its children (each of level n+1).
For any i in {0,1,...,9}, any solution to the mining problem of C can be
inserted as a special transaction inside Ci and this enables the block to
be accepted in Ci (so C and C0,C1,...,C9 are merge mined. But, for any i in
{0,1,...,9} and any j in {0,1,...,9}, any solution to the mining problem of
C cannot be inserted as a special transaction inside of child Cij of Ci. So
that means all of the chains are not merge mined, only localised parts,
right?

By the way, we can eventually get rid of the block size 1 MB limit by
requiring more than just the header to be hashed, but that can be done in
the future as soft fork with sidechains, and is a side topic.


-- 
PGP: B6AC 822C 451D 6304 6A28  49E9 7DB7 011C D53B 5647
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Scaling Bitcoin with Subchains

[Peter Todd]

On Mon, Jun 15, 2015 at 01:15:14PM -0400, Jeff Garzik wrote:
> On Mon, Jun 15, 2015 at 1:09 PM, Pieter Wuille 
> wrote:
> 
> > It's simple: either you care about validation, and you must validate
> > everything, or you don't, and you don't validate anything. Sidechains do
> > not offer you a useful compromise here, as well as adding huge delays and
> > conplexity.
> >
> 
> As noted to Adam last night - although I agree it adds complexity - side
> chains are one solution that will indeed help with scaling long term.
> Similar to the graph you see with git repos and merges, having aggregation
> chains that arbitrarily fork and then rejoin the main chain are both
> feasible and useful.
> 
> That code & future is a ways away from production, so doesn't help us
> here.  Still, let's not dismiss it as a solution either.

To be clear, it depends on what kind of sidechain.

My off-chain transaction notions are federated sidechains with an
economic incentive to not commit fraud using fidelity bonds; they were
definitely proposed as a scaling solution.

Merge-mined sidechains are not a scaling solution any more than SPV is a
scaling solution because they don't solve the scaling problem for
miners.

Some kind of treechain like sidechain / subchains where what part of the
tree miners can mine is constrained to preserve fairness could be both a
scaling solution, and decentralized, but no-one has come up with a solid
design yet that's ready for production. (my treechains don't qualify for
transactions yet; maybe for other proof-of-publication uses)

Keep in mind that other than preserving mining
decentralization/resisting censorship, we've known how to scale up
blockchains for ages w/ things like (U)TXO commitments and fraud proofs.

-- 
'peter'[:-1]@petertodd.org
127ab1d576dc851f374424f1269c4700ccaba2c42d97e778


signature.asc
Description: Digital signature
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Reusable payment codes

[Peter Todd]

On Tue, Jun 16, 2015 at 09:26:07AM -0700, odinn wrote:
> This is very well done.
> 
> Have you seen this discussion that I started regarding BIP 63?
> 
> https://bitcointalk.org/index.php?topic=1083961.0
> 
> I have no response from Peter Todd back on it other than "my time is
> better spent focusing on more fundemental issues" and "I've also got
> no-one interested in funding stealth address development right now,"
> when several people (myself included) offered to send donations to see
> the BIP (63) advance, no donation address was posted, so... waiting
> for him to act on that.

Sorry, but I'm looking at the huge amount of work that I'll likely have
responding to the blocksize issue, so I think I'm inclined to shelve
work on BIP63 for now.

Feel free to take it up; a (>=2)-part standard describing the resuable
codes aspect, and separately how the ephemeral key is transmitted to the
recipient makes sense to me.

-- 
'peter'[:-1]@petertodd.org
127ab1d576dc851f374424f1269c4700ccaba2c42d97e778


signature.asc
Description: Digital signature
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] The Bitcoin Node Market

[Aaron Voisine]

Alternate funding strategy: With 1billion users, mr roger ver is now among
the worlds first $trillionaires, and he generously donates to the
non-profit organization responsible for both the wildly popular wallet, and
his new found largess.

On Tuesday, June 16, 2015, justusranv...@riseup.net <
justusranv...@riseup.net> wrote:

> On 2015-06-16 07:55, Aaron Voisine wrote:
>
>> Suppose a billion mobile phones wanted to run SPV wallets tomorrow. Who
>>> would provide the nodes they would need connect to?
>>>
>>
>> The SPV wallet author would if they wanted their wallet to function.
>>
>
> How will the SPV wallet users pay for this service? With their money, or
> with their privacy?
>


-- 

Aaron Voisine
co-founder and CEO
breadwallet.com
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] The Bitcoin Node Market

[Aaron Voisine]

With their money, if they were to take advantage of optional additional
financial services, like, as one example, comsumer protection insurance.

Aaron

On Tuesday, June 16, 2015,  wrote:

> On 2015-06-16 07:55, Aaron Voisine wrote:
>
>> Suppose a billion mobile phones wanted to run SPV wallets tomorrow. Who
>>> would provide the nodes they would need connect to?
>>>
>>
>> The SPV wallet author would if they wanted their wallet to function.
>>
>
> How will the SPV wallet users pay for this service? With their money, or
> with their privacy?
>


-- 

Aaron Voisine
co-founder and CEO
breadwallet.com
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Reusable payment codes

[odinn]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

This is very well done.

Have you seen this discussion that I started regarding BIP 63?

https://bitcointalk.org/index.php?topic=1083961.0

I have no response from Peter Todd back on it other than "my time is
better spent focusing on more fundemental issues" and "I've also got
no-one interested in funding stealth address development right now,"
when several people (myself included) offered to send donations to see
the BIP (63) advance, no donation address was posted, so... waiting
for him to act on that.

I'm definitely supportive of seeing what you've written up here as
Reusable payment codes move to draft in https://github.com/bitcoin/bips
When you can, please write up something on bitcointalk as well.


On 04/24/2015 01:00 PM, Justus Ranvier wrote:
> Hash: SHA1
> 
> 
> https://github.com/justusranvier/rfc/blob/payment_code/bips/bip-pc01.m
ediawiki
>
> 
> 
> This link contains an RFC for a new type of Bitcoin address called
> a "payment code"
> 
> 
> Payment codes are SPV-friendly alternatives to DarkWallet-style
> stealth addresses which provide useful features such as positively
> identifying senders to recipients and automatically providing for
> transaction refunds.
> 
> 
> Payment codes can be publicly advertised and associated with a
> real-life identity without causing a loss of financial privacy.
> 
> 
> Compared to stealth addresses, payment codes require less
> blockchain data storage.
> 
> 
> Payment codes require 65 bytes of OP_RETURN data per
> sender-recipient pair, while stealth addresses require 40 bytes per
> transaction.
> 
> 
> 
> 
> 
> --
- 
>
> 
One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications 
> Performance metrics, stats and reports that give you Actionable
> Insights Deep dive visibility with transaction tracing using APM
> Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> 
> 
> 
> ___ Bitcoin-development
> mailing list Bitcoin-development@lists.sourceforge.net 
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> 

- -- 
http://abis.io ~
"a protocol concept to enable decentralization
and expansion of a giving economy, and a new social good"
https://keybase.io/odinn
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJVgE4fAAoJEGxwq/inSG8CjgkH/i0aX4aJaOjrbI2xzWbPeL1T
/APSvSqV0D610ljbw/MuRRFVagnK3lCs73fYolKw9uFG0cnwhIWJ53mCqPWhM5nL
kIejDTHr9jQ2tbXrU2L481Oat1Z6vtdQj7LolXFfD3Ktqz+sqp//gBaC9EEZ5nOq
4oz71Am58pf8+XGhtJk0+4XDXzFNd71bKKY+nMf9f3bwqNX93jHiF48hXwijFPC4
MOZmYRh3Sf5LAVP5p1JY3aJRQv4M/W0L2RDC+GW8Ol997etQSGGLhESihNNPw1m8
GEqJLBmUBkavzsRpZ009czfzL7EiCwsMbOrVw918o2Y9NnVpY9a9cBNB+UJgCmk=
=wAGz
-END PGP SIGNATURE-

--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] BIP for Proof of Payment

[Kalle Rosenbaum]

Thank you for the clarification Tom!

/Kalle

2015-06-16 16:05 GMT+02:00 Tom Harding :
> On 6/16/2015 5:12 AM, Kalle Rosenbaum wrote:
>> 2015-06-16 7:26 GMT+02:00 Tom Harding :
>>> Kalle goes to some trouble to describe how merchants need to ensure that
>>> they only accept a PoP provided as a response to their challenge.
>>>
>> Do you mean that it will be hard to explain to merchants that they
>> must check the nonce in the PoP so that it matches the nonce in the
>> pop request?
>
> Sorry for the idiomatic language.  No, I just meant that you have
> thought it out in detail!  You standardize a latent capability of the
> cryptosystem.  It seems very powerful for some classes of users.
>
>

--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] The Bitcoin Node Market

[devrandom]

On 2015-06-16 12:55 AM, Aaron Voisine wrote:
>> Suppose a billion mobile phones wanted to run SPV wallets tomorrow. Who
>> would provide the nodes they would need connect to? 
> 
> The SPV wallet author would if they wanted their wallet to function.

I would also guess that the cost to provide service to SPV wallets is
less than $0.01/mo per wallet and in any case less than long-term
transaction fees.  This can either be taken up by the wallet author or
transparently through a payment channel by the user.

> 
> 
> Aaron Voisine
> co-founder and CEO
> breadwallet.com 

-- 
devrandom / Miron

--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Scaling Bitcoin with Subchains

[Andrew]

Let me ask a simpler question. How do you prove the state of the UTXO
database corresponding to your wallet? With my subchain method, all the
addresses in a wallet can be constrained to a path of subchains, so the
proof is O(log n). Yes, I know some people will say that it is not really a
proof because I didn't verify the transactions involving sibling chains
outside my path of chains. But the protocol is "parent chain always decides
in case of conflict". And the parent chains will have an incentive to be
careful with what child blocks they commit to as they will be merge mining
the (direct) child chains. Yes, the parents can make a mistake with some
really deep children chain transactions, but the deeper you go, the less
value the transactions, and the less important. Also, the children of the
parents are parents themselves so they will have incentive to be careful
with what child chains they commit to. So recursively, the system takes
care of itself.

I challenge anyone to come up with a <= O(log n) proof that each address
(output) they have in their wallet really has the balance they think it
has. If someone can do this, then maybe I will drop this idea. Actually,
rusty asked this on #bitcoin-wizards last night and no one was able to
answer it.

On Mon, Jun 15, 2015 at 6:00 PM, Andrew  wrote:

> Pieter: I kind of see your point (but I think you're missing some key
> points). You mean just download all the headers and then just verify the
> transactions you filter out by using their corresponding merkle trees,
> right? But still, I don't think that would scale as well as with the tree
> structure I propose. Because, firstly, you don't really need the headers of
> the sibling chains. You just need the headers of the parent chains since
> the parent verifies all the siblings. All you really need in a typical
> (non-mining) situation is the headers or full blocks in one path going down
> the tree starting from the root chain. So that means O(log n) needs to be
> stored (headers or blocks) (n the number of transaction on the network).
> With big blocks, you still need O(n) headers. I know headers are small, but
> still they take up space and verification time. Also, since you are storing
> the full blocks on the chains you want, you are validating the headers of
> those blocks and you are sure that you are seeing all transactions on those
> blocks. And if certain addresses must stay on those blocks, you will know
> that you are catching all of the transactions corresponding to those
> blocks. If you just filter out based on addresses or other criteria, you
> can be denied some of those transactions by full nodes, and you may not
> know about it. Say for example, your government representative publishes on
> of his public addresses that is used for paying for expenses. Then with my
> system, you can be sure to catch every transaction being spent from that
> address (or UTXO or whatever you want to call it). If you just filter on
> any transaction that includes that address, you may not catch all of those
> transactions. Same with incoming funds.
>
> There are also advantages for mining decentralization as I have explained
> in my previous posts. So still not sure you are right here...
>
> Thanks
>
> On Mon, Jun 15, 2015 at 5:18 PM, Mike Hearn  wrote:
>
>> It's simple: either you care about validation, and you must validate
>>> everything, or you don't, and you don't validate anything.
>>>
>> Pedantically: you could validate a random subset of all scripts, to give
>> yourself probabilistic verification rather than full vs SPV. If enough
>> people do it with a large enough subset the probability of a problem being
>> detected goes up a lot. You still pay the cost of the database updates.
>>
>> But your main point is of course completely right, that side chains are
>> not a way to scale up.
>>
>
>
>
> --
> PGP: B6AC 822C 451D 6304 6A28  49E9 7DB7 011C D53B 5647
>



-- 
PGP: B6AC 822C 451D 6304 6A28  49E9 7DB7 011C D53B 5647
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] BIP for Proof of Payment

[Pieter Wuille]

On Mon, Jun 15, 2015 at 1:59 PM, Kalle Rosenbaum  wrote:

> 2015-06-15 12:00 GMT+02:00 Pieter Wuille :
> I'm not sure if we will be able to support PoP with CoinJoin. Maybe
> someone with more insight into CoinJoin have some input?
>

Not really. The problem is that you assume a transaction corresponds to a
single payment. This is true for simple wallet use cases, but not
compatible with CoinJoin, or with systems that for example would want to
combine multiple payments in a single transaction.


> > Also, if I understand correctly, there is no commitment to anything
> you're
> > trying to say about the sender? So once I obtain a proof-of-payment from
> you
> > about something you paid, I can go claim that it's mine?
>
> I don't understand this. The pop includes a nonce randomly generated
> by the server. If you're very lucky, 1/(2^48) per try, you can reuse a
> pop.
>
>
I owe you an apology here, for judging based on the summary you posted
rather than reading the actual text.

48 bits seems low to me, but it does indeed solve the problem. Why not 128
or 256 bits?

> Why does anyone care who paid? This is like walking into a coffeshop,
> > noticing I don't have money with me, let me friend pay for me, and then
> have
> > the shop insist that I can't drink it because I'm not the buyer.
>
> If you pay as you use the service (ie pay for coffee upfront), there's
> no need for PoP. Please see the Motivation section. But you are right
> that you must have the wallet(s) that paid at hand when you issue a
> PoP.
>
> >
> > Track payments, don't try to assign identities to payers.
>
> Please elaborate, I don't understand what you mean here.
>

I think that is a mistake. You should not assume that the wallet who held
the coins is the payer/buyer. That's what I said earlier; you're implicitly
creating an identity (the one who holds these keys) based on the
transaction. This seems fundamentally wrong to me, and not necessary. The
receiver should not care who paid or how, he should care what was payed for.

The easiest solution to this IMHO would be an extension to the payment
protocol that gives you (or your wallet) a token in return for paying, and
that knowledge of that token is used to gain access to the services you
provide.

-- 
Pieter
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] BIP for Proof of Payment

[Tom Harding]

On 6/16/2015 5:12 AM, Kalle Rosenbaum wrote:
> 2015-06-16 7:26 GMT+02:00 Tom Harding :
>> Kalle goes to some trouble to describe how merchants need to ensure that
>> they only accept a PoP provided as a response to their challenge.
>>
> Do you mean that it will be hard to explain to merchants that they
> must check the nonce in the PoP so that it matches the nonce in the
> pop request?

Sorry for the idiomatic language.  No, I just meant that you have
thought it out in detail!  You standardize a latent capability of the
cryptosystem.  It seems very powerful for some classes of users.



--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] questions about bitcoin-XT code fork & non-consensus hard-fork

[Pindar Wong]

On Tue, Jun 16, 2015 at 9:33 PM, Peter Todd  wrote:

> On Tue, Jun 16, 2015 at 08:33:31PM +0800, Pindar Wong wrote:
> > On Tue, Jun 16, 2015 at 2:03 AM, Adam Back  wrote:
> > Dear Adam, All:
> >
> > At the community's convenience, it would be an honour to arrange an
> initial
> > open summit to meet with representatives of the Chinese miners in Hong
> Kong
> > (UTC+8) to facilitate a better understand between the different
> > stakeholders of the Bitcoin ecosystem on this important issue.   This
> could
> > be arranged for this October, or earlier, if deemed necessary.
>
> Great!
>
> FWIW there Constance Choi and Primavera De Filippi (CC'd) are holding a
> blockchain-tech conference October 14th-15th in Hong Kong as well;
> coordinating your summit with that conference could be useful.
>
> http://blockchainworkshops.org/
>
> This workshop series has been attracting audiences of people looking to
> use blockchain tech in general; many of these use-cases will likely
> involve the Bitcoin blockchain in unpredictable ways. Importantly, these
> ways can drive demand significantly beyond our current assumptions based
> on most demand being consumer-merchant transactions.
>
> In addition, many of the attendees have significant experience with
> regulatory issues and interacting with governments on regulation of
> blockchain tech. Bitcoin faces existential risks to its existence by
> these regulation efforts, which include things like efforts to setup
> industry wide Anti-Money-Laundering/Know-Your-Customer programs,
> including programs that would tie on-chain transactions to identity
> information. Any blocksize discussion needs to be informed by these
> potential threats to usage of the technology, as well as challenges to
> using scaling solutions.
>
> > Remote online participation would be welcome from those who might not be
> > able to attend in person.
> >
> > However,  it is hoped that such a meeting would be primarily document
> > driven to facilitate orderly translation, discussion and decision.
>
> Agreed. Pieter Wuille's recent work is a great example of the kind of
> science-driven investigations that need to be done - and haven't been
> done very much - to get us some hard data to make decisions on.
>

Thank you very much Peter for pointing this out! That is very kind of you.

It would be great to work with Constance Choi, Primavera De Filippi, your
goodself and others to make this happen.

As you may know, the Hong Kong Monetary Authority considers bitcoin a
virtual 'commodity' and not a currency per se.

Regards,

p.


>
> --
> 'peter'[:-1]@petertodd.org
> 127ab1d576dc851f374424f1269c4700ccaba2c42d97e778
>
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] questions about bitcoin-XT code fork & non-consensus hard-fork

[Peter Todd]

On Tue, Jun 16, 2015 at 08:33:31PM +0800, Pindar Wong wrote:
> On Tue, Jun 16, 2015 at 2:03 AM, Adam Back  wrote:
> Dear Adam, All:
> 
> At the community's convenience, it would be an honour to arrange an initial
> open summit to meet with representatives of the Chinese miners in Hong Kong
> (UTC+8) to facilitate a better understand between the different
> stakeholders of the Bitcoin ecosystem on this important issue.   This could
> be arranged for this October, or earlier, if deemed necessary.

Great!

FWIW there Constance Choi and Primavera De Filippi (CC'd) are holding a
blockchain-tech conference October 14th-15th in Hong Kong as well;
coordinating your summit with that conference could be useful.

http://blockchainworkshops.org/

This workshop series has been attracting audiences of people looking to
use blockchain tech in general; many of these use-cases will likely
involve the Bitcoin blockchain in unpredictable ways. Importantly, these
ways can drive demand significantly beyond our current assumptions based
on most demand being consumer-merchant transactions.

In addition, many of the attendees have significant experience with
regulatory issues and interacting with governments on regulation of
blockchain tech. Bitcoin faces existential risks to its existence by
these regulation efforts, which include things like efforts to setup
industry wide Anti-Money-Laundering/Know-Your-Customer programs,
including programs that would tie on-chain transactions to identity
information. Any blocksize discussion needs to be informed by these
potential threats to usage of the technology, as well as challenges to
using scaling solutions.

> Remote online participation would be welcome from those who might not be
> able to attend in person.
> 
> However,  it is hoped that such a meeting would be primarily document
> driven to facilitate orderly translation, discussion and decision.

Agreed. Pieter Wuille's recent work is a great example of the kind of
science-driven investigations that need to be done - and haven't been
done very much - to get us some hard data to make decisions on.

-- 
'peter'[:-1]@petertodd.org
127ab1d576dc851f374424f1269c4700ccaba2c42d97e778


signature.asc
Description: Digital signature
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] The Bitcoin Node Market

[justusranvier]

On 2015-06-16 07:55, Aaron Voisine wrote:
>> Suppose a billion mobile phones wanted to run SPV wallets tomorrow. 
>> Who
>> would provide the nodes they would need connect to?
> 
> The SPV wallet author would if they wanted their wallet to function.

How will the SPV wallet users pay for this service? With their money, or 
with their privacy?

--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] questions about bitcoin-XT code fork & non-consensus hard-fork

[Pindar Wong]

On Tue, Jun 16, 2015 at 2:03 AM, Adam Back  wrote:

> Hi Mike
>
> Well thank you for replying openly on this topic, its helpful.
>
> I apologise in advance if this gets quite to the point and at times
> blunt, but transparency is important, and we owe it to the users who
> see Bitcoin as the start of a new future and the$3b of invested funds
> and $600m of VC funds invested in companies, we owe it to them that we
> be open and transparent here.
>
> I would really prefer on a personal nor professional basis to be
> having this conversation period, never mind in public, but Mike - your
> and Gavin's decision to promote a unilateral hard-fork and code fork
> are extremely high risk for bitcoin and so there remains little
> choice.  So I apologise again that we have to have this kind of
> conversation on a technical discussion list.  This whole thing is
> hugely stressful and worrying for developers, companies and investors.
>
> I strongly urge that we return to the existing collaborative
> constructive review process that has been used for the last 4 years
> which is a consensus by design to prevent one rogue person from
> inserting a backdoor, or lobbying for a favoured change on behalf of a
> special interest group, or working for bad actor (without accusing you
> of any of those - I understand you personally just want to scale
> bitcoin, but are inclined to knock heads and try to force an issue you
> see, rather than work collaboratively).
>
> For you (and everyone)
>
> - Should there be a summit of some kind, that is open attendance, and
> video recorded so that people who are unable to attend can participate
> too, so that people can present the technical proposals and risks in
> an unbiased way?
>
>
Dear Adam, All:

At the community's convenience, it would be an honour to arrange an initial
open summit to meet with representatives of the Chinese miners in Hong Kong
(UTC+8) to facilitate a better understand between the different
stakeholders of the Bitcoin ecosystem on this important issue.   This could
be arranged for this October, or earlier, if deemed necessary.

Remote online participation would be welcome from those who might not be
able to attend in person.

However,  it is hoped that such a meeting would be primarily document
driven to facilitate orderly translation, discussion and decision.

p.



> (It is not theoretical question, I may have a sponsor and host - not
> Blockstream, an independent, its a question for everyone, developers,
> users, CTOs, CEOs.)
>
>
>
> So here I come back to more frank questions:
>
> Governance
>
> The rest of the developers are wise to realise that they do not want
> exclusive control, to avoid governance centralising into the hands of
> one person, and this is why they have shared it with a consensus
> process over the last 4 years.  No offence but I dont think you
> personally are thinking far enough ahead to think you want personal
> control of this industry.  Maybe some factions dont trust your
> motives, or they dont mind, but feel more assured if a dozen other
> people are closely reviewing and have collective review authority.
>
> - Do you understand that attempting to break this process by
> unilateral hard-fork is extremely weakening of Bitcoin's change
> governance model?
>
> - Do you understand that change governance is important, and that it
> is important that there be multiple reviewers and sign-off to avoid
> someone being blackmailed or influenced by an external party - which
> could potentially result in massive theft of funds if something were
> missed?
>
> - Secondarily do you understand that even if you succeed in a
> unilateral fork (and the level of lost coins and market cap and damage
> to confidence is recoverable), that it sets a precedent that others
> may try to follow in the future to introduce coercive features that
> break the assurances of bitcoin, like fungibility reducing features
> say (topically I hear you once proposed on a private forum the concept
> of red-lists, other such proposals have been made and quickly
> abandoned), or ultimately if there is a political process to obtain
> unpopular changes by unilateral threat, the sky is the limit - rewrite
> the social contract at that point without consensus, but by
> calculation that people will value Bitcoin enough that they will
> follow a lead to avoid risk to the system?
>
>
> Security
>
> As you probably know some extremely subtle bugs in Bitcoin have at
> times slipped past even the most rigorous testings, often with
> innocuous but unexpected behaviours, but some security issues  Some
> extremely intricate and time-sensitive security defect and incident
> response happens from time to time which is not necessarily publicly
> disclosed until after the issue has been rolled out and fixed, which
> can take some time due to the nature of protocol upgrades,
> work-arounds, software upgrade via contacting key miners etc.  We
> could take an example of the openSSL bug.
>
> - How d

Re: [Bitcoin-development] BIP for Proof of Payment

[Kalle Rosenbaum]

Another thing worth mentioning is that an SPV wallet cannot validate a
PoP without fetching the input transactions of the PoP from an
external (not bitcoin network) source, for example chain.com or some
other trusted full node's API.

The validation of the PoP depends on the external source(s) being
honest. It can make a valid pop look invalid, but it cannot make an
invalid pop look valid.

/Kalle



2015-06-16 14:12 GMT+02:00 Kalle Rosenbaum :
> 2015-06-16 7:26 GMT+02:00 Tom Harding :
>>
>> Kalle goes to some trouble to describe how merchants need to ensure that
>> they only accept a PoP provided as a response to their challenge.
>>
>
> Do you mean that it will be hard to explain to merchants that they
> must check the nonce in the PoP so that it matches the nonce in the
> pop request? I think not, this is a commonly used pattern that anyone
> should be able to grasp. Anyway, merchants will probably use a library
> (though yet non-existing) for PoP, that will hide the gory details. I
> also think that payment providers may want to add PoP to their
> offering to customers (merchants).
>
> Regards,
> /Kalle
>
>>
>>
>> On 6/15/2015 3:00 AM, Pieter Wuille wrote:
>>
>> I did misunderstand that. That changes things significantly.
>>
>> However, having paid is not the same as having had access to the input
>> coins. What about shared wallets or coinjoin?
>>
>> Also, if I understand correctly, there is no commitment to anything you're
>> trying to say about the sender? So once I obtain a proof-of-payment from you
>> about something you paid, I can go claim that it's mine?
>>
>> Why does anyone care who paid? This is like walking into a coffeshop,
>> noticing I don't have money with me, let me friend pay for me, and then have
>> the shop insist that I can't drink it because I'm not the buyer.
>>
>> Track payments, don't try to assign identities to payers.
>>
>> On Jun 15, 2015 11:35 AM, "Kalle Rosenbaum"  wrote:
>>>
>>> Hi Pieter!
>>>
>>> It is intended to be a proof that you *have paid* for something. Not
>>> that you have the intent to pay for something. You cannot use PoP
>>> without a transaction to prove.
>>>
>>> So, yes, it's just a proof of access to certain coins that you no longer
>>> have.
>>>
>>> Maybe I don't understand you correctly?
>>>
>>> /Kalle
>>>
>>> 2015-06-15 11:27 GMT+02:00 Pieter Wuille :
>>> > Now that you have removed the outputs, I don't think it's even a intent
>>> > of
>>> > payment, but just a proof of access to certain coins.
>>> >
>>> > On Jun 15, 2015 11:24 AM, "Kalle Rosenbaum"  wrote:
>>> >>
>>> >> Hi all!
>>> >>
>>> >> I have made the discussed changes and updated my implementation
>>> >> (https://github.com/kallerosenbaum/poppoc) accordingly. These are the
>>> >> changes:
>>> >>
>>> >> * There is now only one output, the "pop output", of value 0.
>>> >> * The sequence number of all inputs of the PoP must be set to 0. I
>>> >> chose to set it to 0 for all inputs for simplicity.
>>> >> * The lock_time of the PoP must be set to 4 (max block height
>>> >> lock
>>> >> time).
>>> >>
>>> >> The comments so far has been mainly positive or neutral. Are there any
>>> >> major objections against any of the two proposals? If not, I will ask
>>> >> Gregory Maxwell to assign them BIP numbers.
>>> >>
>>> >> The two BIP proposals can be found at
>>> >> https://github.com/kallerosenbaum/poppoc/wiki/Proof-of-Payment-BIP and
>>> >> https://github.com/kallerosenbaum/poppoc/wiki/btcpop-scheme-BIP. The
>>> >> source
>>> >> for the Proof of Payment BIP proposal is also in-lined below.
>>> >>
>>> >> A number of alternative names have been proposed:
>>> >>
>>> >> * Proof of Potential
>>> >> * Proof of Control
>>> >> * Proof of Signature
>>> >> * Signatory Proof
>>> >> * Popo: Proof of payment origin
>>> >> * Pots: Proof of transaction signer
>>> >> * proof of transaction intent
>>> >> * Declaration of intent
>>> >> * Asset-access-and-action-affirmation, AAaAA, or A5
>>> >> * VeriBit
>>> >> * CertiBTC
>>> >> * VBit
>>> >> * PayID
>>> >>
>>> >> Given this list, I still think "Proof of Payment" is the most
>>> >> descriptive
>>> >> to non-technical people.
>>> >>
>>> >> Regards,
>>> >> Kalle
>>> >>
>>> >>
>>> >> #
>>> >> 
>>> >>   BIP: 
>>> >>   Title: Proof of Payment
>>> >>   Author: Kalle Rosenbaum 
>>> >>   Status: Draft
>>> >>   Type: Standards Track
>>> >>   Created: 
>>> >> 
>>> >>
>>> >> == Abstract ==
>>> >>
>>> >> This BIP describes how a wallet can prove to a server that it has the
>>> >> ability to sign a certain transaction.
>>> >>
>>> >> == Motivation ==
>>> >>
>>> >> There are several scenarios in which it would be useful to prove that
>>> >> you
>>> >> have paid for something. For example:
>>> >>
>>> >> * A pre-paid hotel room where your PoP functions as a key to the door.
>>> >> * An online video rental service where you pay for a video and watch it
>>> >> on
>>> >> any device.
>>> >> * An ad-sign where you pay in advance for e.g. 2 w

Re: [Bitcoin-development] BIP for Proof of Payment

[Kalle Rosenbaum]

2015-06-16 7:26 GMT+02:00 Tom Harding :
>
> Kalle goes to some trouble to describe how merchants need to ensure that
> they only accept a PoP provided as a response to their challenge.
>

Do you mean that it will be hard to explain to merchants that they
must check the nonce in the PoP so that it matches the nonce in the
pop request? I think not, this is a commonly used pattern that anyone
should be able to grasp. Anyway, merchants will probably use a library
(though yet non-existing) for PoP, that will hide the gory details. I
also think that payment providers may want to add PoP to their
offering to customers (merchants).

Regards,
/Kalle

>
>
> On 6/15/2015 3:00 AM, Pieter Wuille wrote:
>
> I did misunderstand that. That changes things significantly.
>
> However, having paid is not the same as having had access to the input
> coins. What about shared wallets or coinjoin?
>
> Also, if I understand correctly, there is no commitment to anything you're
> trying to say about the sender? So once I obtain a proof-of-payment from you
> about something you paid, I can go claim that it's mine?
>
> Why does anyone care who paid? This is like walking into a coffeshop,
> noticing I don't have money with me, let me friend pay for me, and then have
> the shop insist that I can't drink it because I'm not the buyer.
>
> Track payments, don't try to assign identities to payers.
>
> On Jun 15, 2015 11:35 AM, "Kalle Rosenbaum"  wrote:
>>
>> Hi Pieter!
>>
>> It is intended to be a proof that you *have paid* for something. Not
>> that you have the intent to pay for something. You cannot use PoP
>> without a transaction to prove.
>>
>> So, yes, it's just a proof of access to certain coins that you no longer
>> have.
>>
>> Maybe I don't understand you correctly?
>>
>> /Kalle
>>
>> 2015-06-15 11:27 GMT+02:00 Pieter Wuille :
>> > Now that you have removed the outputs, I don't think it's even a intent
>> > of
>> > payment, but just a proof of access to certain coins.
>> >
>> > On Jun 15, 2015 11:24 AM, "Kalle Rosenbaum"  wrote:
>> >>
>> >> Hi all!
>> >>
>> >> I have made the discussed changes and updated my implementation
>> >> (https://github.com/kallerosenbaum/poppoc) accordingly. These are the
>> >> changes:
>> >>
>> >> * There is now only one output, the "pop output", of value 0.
>> >> * The sequence number of all inputs of the PoP must be set to 0. I
>> >> chose to set it to 0 for all inputs for simplicity.
>> >> * The lock_time of the PoP must be set to 4 (max block height
>> >> lock
>> >> time).
>> >>
>> >> The comments so far has been mainly positive or neutral. Are there any
>> >> major objections against any of the two proposals? If not, I will ask
>> >> Gregory Maxwell to assign them BIP numbers.
>> >>
>> >> The two BIP proposals can be found at
>> >> https://github.com/kallerosenbaum/poppoc/wiki/Proof-of-Payment-BIP and
>> >> https://github.com/kallerosenbaum/poppoc/wiki/btcpop-scheme-BIP. The
>> >> source
>> >> for the Proof of Payment BIP proposal is also in-lined below.
>> >>
>> >> A number of alternative names have been proposed:
>> >>
>> >> * Proof of Potential
>> >> * Proof of Control
>> >> * Proof of Signature
>> >> * Signatory Proof
>> >> * Popo: Proof of payment origin
>> >> * Pots: Proof of transaction signer
>> >> * proof of transaction intent
>> >> * Declaration of intent
>> >> * Asset-access-and-action-affirmation, AAaAA, or A5
>> >> * VeriBit
>> >> * CertiBTC
>> >> * VBit
>> >> * PayID
>> >>
>> >> Given this list, I still think "Proof of Payment" is the most
>> >> descriptive
>> >> to non-technical people.
>> >>
>> >> Regards,
>> >> Kalle
>> >>
>> >>
>> >> #
>> >> 
>> >>   BIP: 
>> >>   Title: Proof of Payment
>> >>   Author: Kalle Rosenbaum 
>> >>   Status: Draft
>> >>   Type: Standards Track
>> >>   Created: 
>> >> 
>> >>
>> >> == Abstract ==
>> >>
>> >> This BIP describes how a wallet can prove to a server that it has the
>> >> ability to sign a certain transaction.
>> >>
>> >> == Motivation ==
>> >>
>> >> There are several scenarios in which it would be useful to prove that
>> >> you
>> >> have paid for something. For example:
>> >>
>> >> * A pre-paid hotel room where your PoP functions as a key to the door.
>> >> * An online video rental service where you pay for a video and watch it
>> >> on
>> >> any device.
>> >> * An ad-sign where you pay in advance for e.g. 2 weeks exclusivity.
>> >> During
>> >> this period you can upload new content to the sign whenever you like
>> >> using
>> >> PoP.
>> >> * Log in to a pay site using a PoP.
>> >> * A parking lot you pay for monthly and the car authenticates itself
>> >> using
>> >> PoP.
>> >> * A lottery where all participants pay to the same address, and the
>> >> winner
>> >> is selected among the transactions to that address. You exchange the
>> >> prize
>> >> for a PoP for the winning transaction.
>> >>
>> >> With Proof of Payment, these use cases can be achieved without any
>> >> personal informat

Re: [Bitcoin-development] questions about bitcoin-XT code fork & non-consensus hard-fork

[Mike Hearn]

>
> "How do you plan to deal with security & incident response for the
> duration you describe where you will have control while you are deploying
> the unilateral hard-fork and being in sole maintainership control?"
>

How do we plan to deal with security & incident response - exactly the same
way as before. Remember that XT is basically Core plus a few patches.

Gavin and myself are both on the bitcoin-security mailing list and have
been for years. Both of us have experience of responding to very serious
and tight-deadline security incidents, for example, the accidental bdb hard
fork and (in my case) when we discovered that Android phones had so little
entropy in them that different devices were actually generating the same
keys!

That one required co-ordinated crash rollouts of multiple wallets across
the Bitcoin ecosystem because there was a parallel investigation into key
collisions taking place in an open forum and they were not far from
discovering the truth about how badly the Android RNG was broken   (I knew
because at the time I had access to the Google internal Android bug
tracker). I organised the whole thing.

So I think we'll manage. But I don't expect things to exist in a state of
disjointness for very long. XT will rebase on top of Core and follow it's
releases for as long as there seems to be interest in bigger blocks and as
long as I have the time/energy/interest. If the >1mb chain wins then Core
will have to adopt the new ruleset or simply stop being relevant, as it
will have no users. That wouldn't make much sense.

Now, there have been concerns raised that a hard fork is unbelievably
risky, the sky will fall, the value of Bitcoin will drop to zero, etc. I
don't believe it's anywhere near that risky. The patch Gavin is working on
requires both a miner majority *and* also has a date trigger in it. Much
like previous forks, in fact. So nobody should be taken by surprise if/when
bigger blocks appear, because it will have been known for a long time
beforehand that there was sufficiently strong consensus, there will have
been messages printed to the node logs, announcements in various places and
so on.

Does that help clear things up?
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] questions about bitcoin-XT code fork & non-consensus hard-fork

[Mike Hearn]

Hi Bryan,

Specifically, when Adam mentioned your conversations with non-technical
> people, he did not mean "Mike has talked with people who have possibly not
> made pull requests to Bitcoin Core, so therefore Mike is a non-programmer".
>

Yes, my comment was prickly and grumpy. No surprises, I did not sleep well
last night.

I am upset about this constant insistence from Adam, Gregory and others
that the "technical community" or "technical majority" agree with them and
anyone who doesn't is "non technical" or "not a contributor" or not an
expert or not had things properly explained to them.

This is not true and needs to stop. Gavin and I have both been working on
Bitcoin in substantial ways for longer than Gregory and Adam have been in
the community at all. We are extremely technical, as are many of the people
who want us to release XT+larger blocks. We cannot make progress in any
kind of negotiation if one side constantly blows off the other and refuses
to take anything they say seriously, which has been a feature of this
"debate" from the start.

In contrast Gavin and I have written vast amounts of analysis on the
concerns raised by larger blocks. So many hours were spent, we could
probably fill a small book by now. We have carefully read and addressed
*dozens* of points raised by the 1mb camp. We have also done our best to
open this debate to the whole community.

So it would be nice if the people who are so keen on 1mb blocks show the
same respect to us.
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] questions about bitcoin-XT code fork & non-consensus hard-fork

[Tier Nolan]

On Tue, Jun 16, 2015 at 6:18 AM, Venzen  wrote:

> Mike Hearn, you should cease your activity of a unilateral hard-fork
> immediately. You are doing untold damage by breaking FOSS governance
> protocol requiring methodical collaborative work and due process of
> change implementation by consensus.


The main principle of open source software is that anyone can fork the code
if they wish.  They don't do it very often, but they can.

This means that if a project dies, someone can take it over.  If some of
the devs want to take things in a different direction, they can.  Users can
decide which version they prefer.

The software itself is what is valuable.

In the case of bitcoin, the blockchain is also (very) valuable.  Simply
splitting into two projects is not possible for bitcoin.

Otherwise, the discussion would have ended already, those who want a larger
block would simply create a fork of the software and create an alt chain.

The fundamental problem is that there is no clear way to make this decision
once and for all.

An agreed set of rules for a hard fork would be a nice thing to have, but
it is hard to have rules about how to change fundamental rules.

I think using the soft fork rules (maybe with a higher threshold than 95%)
plus a delay is a reasonable compromise on hard fork rules.

Even then, it would be nice to include users of the software too.  Peter
Todd's suggestion of encoding a vote in transactions is a step in that
direction (YES transactions in YES blocks and NO transactions in NO blocks).


> Mike Hearn and Gavin Andresen do not own Bitcoin and, emphatically,
> you cannot have it.


Nobody owns it, so there is no court of final appeal.

If miners vote >95% for the fork, users could still refuse to accept the
change.

Maybe the sequence could be

version 3 blocks means no opinion
version 4 blocks means NO to fork
version 5 blocks means YES to fork & YES transactions
version 6 blocks means YES to fork & NO transactions

Transaction matching rule:

version 1, 2, 3 transactions means no opinion (can be in any block)
version 4 transactions means YES to fork (cannot be in version 6 blocks)
version 5 transactions means NO to fork (cannot be in version 5 blocks)

Rules
0) if 750 of the last 1000 blocks are version 5 or 6 blocks, tx matching
rule activates for version 5 & 6 blocks
1) if 950 of the last 1000 blocks are version 5 or 6 blocks, then version 4
blocks are rejected
2) if 750 of the last 1000 blocks are version 4 blocks, then version 5 & 6
blocks are rejected
3) if 750 of the last 1000 blocks are version 5 transactions and 950 of the
last 1000 are version 5 or 6, then the fork is accepted
4) 25,000 blocks after 3 is accepted, hard fork actually takes effect

Once miner acceptance is achieved, then only version 5 and 6 blocks are
allowed.  The split between version 5 and 6 blocks should be roughly in
proportion to the number of transactions of each kind produced.

75% of miners can kill the fork by producing version 4 blocks, but 95% is
needed for acceptance.  Even then, transaction volume needs to support the
fork.  I think 75% is reasonable here.  (95% of miners and 75% of
merchants/users is a pretty strong majority).


> You may accuse the community for being antagonistic to you, and
> therefore uncooperative, but it is plain to see that your bullheaded
> manner eventually generates antagonism wherever you go. Taking Bitcoin
> away from this community, in anger, won't solve the problem and will
> be like killing the goose that lays the golden eggs.
>

They are still suggesting some kind of fork threshold process (or at least
that is what is being suggested)

If their system requires 95% miner approval, they aren't taking unilateral
action.  Miners are though if they vote in favour.
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] questions about bitcoin-XT code fork & non-consensus hard-fork

[Benjamin]

"And it allows the minority to hold the majority hostage"

The Bitcoin protocol has no definitions about developer consensus .
The reference to FOSS is quite arbitrary. The alternative of lobbying
companies is equally indeterminate and arbitrary. One of the core
problem is that you can't poll users about features, and even if one
could users are unlikely to be able to make design decisions about the
system. Voting is a quite imperfect mechanism. IF there would be a
hardfork vote of this kind, at least each party should lay out a
longterm plan and proposal. Mike and Gavin don't have any plans to
implement new scaling facilities and Lightening is not a coherent
proposal. In effect this fork battle would not be part of a BIP
process, but a vote on a longterm plan/architecture.

On Tue, Jun 16, 2015 at 8:09 AM, Marcel Jamin  wrote:
>> Mike Hearn and Gavin Andresen do not own Bitcoin and, emphatically,
> you cannot have it.
>
> Neither do you or anyone else.
>
>> There is protocol for how change is effected in a FOSS project.
>
> And it allows the minority to hold the majority hostage.
>
>> If you take the risks with Mike&GavCoin, that would be fine, but you are
>> about to take them with community-owned Bitcoin and Other People's Money!
>
> The same can be said about the other camp.
>
> BitcoinXT is not going to fork the chain on a specific date no matter what.
> People will be able to vote via block versions and once a sufficient
> majority supports the extensions, everyone else will have a grace period to
> upgrade. Only after that is a very small minority at risk of losing money.
>
> That being said, I'd rather see a solution that everyone agrees on. My
> personal opinion/hope is that Mike and Gavin are just applying pressure
> where it's needed. But in the end, they can do whatever they want if they
> have the necessary support. Permissionless innovation is one of bitcoins
> virtues. In the end, only adoption will decide what bitcoin is and isn't.
>
> 2015-06-16 7:18 GMT+02:00 Venzen :
>>
>> Mike Hearn,
>>
>> In the light of your responses to Adam Back's questions, below, I feel
>> it is time to speak up because what I now understand, and is implied,
>> is that Mike Hearn and Gavin Andresen have planned and deployed the
>> infrastructure for a Bitcoin hard-fork and intend to action it despite
>> majority opposition.  http://xtnodes.com/
>>
>> I'll try to keep it brief:
>>
>> Mike Hearn, you should cease your activity of a unilateral hard-fork
>> immediately. You are doing untold damage by breaking FOSS governance
>> protocol requiring methodical collaborative work and due process of
>> change implementation by consensus. Your actions are bad for the
>> Bitcoin project and its ideals, disrespectful of your peers and years
>> of their passionate hard work, and dangerous for Bitcoin in the
>> marketplace and bitcoin in peoples' wallets.
>>
>> Mike Hearn and Gavin Andresen do not own Bitcoin and, emphatically,
>> you cannot have it. Your hard-fork is tantamount to theft and you and
>> your collaborators will effectively ex-communicate yourselves from
>> this project and community. It appears that you are consciously trying
>> to usurp ownership and maintenance of Bitcoin. As if it is that easy!
>> You clearly do not comprehend the array of risks - especially the
>> unanticipated ones. As the market saying goes: "If you think
>> speculation is easy, it is because you are ignorant about the risks".
>> If you take the risks with Mike&GavCoin, that would be fine, but you
>> are about to take them with community-owned Bitcoin and Other People's
>> Money!
>>
>> You are causing a lot of stress, unnecessarily, and grave concern
>> surrounds your proposed renegade action. You can dissolve the threat:
>> those players to whom you have made promises can be appeased and
>> eventually get most of what they need from this FOSS project. The
>> developers whom you are railroading to get your way, and the way in
>> which you are doing it, is about to cause a schism that will expand
>> outward from this community.
>>
>> You may accuse the community for being antagonistic to you, and
>> therefore uncooperative, but it is plain to see that your bullheaded
>> manner eventually generates antagonism wherever you go. Taking Bitcoin
>> away from this community, in anger, won't solve the problem and will
>> be like killing the goose that lays the golden eggs.
>>
>> If an individual in an objectively agreed-to FOSS-modelled
>> collaborative project has the audacity to threaten his peers and the
>> world with a unilateral hard-fork despite majority objection and a
>> probability distribution that includes terminal risks and unintended
>> consequences, then what would an impartial outsider think? Some of
>> their thoughts would include that the antagonist could be acting in
>> self-interest, or may be a paid actor, or worse, a saboteur. What
>> would they advise? Stop that individual, at once!
>>
>> Bitcoin is a Free and Open Source Softw

Re: [Bitcoin-development] The Bitcoin Node Market

[Aaron Voisine]

> Suppose a billion mobile phones wanted to run SPV wallets tomorrow. Who
> would provide the nodes they would need connect to?

The SPV wallet author would if they wanted their wallet to function.


Aaron Voisine
co-founder and CEO
breadwallet.com

On Mon, Jun 15, 2015 at 10:28 PM,  wrote:

> On 2015-06-16 03:49, Kevin Greene wrote:
> > ​Hah, fair enough, there is no such thing as the "right" way to do
> > anything. But I still think punishing users who use SPV wallets is ​a
> > less-than-ideal way to incentive people to run full nodes. Right now
> > SPV is
> > the best way that exists for mobile phones to participate in the
> > network in
> > a decentralized way. This proposal makes the user experience for mobile
> > wallets a little more confusing and annoying.
>
> Suppose a billion mobile phones wanted to run SPV wallets tomorrow. Who
> would provide the nodes they would need connect to? The decentralization
> fairy?
>
> There's absolutely no reason that paying for connectivity would be any
> more confusing or annoying than transaction fees are.
>
> If some full nodes in the network started offering paid connection
> slots, that would just mean that users who checked the "pay subscription
> fee" box in their wallet configuration would have an easier time
> connecting than the users who did't, just like how your transaction
> might eventually get mined without a fee but paying one makes it faster
> and more probable.
>
>
> --
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] [RFC] Canonical input and output ordering in transactions

[Jorge Timón]

On Jun 15, 2015 11:43 PM, "Rusty Russell"  wrote:

> Though Peter Todd's more general best-effort language might make more
> sense.  It's not like you can hide an OP_RETURN transaction to make it
> look like something else, so that transaction not going to be
> distinguished by non-canonical ordering.

What about commitments that don't use op_return (ie pay2contract
commitments)?

In any case, if the motivation is ordering in multi-party transactions
there should be ways to do it without any consequences for other
transaction types' privacy. For example you could have a deterministic
method that depends on a random seed all parties in the transaction
previously share. That way the ordering is deterministic for all parties
involved in the transaction (which can use whatever channel they're using
to send the parts to also send this random seed) while at the same time the
order looks random (or at least not cannonical in a recognisable way) to
everyone else.
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development