Re: [Bitcoin-development] questions about bitcoin-XT code fork non-consensus hard-fork
On Tue, Jun 16, 2015 at 2:03 AM, Adam Back a...@cypherspace.org 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 do you plan to deal with security incident response for the duration
Re: [Bitcoin-development] The Bitcoin Node Market
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
On Tue, Jun 16, 2015 at 08:33:31PM +0800, Pindar Wong wrote: On Tue, Jun 16, 2015 at 2:03 AM, Adam Back a...@cypherspace.org 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] BIP for Proof of Payment
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 ka...@rosenbaum.se: 2015-06-16 7:26 GMT+02:00 Tom Harding t...@thinlink.com: 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 ka...@rosenbaum.se 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 pieter.wui...@gmail.com: 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 ka...@rosenbaum.se 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 # pre BIP: BIP number Title: Proof of Payment Author: Kalle Rosenbaum ka...@rosenbaum.se Status: Draft Type: Standards Track Created: date created on, in ISO 8601 (-mm-dd) format /pre == 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
Re: [Bitcoin-development] questions about bitcoin-XT code fork non-consensus hard-fork
On Tue, Jun 16, 2015 at 9:33 PM, Peter Todd p...@petertodd.org 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 a...@cypherspace.org 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] BIP for Proof of Payment
Thank you for the clarification Tom! /Kalle 2015-06-16 16:05 GMT+02:00 Tom Harding t...@thinlink.com: On 6/16/2015 5:12 AM, Kalle Rosenbaum wrote: 2015-06-16 7:26 GMT+02:00 Tom Harding t...@thinlink.com: 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] Reusable payment codes
-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] Scaling Bitcoin with Subchains
On Tue, Jun 16, 2015 at 6:17 PM, Peter Todd p...@petertodd.org 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] Reusable payment codes
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] Scaling Bitcoin with Subchains
On Mon, Jun 15, 2015 at 01:15:14PM -0400, Jeff Garzik wrote: On Mon, Jun 15, 2015 at 1:09 PM, Pieter Wuille pieter.wui...@gmail.com 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] BIP for Proof of Payment
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 ka...@rosenbaum.se wrote: 2015-06-16 21:25 GMT+02:00 Pieter Wuille pieter.wui...@gmail.com: 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 ka...@rosenbaum.se wrote: Thank you for your comments Pieter! Please find my answers below. 2015-06-16 16:31 GMT+02:00 Pieter Wuille pieter.wui...@gmail.com: On Mon, Jun 15, 2015 at 1:59 PM, Kalle Rosenbaum ka...@rosenbaum.se wrote: 2015-06-15 12:00 GMT+02:00 Pieter Wuille pieter.wui...@gmail.com: 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
Re: [Bitcoin-development] [BIP draft] Consensus-enforced transaction replacement signalled via sequence numbers
On Wed, Jun 17, 2015 at 1:00 AM, Mark Friedenbach m...@friedenbach.org 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] Reusable payment codes
-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] Proposal: Move Bitcoin Dev List to a Neutral Competent Entity
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] [RFC] Canonical input and output ordering in transactions
On Jun 15, 2015 11:43 PM, Rusty Russell ru...@rustcorp.com.au 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
Re: [Bitcoin-development] The Bitcoin Node Market
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, justusranv...@riseup.net wrote: On 2015-06-16 03:49, Kevin Greene wrote: Hah, fair enough, there is no such thing as the right way to do anything. But I still think punishing users who use SPV wallets is a less-than-ideal way to incentive people to run full nodes. Right now SPV is the best way that exists for mobile phones to participate in the network in a decentralized way. This proposal makes the user experience for mobile wallets a little more confusing and annoying. Suppose a billion mobile phones wanted to run SPV wallets tomorrow. Who would provide the nodes they would need connect to? The decentralization fairy? There's absolutely no reason that paying for connectivity would be any more confusing or annoying than transaction fees are. If some full nodes in the network started offering paid connection slots, that would just mean that users who checked the pay subscription fee box in their wallet configuration would have an easier time connecting than the users who did't, just like how your transaction might eventually get mined without a fee but paying one makes it faster and more probable. -- ___ Bitcoin-development mailing list Bitcoin-development@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] questions about bitcoin-XT code fork non-consensus hard-fork
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
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
