His BIP is at https://github.com/luke-jr/bips/blob/bip-sizefp/bip-sizefp.mediawiki He posted a link to it on the bitcoin-dev mailing list.
Matt On March 22, 2017 2:09:13 PM PDT, Manfred Karrer <manfred.kar...@gmail.com> wrote: >Do you have a link to that discussion? > >Am Mittwoch, 22. März 2017 14:49:15 UTC-5 schrieb Matt Corallo: >> >> Luke made a good observation this morning that you can do (somewhat) >> compact fraud proofs of blocks > 1MB because of the structure of >SHA256 >> (you can provide a midstate + the last few bytes of the tx and have a > >> proof of each txn's length). Having a tor-based (or even public, if >it >> must be) service which will provide fraud proofs for blocks as proof >of >> which chain/currency its on is likely very doable (sadly getting >nodes >> to upgrade to support it now is likely difficult). >> >> At a minimum any wallet which is not going to do this should almost >> certainly have a popup warning their users that Bitcoin is likely >> splitting and they are going to be using BTU otherwise users will get > >> completely screwed trying to do localbitcoins and then sell on an >> exchange only to find they received a different coin. >> >> Matt >> >> On 03/22/17 16:18, Andreas Schildbach wrote: >> > Maybe the recommendation should be: if you want to follow a >minority >> > chain, use the Peer API to connect to a trusted peer under your >control. >> > You can then run your desired full node implemention on the trusted >peer >> > and bitcoinj will follow. If the network between bitcoinj and the >> > trusted peer is not to be trusted, use a VPN to secure that >connection >> > (the Bitcoin protocol itself lacks authentication). >> > >> > That would be far more reliable than a version string whitelist. In > >> > fact, frontending bitcoinj with bitcoind has always been a >> > recommendation for centralized/web services, so if they followed >that >> > recommendation they should not have to change anything. >> > >> > >> > On 03/22/2017 03:34 PM, Tobias B. wrote: >> >> Still maybe it adding an API call to go into "whitelist mode" and >then >> >> add certain node ips would be a compromise. Software building on >> >> bitcoinj could then offer the user to go into this mode and add >certain >> >> ips there. >> >> >> >> On Wednesday, March 22, 2017 at 3:25:15 PM UTC+1, Tobias B. wrote: > >> >> >> >> A whitelist of nodes for me sounds highly conflicting with the > >> >> decentralized nature of bitcoin. Also what if nodes switch >their >> >> software? Not that unlikely in case they notice that their >minority >> >> chain is dying. >> >> >> >> On Wednesday, March 22, 2017 at 1:28:09 PM UTC+1, Jameson Lopp > >> wrote: >> >> >> >> >> >> >> >> On Wed, Mar 22, 2017 at 1:55 AM, Manfred Karrer >> >> <manfred...@gmail.com> wrote: >> >> >> >> A Bitcoin core node will not mine a transaction >originated >> >> in a >1 MB block (not sure if it would relay it). >BitcoinJ >> >> has no validation of that consensus rule, so it would >> accept >> >> a tx from a BTU block. I think with a whitelist to >connect >> >> to BTC core nodes only (or better run your local node) >you >> >> should be safe against receiving txs from a BTU block >(> >> >> 1MB or built on top of a >1MB block). If BTC core does >not >> >> check if a tx has inputs from a >1 MB block for >replaying >> >> then we need to take extra care of 0 confirmation txs. > >> >> Does anyone here know if that is the case? >> >> >> >> >> >> If your software ignores all unconfirmed transactions then >I >> >> could see a slightly stronger argument for going the >whitelist >> >> route. My point was that unconfirmed transactions will get > >> >> relayed around the network by nodes on both chain forks. >> >> >> >> >> >> Yes I agree on the protocol level it will be hard as >the >> >> nodes can easily lie. >> >> >> >> Sure wallet providers should not have to deal with it. >But >> I >> >> don't see much alternative. As pure wallet it might be > >> >> easier to tell the people just dont use yoru wallet >for a >> >> few days/week. But for Bitsquare as an exchange that >is not >> >> really an option, trading should not get stopped (and >in >> >> case of Bitsquare cannot really). >> >> >> >> Maybe 2015 people have not been so nervous about it >because >> >> it was before ETH demonstrated the risk and damage of >a >> HF... >> >> >> >> Am Dienstag, 21. März 2017 21:42:07 UTC-5 schrieb >Jameson >> Lopp: >> >> >> >> I don't think replay protection can be added at >the >> >> network level. Peers could lie about their >software >> >> version and/or switch it, plus it's highly likely >that >> a >> >> chain split won't result in a clean network >partition. >> >> Transactions will get relayed around the network >> >> comprised of nodes on both chains and you can >expect >> >> that Core nodes would still relay transactions to >you >> >> that were originally broadcast by Unlimited nodes >and >> >> vice versa. >> >> >> >> At a more philosophical level, I'm not so sure >that the >> >> onus is on every wallet provider to implement >> protection >> >> against contentious hard forks. You could have >made >> >> similar arguments that BitcoinJ should have added >> replay >> >> protection when support for 8MB blocks was nearing >50% >> >> hashrate back in 2015. >> >> >> >> On Tue, Mar 21, 2017 at 8:28 PM, Manfred Karrer >> >> <manfred...@gmail.com> wrote: >> >> >> >> Btw. of course the whitelist can be set by the >user >> >> himself, so if he runs a full node he can use >that. >> >> But knowing that the majority of users are not > >> >> running their own full node we need >alternative >> >> solutions as well. >> >> >> >> >> >> Am Dienstag, 21. März 2017 19:23:56 UTC-5 >schrieb >> >> Manfred Karrer: >> >> >> >> Andreas, how are you planning to protect >users >> >> of the Android wallet agains replay >attacks? >> >> How does a user know if she/he can send >his >> >> wallet coins to a peer who accepts only >BTC or >> >> BTU (e.g. exchange)? Otherwise he might >end up >> >> pretty frustrated to see outgoing >transactions >> >> at this wallet but not confirmation of >receipt >> >> at the receiver. >> >> >> >> You cannot assume that all your users are >> >> blindly following the longest PoW chain as >the >> >> only valid BTC chain and ignore the replay > >> >> attack risks. >> >> There might be even legal issues connected >to >> it >> >> (see ETH HF and losses from replay >attacks), >> >> probably less for a wallet provider than >for a >> >> centralized exchange holding customers >funds. >> >> But I am not sure if that would not fall >back >> to >> >> others as well (due diligence), at least >people >> >> could try to sue... >> >> >> >> One of the easiest solution I see is to >deploy >> a >> >> whitelist of Bitcoin Core nodes and use >those >> >> for the P2P network connections. >> >> You can give the user the choice to select > >> >> between whitelist Bitcoin Core nodes (if >he >> >> wants BTC), whitelist BU nodes (i he wants >BTU) >> >> or public network (if he thinks all plays >out >> by >> >> itself and is aware of the included >risk/mess). >> >> Of course a whitelist is not great as well >but >> >> that would solve the problem that we >cannot >> know >> >> in advance the data which helps us to >> >> distinguish between the chains (like >blockID or >> >> certain transactions). That whitelist only >need >> >> to be used as long the HF is messy, once >things >> >> have settled it can be removed or replaced >by >> >> other distinguishing data sources like >> blockIds. >> >> >> >> If BTU implements a clean mechanism to >make it >> >> easy to distinguish that would be the best > >> >> solution of course but I am not aware of >any >> >> concrete plans for such. >> >> >> >> >> >> Am Mittwoch, 15. März 2017 06:08:55 UTC-5 >> >> schrieb Andreas Schildbach: >> >> >> >> As long as a fork does not change the >proof >> >> of work rules, bitcoinj >> >> makes no assumptions about forks. It >will >> >> always select the chain with >> >> the most work. >> >> >> >> What do you mean by "requesting an >UTXO" >> and >> >> what do you want to achieve >> >> by that? >> >> >> >> >> >> On 03/14/2017 06:07 PM, Manfred Karrer > >> wrote: >> >> > If there would happen really a BU >fork >> SPV >> >> wallets could get a >> >> > connection to a majority of BU nodes >and >> >> so a different view to the network. >> >> > Any plans or ideas how to deal with >that? >> >> > >> >> > One idea would be to use a UTXO >which is >> >> known to exist on only 1 chain >> >> > request that and use that as a check >to >> >> see which chain the node is >> >> > operated on. >> >> > If it is not the chain the wallet >> supports >> >> the node gets disconnected. >> >> > >> >> > Br, >> >> > Manfred >> >> > >> >> > -- >> >> > You received this message because >you are >> >> subscribed to the Google >> >> > Groups "bitcoinj" group. >> >> > To unsubscribe from this group and >stop >> >> receiving emails from it, send >> >> > an email to >> bitcoinj+u...@googlegroups.com >> >> > ><mailto:bitcoinj+u...@googlegroups.com>. >> >> > For more options, visit >> >> https://groups.google.com/d/optout >> >> <https://groups.google.com/d/optout>. >> >> >> >> >> >> -- >> >> You received this message because you are >> subscribed >> >> to the Google Groups "bitcoinj" group. >> >> To unsubscribe from this group and stop >receiving >> >> emails from it, send an email to >> >> bitcoinj+u...@googlegroups.com. >> >> For more options, visit >> >> https://groups.google.com/d/optout >> >> <https://groups.google.com/d/optout>. >> >> >> >> >> >> -- >> >> You received this message because you are subscribed >to the >> >> Google Groups "bitcoinj" group. >> >> To unsubscribe from this group and stop receiving >emails >> >> from it, send an email to >bitcoinj+u...@googlegroups.com. >> >> For more options, visit >https://groups.google.com/d/optout >> >> <https://groups.google.com/d/optout>. >> >> >> >> >> >> -- >> >> You received this message because you are subscribed to the Google > >> >> Groups "bitcoinj" group. >> >> To unsubscribe from this group and stop receiving emails from it, >send >> >> an email to bitcoinj+u...@googlegroups.com <javascript:> >> >> <mailto:bitcoinj+u...@googlegroups.com <javascript:>>. >> >> For more options, visit https://groups.google.com/d/optout. >> > >> > >> > >-- >You received this message because you are subscribed to the Google >Groups "bitcoinj" group. >To unsubscribe from this group and stop receiving emails from it, send >an email to bitcoinj+unsubscr...@googlegroups.com. >For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "bitcoinj" group. To unsubscribe from this group and stop receiving emails from it, send an email to bitcoinj+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
