1 2015-12-25 03:22:57 <jl2012> I'm designing address format for segwit. Do you know any altcoin address design allows variable address length?
  2 2015-12-25 03:24:03 <Luke-Jr> almost as a rule, altcoins are not innovative
  3 2015-12-25 03:27:37 <Luke-Jr> jl2012: potentially useful thread: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2013-May/002588.html
  4 2015-12-25 03:29:31 <jl2012> Thanks. It seems there is an altcoin with addresses starting as BW- , but I forgot its name
  5 2015-12-25 03:41:36 <jl2012> Luke-Jr: you design will have 45 characters for 160bit. A witness program could be as long as 328bit, that will become around 90 characters
  6 2015-12-25 03:43:26 <Luke-Jr> I'm not suggesting using it as-is necessarily
  7 2015-12-25 03:43:38 <jl2012> maybe due to less characters used and stronger checksum
  8 2015-12-25 06:12:03 <maaku> There is absolutely no reason to have an address format for segwit. it destroys one of the primary benefits of the design of segwit. why push this?
  9 2015-12-25 06:21:31 <jcorgan> was kinda wondering about that myself
 10 2015-12-25 06:35:32 <maaku> jcorgan: I posted a longer complaint on the bip draft : https://github.com/bitcoin/bips/pull/267#issuecomment-167200141
 11 2015-12-25 07:42:09 <Luke-Jr> maaku: what? how do p2pkh addresses work fine for segwit?
 12 2015-12-25 07:47:59 <maaku> Luke-Jr: use the p2pkh script as the redeem script
 13 2015-12-25 07:48:49 <Luke-Jr> huh?
 14 2015-12-25 07:50:10 <Luke-Jr> sending to a p2pkh address in any way other than scriptPubKey=<whatever it is now>, is invalid
 15 2015-12-25 07:50:17 <Luke-Jr> might as well be burning bitcoins
 16 2015-12-25 07:50:51 <maaku> Luke-Jr: you are being far too pedantic here
 17 2015-12-25 07:51:00 <Luke-Jr> …
 18 2015-12-25 07:51:25 <Luke-Jr> NOT being pedantic here, BREAKS backward compatibility
 19 2015-12-25 07:51:53 <maaku> new addresses break compatibility too
 20 2015-12-25 07:52:03 <Luke-Jr> new addresses are stupid, I agree with that
 21 2015-12-25 10:21:15 <jl2012> Luke-Jr, unfortunately, most people are still using addresses. Not providing a new address format won't change this fact
 22 2015-12-25 10:25:02 <jl2012> and I don't see how bitcoin could be burnt (unless an attack), as no existing wallet would be able to create any type of scriptPubKey based on the new address
 23 2015-12-25 10:27:11 <jl2012> maaku: I think something like AES is the robust deterministic permutation algorithm you want
 24 2015-12-25 10:27:54 <maaku> jl2012: but now you're back to the giant checksum
 25 2015-12-25 10:28:22 <maaku> oh wait, maybe not. i was thinking abou that wrong...
 26 2015-12-25 10:28:38 <jl2012> <1-byte address version><x-byte checksum><y-byte encrypted payload>
 27 2015-12-25 10:29:07 <jl2012> checksum = hash(address version|payload)
 28 2015-12-25 10:29:29 <jl2012> encrypted payload = AES(payload, checksum)
 29 2015-12-25 10:30:45 <Luke-Jr> jl2012: why not encode a payment request instead?
 30 2015-12-25 10:31:32 <jl2012> Luke-Jr: payment request includes scriptPubKey, isn't it?
 31 2015-12-25 10:32:02 <Luke-Jr> yes, includes
 32 2015-12-25 10:32:24 <jl2012> so it goes back to the question of how to safely encode a scriptPubKey
 33 2015-12-25 10:32:45 <maaku> jl2012: the counter-argument to your BIP is that werever you were imagining using this new address type, you should just be using a serialized payment request instead
 34 2015-12-25 10:33:20 <maaku> jl2012: the payment request just serializes it as a byte string
 35 2015-12-25 10:36:26 <jl2012> maaku: none of the services I used support BIP70, so they can't even generate a payment request
 36 2015-12-25 10:36:53 <maaku> jl2012: they will have to be updated to use your new address format. why not have them support bip 70 instead?
 37 2015-12-25 10:37:06 <btcdrak> ^
 38 2015-12-25 10:39:19 <Luke-Jr> ^^
 39 2015-12-25 10:39:53 <jl2012> what is the shortest possible length for a serialized payment request, encoded in base64, for a scriptPubKey of 34 bytes?
 40 2015-12-25 10:40:46 <jl2012> to make it useful like an address, it must be copy-and-paste-able
 41 2015-12-25 10:41:13 <Luke-Jr> copy-and-paste works with any length :D
 42 2015-12-25 10:41:49 <jl2012> ok, but no checksum?
 43 2015-12-25 10:42:39 <Luke-Jr> your ASCII encoding can add that
 44 2015-12-25 10:43:02 <Luke-Jr> payment requests require only their creation time and output script
 45 2015-12-25 10:43:12 <jl2012> Luke-Jr: that becomes a new address format, again
 46 2015-12-25 10:43:13 <Luke-Jr> I don't know how much overhead protobuf adds, but probably about 10 bytes
 47 2015-12-25 10:43:36 <Luke-Jr> jl2012: fine, so it's a new address format, but at least it's BIP70-based
 48 2015-12-25 10:44:24 <Luke-Jr> bonus feature: people with SSL certs can sign their new addresses
 49 2015-12-25 10:46:36 <jl2012> Luke-Jr: I don't think BIP70 is designed to be used as C&P. And with signing, that means the "address" will be extremely long
 50 2015-12-25 10:47:40 <jl2012> Actually I don't think it is really an "address". It's a block of data
 51 2015-12-25 10:49:16 <Luke-Jr> "with signing" what?
 52 2015-12-25 10:49:42 <jl2012> " people with SSL certs can sign their new addresses"
 53 2015-12-25 10:51:23 <jl2012> that means the user has to C&P the signature too?
 54 2015-12-25 10:53:58 <Luke-Jr> no
 55 2015-12-25 10:54:06 <Luke-Jr> it would be included in the address
 56 2015-12-25 10:54:52 <jl2012> and the "address" will be very long as it contains a signature
 57 2015-12-25 10:54:59 <Luke-Jr> perhaps
 58 2015-12-25 10:55:08 <jl2012> like a block of PGP data
 59 2015-12-25 10:55:15 <jl2012> that's not address
 60 2015-12-25 10:57:43 <Luke-Jr> perhaps it won't get used
 61 2015-12-25 10:58:53 <jl2012> and in merchant's standpoint, upgrade to a new address is easier than upgrade to BIP70
 62 2015-12-25 10:59:14 <jl2012> a new address format won't change their existing UI, at least
 63 2015-12-25 11:00:45 <Luke-Jr> …
 64 2015-12-25 11:01:04 <Luke-Jr> neither would BIP 70 in this use
 65 2015-12-25 11:01:44 <jl2012> BIP70 without checksum or signature is more insecure than address
 66 2015-12-25 11:02:52 <Luke-Jr> [10:42:39] <Luke-Jr> your ASCII encoding can add that
 67 2015-12-25 11:03:12 <jl2012> 18:43 <jl2012> Luke-Jr: that becomes a new address format, again
 68 2015-12-25 12:45:34 <jl2012> maaku: does Damm error correction work with Base58?
 69 2015-12-25 12:47:00 <jl2012> need a quasigroup of order 58?
 70 2015-12-25 12:51:59 <jl2012> I prefer 58 than 32, as the security is better with the same number of charaters
 71 2015-12-25 12:53:37 <Luke-Jr> jl2012: 58 is a pain to implement
 72 2015-12-25 13:08:09 <jl2012> http://www.sciencedirect.com/science/article/pii/S0012365X06004225
 73 2015-12-25 17:43:14 <maaku> jl2012: sure but why would you want to? base58 is an absolute mess
 74 2015-12-25 17:44:57 <jl2012> to keep the length below 80
 75 2015-12-25 17:47:25 <maaku> then base64, but base64 is severly lacking in accessibility
 76 2015-12-25 17:47:42 <maaku> you've got mutually exclusive requirements here, which is the issue
 77 2015-12-25 17:49:10 <maaku> if you want people reading off addresses, speaking them over the phone, copying them down, or typing them, do not use base58, base64, or anything that requires case sensitivity or extra symbols. that's the argument for base32
 78 2015-12-25 17:49:47 <maaku> (and between base58 and base64, there are very strong technical reasons to prefer base64)
 79 2015-12-25 18:12:53 <jl2012> maybe just forget my BIP first. A simple modification could be made for existing P2PKH address, by replacing the address version byte 0x00 with 0x19. The resulting address will look completely different, starting with "B", and has constant length of 34
 80 2015-12-25 18:13:47 <jl2012> An address of this type indicates a P2PKH in a native v0 witness program
 81 2015-12-25 18:14:32 <jl2012> Since P2PKH is still >90% of the tx volume, this should solve most problem
 82 2015-12-25 18:15:02 <jl2012> minimal change, not better nor worse than existing address
 83 2015-12-25 18:28:36 <jl2012> for more complicated things, we may need a different scheme. Has anyone proposed a QR code BIP?
 84 2015-12-25 18:57:04 <phantomcircuit> jl2012, i was actually thinking that we might want to change bitcoin core to produce p2sh addresses by default
 85 2015-12-25 18:57:52 <jl2012> the future is segwit, no reason to further promote p2sh
 86 2015-12-25 19:09:57 <genac> sup
 87 2015-12-25 19:11:43 <Diablo-D3> Ive never heard of segwit, so, surely, it can't be the future
 88 2015-12-25 19:30:34 <phantomcircuit> jl2012, sw is basically the same construct as p2sh actually
 89 2015-12-25 19:31:00 <phantomcircuit> the original p2sh proposal probably should have been sw but we didn't have any experience with the concept at the time
 90 2015-12-25 19:31:24 <phantomcircuit> almost certainly the only reason anybody can even propose such a change now is because of elements alpha
 91 2015-12-25 21:34:41 <CodeShark> sw is p2sh (except that the scriptSig is committed separately and is ignored for the purposes of txid)
 92 2015-12-25 21:38:22 <CodeShark> we don't need to support p2pkh in segwit - we can still support sending to p2pkh addresses, but there's no reason to try to migrate existing p2pkh addresses to segwit
 93 2015-12-25 21:39:18 <CodeShark> we can't change earlier blocks so there's nothing to be gained
 94 2015-12-25 21:42:21 <CodeShark> if people want to migrate to segwit, let them generate new keys :)
 95 2015-12-25 21:53:29 <CodeShark> bitcoin core's wallet can continue to support internal p2pkh addresses as legacy - but their use should be strongly discouraged and only allowed for the sake of making it easy for people to migrate their existing funds
 96 2015-12-25 21:55:22 <CodeShark> and ultimately phased out entirely
 97 2015-12-25 21:55:47 <CodeShark> eventually perhaps another soft fork can make everything use sw
 98 2015-12-25 21:55:58 <CodeShark> way later on down the line, once deployment is complete
 99 2015-12-25 21:56:42 <CodeShark> or perhaps not ;)
100 2015-12-25 21:58:17 <CodeShark> I retract my last statement regarding elimination of p2pkh support at the consensus layer - only at the wallet layer
101 2015-12-25 21:59:18 <CodeShark> economic forces should suffice - no need to prohibit people from using p2pkh
102 2015-12-25 22:09:44 <phantomcircuit> CodeShark, the core wallet needs a huge amount of attention
103 2015-12-25 22:10:04 <phantomcircuit> there's a bunch of components in it which nobody else has even come close to matching
104 2015-12-25 22:10:18 <CodeShark> I personally think it should be broken off into a separate project ;)
105 2015-12-25 22:10:23 <phantomcircuit> but there's also stuff that's really annoying (such as using bdb)
106 2015-12-25 22:11:14 <CodeShark> which components, phantomcircuit?
107 2015-12-25 22:11:48 <phantomcircuit> CodeShark, coin selection for one
108 2015-12-25 22:11:58 <phantomcircuit> although thinking about it i haven't looked at how you did that
109 2015-12-25 22:12:01 <CodeShark> I've been supporting that for like over a year ;)
110 2015-12-25 22:12:58 <CodeShark> you mean manual coin selection? or the knapsack problem thing?
111 2015-12-25 22:13:08 <CodeShark> the latter I admittedly have not attempted to optimize too much
112 2015-12-25 22:13:27 <phantomcircuit> i mean the knapsack solver
113 2015-12-25 22:13:38 <CodeShark> ah, right
114 2015-12-25 22:14:01 <phantomcircuit> it's not really fast in core but it's fast enough and comes up with a good enough solution
115 2015-12-25 22:14:34 <CodeShark> yeah, it would be easy to lift the algo
116 2015-12-25 22:15:28 <CodeShark> I might just do that ;)
117 2015-12-25 22:17:31 <CodeShark> jonathan hope gave a presentation on this in hong kong and apparently is working on some libraries (threekey.solutions)
118 2015-12-25 22:33:48 <CodeShark> it's also related to the problems of defragmentation and change minimization
119 2015-12-25 22:34:29 <CodeShark> coin selection is not always sufficient - sometimes you need to create denominated outputs up front
120 2015-12-25 22:36:24 <CodeShark> I agree, phantomcircuit - these problems haven't received enough attention
121 2015-12-25 22:43:08 <jcorgan> and fees always mess it up anyway
122 2015-12-25 22:44:26 <CodeShark> yes, then we get into replacement schemes
123 2015-12-25 22:45:05 <CodeShark> i.e. batching sends...or replacing mempool transactions with new ones that combine more inputs and outputs
124 2015-12-25 22:45:34 <CodeShark> RBF, etc..
125 2015-12-25 22:50:00 <CodeShark> payment channels might alleviate much of the complexity since presumably channels will tend to be created at certain denominations and defragmentation need only occur after channel closes
126 2015-12-25 22:51:07 <CodeShark> or at least, the usability isn't severely impacted
127 2015-12-25 22:56:51 <CodeShark> and they certainly help with the fee stuff since exit/close transactions have essentially a predetermined size
128 2015-12-25 23:00:02 <CodeShark> and the fee can be arbitrarily set to anything...to be paid by either party
129 2015-12-25 23:07:29 <CodeShark> it's still a little tricky how to allow either party to add more fees without requiring the other's signature
130 2015-12-25 23:08:09 <CodeShark> would be a very useful mechanism to have
131 2015-12-25 23:17:41 <CodeShark> SIGHASH_ANYONECANPAY is probably suboptimal in several respects
132 2015-12-25 23:19:00 <CodeShark> not probably - IS