Re: [bitcoin-dev] BIP Proposal: Compact Client Side Filtering for Light Clients
Most SPV wallets make it quite clear that unconfirmed transactions are just that. On 06/19/2017 06:36 PM, adiabat via bitcoin-dev wrote: > This has been brought up several times in the past, and I agree with > Jonas' comments about users being unaware of the privacy losses due to > BIP37. One thing also mentioned before but not int he current thread > is that the entire concept of SPV is not applicable to unconfirmed > transactions. SPV uses the fact that miners have committed to a > transaction with work to give the user an assurance that the > transaction is valid; if the transaction were invalid, it would be > costly for the miner to include it in a block with valid work. > > Transactions in the mempool have no such assurance, and are costlessly > forgeable by anyone, including your ISP. I wasn't involved in any > debate over BIP37 when it was being written up, so I don't know how > mempool filtering got in, but it never made any sense to me. The fact > that lots of lite clients are using this is a problem as it gives > false assurance to users that there is a valid but yet-to-be-confirmed > transaction sending them money. > > -Tadge > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] An alternative way to protect the network from 51% attacks threat
Here is the text of a post to reddit from Feb 2017, discussing a similar idea, and wondering if it could reduce the incentive to delay broadcast of solved blocks: # How an anchored Proof of Stake Sidechain can help the Bitcoin main chain # Steps: 1. Soft fork Bitcoin to enable side chains 2. Create a side chain that is secured with Proof of Stake. Call blocks on this chain "POS-blocks." The original chain is made of "POW-blocks." 3. Side chain mints one POS-block after each POW-block on the main chain, and contains the hash of the POW-block, and the hash of the previous POS-block. See diagram [here.](https://s32.postimg.org/916n9zxlx/Pos_Sf1.png ) 4. Side chain Minters must make a deposit in order to mint. If they mint an invalid POS-block, they lose the deposit. 5. Side chain blocks are small enough to broadcast and validate quickly (e.g. 100 - 300 KB). 6. Soft fork a new rule into Bitcoin that encourages POW-blocks to include the hash of the prior POS-block. Specifically, penalize POW-blocks which do not point to the prior POS-block by doubling the difficulty necessary for them to be valid. Call POW-blocks which do not point to the prior POS-block but are valid because of their very high POW "hard blocks." In the following diagram POW2 and POW4 are valid because they point to the prior POS-block and also satisfy the difficulty requirement. POW3 does not point to the prior POS-bock, but is valid anyway because it contains proof of work at twice the normal difficulty. https://s27.postimg.org/6hc0b8ejn/Pos_Sf2.png # Advantages: 1. Allow people who do not control ASICs to influence which transactions happen. 2. Allow people who do not control ASICs to influence which chain gets extended. 3. Reduce the incentive to selfish mine. Once a miner discovers a block, they should broadcast it immediately in the hopes that a Minter will build on it, because that is the most likely way their block will not go stale. Miners will also immediately start trying to build a hard block. (Maybe statistics could tell us what is the proper range for the Hardness Multiplier. I guessed 2 would be good.) 4. Reduces the effective block interval while reducing the incidence of stale blocks, empty blocks and SPV mining. After a POW-block is mined, it is immediately broadcast to the network, seeking a qualified Minter to extend it. Minters have a deposit, which they will lose if they mint an invalid block. Pointing to the hash of an invalid POW-block would produce an invalid minted block, so Minters have a strong incentive to completely validate the POW-block before they mint on top of it. After validating, they mint a block and broadcast it. While the Minter is validating the previous POW-block, competing miners also have time to fully validate the previous POW-block. By the time the Miners receive the POS-block, they know what transactions they can and cannot include in their own block, because the Minter only processes transactions on the side chain. There is less reason to mine empty blocks, because there is adequate time to update the mempool before mining the next soft block begins, and because hard blocks take a long time to produce. The risks involved with mining on an un-validated POS-block can be made small by the fact that there is a deposit that will be destroyed if the POS-block is invalid. POS-blocks can be validated quickly because they are small. Here is a gantt chart of the schedule described above: https://s22.postimg.org/hvnkyac5d/Pos_Sf3.png 5. Unlike a pure POS system, a cabal of early Stake holders cannot cheaply hatch an alternate history. Much less imperative for nodes to go to a trusted peer and ask whether the chain they are being fed is legitimate. 6. After step 6 above, the side chain would have essentially the same security characteristics as the main chain, and could be used interchangeably. 7. No hard fork required, and this soft fork could be deployed even if the miners do not consent to it. Some hybrid POS system would be my recommendation as preferable to simply changing POW algorithms in the face of miners abusing their power. 8. Users can opt into the POS sidechain, and it can fully prove itself in production before there is any attempt to anchor the main chain back to it. Even if consensus cannot be obtained to execute step 6, the mere existence of such a chain could deter tomfoolery on the part of POW miners, lest they galvanize the community into throwing the switch. Original reddit post here: https://www.reddit.com/r/Bitcoin/comments/5vy4qc/how_an_anchored_proof_of_stake_sidechain_can_help/ ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP148 temporary service bit (1 << 27)
It is essential that BIP-148 nodes connect to at least two other BIP-148 nodes to prevent a network partition in August 1st. The temporary service but is how such nodes are able to detect each other. > On Jun 19, 2017, at 12:46 PM, Tom Zander via bitcoin-dev >wrote: > >> On Monday, 19 June 2017 21:26:22 CEST Luke Dashjr via bitcoin-dev wrote: >> To ease the transition to BIP148 and to minimise risks in the event miners >> choose to perform a chain split attack, at least Bitcoin Knots will be >> using the temporary service bit (1 << 27) to indicate BIP148 support. >> >> Once the transition is complete, this will no longer be necessary, and the >> bit will be (manually) returned for reuse. >> >> I encourage other software implementing BIP148 (both full and light nodes) >> to set and use this service bit to avoid network partitioning risks. > > I'm curious what you action on the finding (or not) of a peer with this bit > set (or not). > Can you link to the github commit where you implemented this? > -- > Tom Zander > Blog: https://zander.github.io > Vlog: https://vimeo.com/channels/tomscryptochannel > ___ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP148 temporary service bit (1 << 27)
On Monday, 19 June 2017 21:26:22 CEST Luke Dashjr via bitcoin-dev wrote: > To ease the transition to BIP148 and to minimise risks in the event miners > choose to perform a chain split attack, at least Bitcoin Knots will be > using the temporary service bit (1 << 27) to indicate BIP148 support. > > Once the transition is complete, this will no longer be necessary, and the > bit will be (manually) returned for reuse. > > I encourage other software implementing BIP148 (both full and light nodes) > to set and use this service bit to avoid network partitioning risks. I'm curious what you action on the finding (or not) of a peer with this bit set (or not). Can you link to the github commit where you implemented this? -- Tom Zander Blog: https://zander.github.io Vlog: https://vimeo.com/channels/tomscryptochannel ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] BIP148 temporary service bit (1 << 27)
To ease the transition to BIP148 and to minimise risks in the event miners choose to perform a chain split attack, at least Bitcoin Knots will be using the temporary service bit (1 << 27) to indicate BIP148 support. Once the transition is complete, this will no longer be necessary, and the bit will be (manually) returned for reuse. I encourage other software implementing BIP148 (both full and light nodes) to set and use this service bit to avoid network partitioning risks. Luke ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] An alternative way to protect the network from 51% attacks threat
On Tue, Jun 20, 2017 at 02:01:45AM +0800, Wang Chun via bitcoin-dev wrote: > There has been proposal to change the PoW in case of potential 51% attacks > from malicious miners during a fork. But such a change in PoW renders > multi-billion-dollar of ASIC into worthless. which hurts economy so much > and the average innocent mining users. I would propose, instead of PoW > change, we could change the system to the same double sha256 PoW but mix it > with PoS features. Such a PoW+PoS system has several advantages: You have to specify what you mean by "PoS" - there's dozens of variations. Equally, existing pure PoS schemes probably don't make sense as a "bolt-on" add-on, as once you introduce PoW to it you should design something that uses the capabilities of both systems. FWIW, I've heard that the Ethereum guys are leaning towards abandoning pure PoS and are now trying to design a PoW + staking system instead. > * It protects existing multi-billion dollar investments from innocent > mining users, To be clear, you mean such a scheme would protect the multi-billion dollar investments non-malicious miners have made in SHA256^2 hardware by ensuring it remains useful, right? > * A malicious miner cannot launch attacks and rewrite the blockchain with > 51% or even more hashrate, > * If we insert 4 PoS blocks between 2 PoW blocks, we'll have 2-minute block > time span, that solves the long confirmation time problem, Note that if those PoS blocks are *pure* PoS, you'll create a significant risk of double-spend attacks, as there's zero inherent cost to creating a pure-PoS block. Such blocks can't be relied on for confirmations; even "slasher" schemes have significant problems with sybil attacks. > * We'll suddenly have 5 times of block space, that solves the scaling > problem, The scaling problem is one of scalability; PoS does nothing to improve scalability (though many in the ETH community have been making dishonest statements to the contrary). > * The PoS blocks only mine transaction fees, so the 21M cap remains, > * With careful design, the PoW+PoS transition _might_ be able to deploy > with a soft fork. As a sidechain yes, but in what you propose above the extra blocks wouldn't contain transactions that non-PoS-aware nodes could understand in a backwards-compatible way. All the above aside, I don't think it's inherently wrong to look at adding PoS block *approval* mechanisms, where a block isn't considered valid without some kind of coin owner approval. While pure-PoS is fundamentally broken in a decentralized setting, it may be possible to mitigate the reasons it's broken with PoW and get a system that has a stronger security model than PoW alone. FWIW there's some early discussions by myself and others about this type of approach on the #bitcoin-wizards IRC channels, IIRC from around 2014 or so. -- https://petertodd.org 'peter'[:-1]@petertodd.org signature.asc Description: Digital signature ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] An alternative way to protect the network from 51% attacks threat
There has been proposal to change the PoW in case of potential 51% attacks from malicious miners during a fork. But such a change in PoW renders multi-billion-dollar of ASIC into worthless. which hurts economy so much and the average innocent mining users. I would propose, instead of PoW change, we could change the system to the same double sha256 PoW but mix it with PoS features. Such a PoW+PoS system has several advantages: * It protects existing multi-billion dollar investments from innocent mining users, * A malicious miner cannot launch attacks and rewrite the blockchain with 51% or even more hashrate, * If we insert 4 PoS blocks between 2 PoW blocks, we'll have 2-minute block time span, that solves the long confirmation time problem, * We'll suddenly have 5 times of block space, that solves the scaling problem, * The PoS blocks only mine transaction fees, so the 21M cap remains, * With careful design, the PoW+PoS transition _might_ be able to deploy with a soft fork. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP Proposal: Compact Client Side Filtering for Light Clients
On Monday, 19 June 2017 18:30:18 CEST Jonas Schnelli wrote: > I personally would ALWAYS [snip] I mentioned that it was a usability point for a reason, and your personal behavior makes me want to quote one of the main UX guidelines; “You are not your user” http://uxmyths.com/post/715988395/myth-you-are-like-your-users older; http://52weeksofux.com/post/385981879/you-are-not-your-user I think we should defer to actual real numbers and user reseach, as has been quoted by Andreas. You disagreeing based on your own experience and behavior is worse than useless. As the above links show. Don’t fall in that trap :) -- Tom Zander Blog: https://zander.github.io Vlog: https://vimeo.com/channels/tomscryptochannel ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP Proposal: Compact Client Side Filtering for Light Clients
This has been brought up several times in the past, and I agree with Jonas' comments about users being unaware of the privacy losses due to BIP37. One thing also mentioned before but not int he current thread is that the entire concept of SPV is not applicable to unconfirmed transactions. SPV uses the fact that miners have committed to a transaction with work to give the user an assurance that the transaction is valid; if the transaction were invalid, it would be costly for the miner to include it in a block with valid work. Transactions in the mempool have no such assurance, and are costlessly forgeable by anyone, including your ISP. I wasn't involved in any debate over BIP37 when it was being written up, so I don't know how mempool filtering got in, but it never made any sense to me. The fact that lots of lite clients are using this is a problem as it gives false assurance to users that there is a valid but yet-to-be-confirmed transaction sending them money. -Tadge ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP Proposal: Compact Client Side Filtering for Light Clients
>> >> I think many users would be willing ... >> a) … to trade higher privacy (using client side filtering) for not having >> the „incoming transaction“ feature b) – if they want 0-conf – to fetch >> all inved transactions > > You seem to misunderstand the usecase. > If you send me a transaction, both of use are using our phones, then I need > to be able to have immediate feedback on the transaction being broadcast on > the network. > This is not about zero-conf, this is simple seeing what is happening while > it is happening. > > Additionally, when the transaction that is meant for my wallet is broadcast, > I want my SPV wallet to parse and check the actual transaction. > It is not just to see that *something* was actually send, but also to be > able to see how much is being paid to me. Maybe If the transaction is marked > as RBF-able, etc. > > Really basic usability: provide information to your users when you can, > should they want to, and by default on. I see this use case. But I did receive bank wire transfers for the last decades without _immediately_ knowing that someone sent funds to me. I personally would ALWAYS trade the higher bandwidth consumption (300MB mempool filtering) or slower notification time (maybe ~1h) for preserving privacy. I agree, there are use cases where you want immediate notification, those use cases could probably be solved by not trowing away privacy („parsing“ all transactions and running in the background). /jonas signature.asc Description: Message signed with OpenPGP ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP Proposal: Compact Client Side Filtering for Light Clients
> > On the other hand, I remember only 1 (one) inquiry about the privacy > problems of BIP37 (or privacy at all). IMO privacy its something developers should make sure users have it. Also, I think, todays SPV wallets should make users more aware of the possible privacy implications. Do users know, if they pay for a good in a shop while consuming the shops WIFI, that the shop-owner as well as the ISP can use that data to combine it with the user profile (and ~ALL FUTURE purchases you do with the same wallet IN ANY LOCATION online or in-person)? Do users know, that ISPs (cellular; including Google) can completely link the used Bitcoin wallet (again: all purchase including future ones) with the to the ISP well known user profile including credit-card data and may sell the Bitcoin data to any other data mining company? If you use BIP37, you basically give your transaction history (_ALL TRANSACTIONS_ including transactions in future) to everyone. > > From a regular user's point of view, privacy is non-issue. Sure, > everyone would take it for free, but certainly not if it a) delays > incoming payments or b) quickly eats up your traffic quota. This may be true because they are not aware of the ramification and I don’t think client side filtering is a drop-in replacement for todays, smartphone SPV-model. /jonas signature.asc Description: Message signed with OpenPGP ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP Proposal: Compact Client Side Filtering for Light Clients
On Monday, 19 June 2017 17:49:59 CEST Jonas Schnelli wrote: > Hi > > > On Monday, 19 June 2017 14:26:46 CEST bfd--- via bitcoin-dev wrote: > >> It's been debated if [filtering of] unconfirmed transactions are > >> necessary, > > > > Why would it not be needed? Any SPV client (when used as a > > payment-receiver) requires this from a simple usability point of view. > > I think many users would be willing ... > a) … to trade higher privacy (using client side filtering) for not having > the „incoming transaction“ feature b) – if they want 0-conf – to fetch > all inved transactions You seem to misunderstand the usecase. If you send me a transaction, both of use are using our phones, then I need to be able to have immediate feedback on the transaction being broadcast on the network. This is not about zero-conf, this is simple seeing what is happening while it is happening. Additionally, when the transaction that is meant for my wallet is broadcast, I want my SPV wallet to parse and check the actual transaction. It is not just to see that *something* was actually send, but also to be able to see how much is being paid to me. Maybe If the transaction is marked as RBF-able, etc. Really basic usability: provide information to your users when you can, should they want to, and by default on. -- Tom Zander Blog: https://zander.github.io Vlog: https://vimeo.com/channels/tomscryptochannel ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP Proposal: Compact Client Side Filtering for Light Clients
> Just to give you a number: based on the statistics of the Bitcoin Wallet > app there are at least 2 million wallets depending on BIP37. Not all > would need instant notification but based on the daily support enquiries > instant notificaton is the most asked property of Bitcoin. Yes. Users probably like this feature and client side filtering is not a drop-in replacement for BIP37. We should also consider: BIP37 works, because node-operators are willing to offer that service for free (which maybe change over time). BIP37 consumes plenty of horsepower (disk/cpu) from nodes. Filtering a couple of days of blocks (assume 1000+) eats lots of resources for something, that has no direct long-term value for Bitcoin (the filters data is unique and will be "thrown away“ [can’t be used by other peers]). Same applies for mempool (filtering mempool of a couple of hundred of mb each time the HD gap limit has been exceeded or the app gets sent to the foreground again). Purely relying on the availability of BIP37 seems fragile to me and start to explore other ways is very reasonable. /jonas signature.asc Description: Message signed with OpenPGP ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Drivechain RfD -- Follow Up
Hi Greg, Responses below: On 6/18/2017 5:30 PM, Tao Effect wrote: > In Drivechain, 51% of miners have total control and ownership over all > of the sidechain coins. It would not be accurate to say that miners have "total" control. Miners do control the destination of withdrawals, but they do not control the withdrawal-duration nor the withdrawal-frequency. So, if miners wish to 'steal' from a sidechain, they _can_ initiate a theft, but they can not change the fact that their malfeasance will be [a] obvious, and [b] on display for a long period of time. We might draw a comparison between: 1. Classic Theft -- A majority hashrate reorganizes the main Bitcoin chain to double-spend funds (or coordinate with someone who is double-spending). This is prevented/discouraged by waiting for many confirmations. 2. Channel Theft -- A majority hashrate assists a Lightning-Network thief, by censoring the punitive audit txn (possibly by exploiting some excuse regarding fullness of blocks, or possibly induced to do so by the thief provably splitting the proceeds with miners). This is prevented/discouraged by using lengthy custodial periods, paying high fees with your attacker's money, and using fungibility/non-communication to interact with miners as little as possible (so as to frame LN-theft as undermining the entire LN system, and not merely a single tragedy). 3. Drivechain Theft -- A majority hashrate initiates an unrepresentative withdrawal from some sidechain. This is prevented/discouraged by only using 'popular' sidechains (those that [a] increase the usefulness ("market price") of bitcoin, and [b] generate tx fees for miners). It is also discouraged by the fact that egregious theft would probably end the sidechain experiment, meaning that all present and future sidechains would be forever unavailable (and unable to buoy the price or the tx revenues). I do not think that any of the three stands out as being categorically worse than the others, especially when we consider the heterogeneity of use-cases and preferences. As Luke-Jr has been pointing out on social media recently, the very group which is more associated with miners (and explicitly more willing to trust them, ie Bitcoin Unlimited et al), happens to be the same group that would be expected to make use of a LargeBlock drivechain. Some can argue that one type of security is more "cryptographic" than others, but I think this is misguided (how many 'bits' of security does each have?) -- imho, all three security models are 'game theoretic' (neither computer scientific, nor cryptographic). More importantly, before a miner has any "control" over the sidechain coins, users must voluntarily agree to subject themselves to these new rules. This is similar to how an arbitrary piece of (open source) software can have "total" control over your computer...if you choose to install it. > Thus the effect of Drivechain appears to be the creation of a new kind > of digital border imposed onto the network ... I'm not sure it would "create a border", given that sidechains are currently not accessible at all. If anything drivechain cuts a door into an existing impassible border. > ... where everyone hands over ownership of their Bitcoins to a > /single/ mining cartel when they wish to interact with /any/ sidechain. The qualifier "/any/ sidechain" would seem to imply that there is a way to do sidechains that does not involve handing over some control to 51% hashrate...I think this is false (even in the fabled case of ZK-SNARKS). The first thing I do in the drivechain spec ( truthcoin.info/blog/drivechain ) is explain why. > Drivechain would be a reasonable idea if that weren't the case, but > since it is, Drivechain now introduces a very real possible future > where Bitcoins can be confiscated by the Chinese government in exactly > the same manner that the Chinese government today confiscates > financial assets in other financial networks within China. Yes, but money could also be confiscated from _any_ Bitcoin users (Chinese or otherwise) using any of the three methods I mentioned above. And confiscation could strike Chinese Bitcoin users if they decided to sell their Bitcoin for Chinese Yuan, which they then deposited in a Chinese bank. Or if they sold their Bitcoin for an Altcoin controlled by the Chinese govt in some other way. It is not up to the members of this list to decide, USSR style, what other people are allowed to do with their own money. The exceptions to this rule would be (ie, "bitcoin-dev should care about what users are doing when..."): 1. [Unreasonable use of Reviewer Time] The user's use-case is either nonexistent (ie "no one wants that"), or totally unachievable ("we can't do that") thus rendering the conversation a complete waste of time / reviewer attention. 2. [Harmful Interference] The user's use-case would impose harm on some existing use-case(s). No reasonable person will claim the first, given today's scaling debate (not to
Re: [bitcoin-dev] BIP Proposal: Compact Client Side Filtering for Light Clients
On 06/19/2017 05:49 PM, Jonas Schnelli via bitcoin-dev wrote: >>> It's been debated if [filtering of] unconfirmed transactions are >>> necessary, >> >> Why would it not be needed? Any SPV client (when used as a payment-receiver) >> requires this from a simple usability point of view. > > > I think many users would be willing ... > a) … to trade higher privacy (using client side filtering) for not having the > „incoming transaction“ feature > b) – if they want 0-conf – to fetch all inved transactions Another number: I'm answering dozens of support inquiries about delayed/missing transactions per day. Over the 7 years of Bitcoin Wallet's existence, I estimate about 5 inquiries. On the other hand, I remember only 1 (one) inquiry about the privacy problems of BIP37 (or privacy at all). From a regular user's point of view, privacy is non-issue. Sure, everyone would take it for free, but certainly not if it a) delays incoming payments or b) quickly eats up your traffic quota. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP Proposal: Compact Client Side Filtering for Light Clients
Hi > On Monday, 19 June 2017 14:26:46 CEST bfd--- via bitcoin-dev wrote: >> It's been debated if [filtering of] unconfirmed transactions are >> necessary, > > Why would it not be needed? Any SPV client (when used as a payment-receiver) > requires this from a simple usability point of view. I think many users would be willing ... a) … to trade higher privacy (using client side filtering) for not having the „incoming transaction“ feature b) – if they want 0-conf – to fetch all inved transactions /jonas signature.asc Description: Message signed with OpenPGP ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Drivechain -- Request for Discussion
> > Since the sidechain has the sidechain BMM headers that they want the LD > (bribe) data for, I think that they could specifically request LD data > relevant only to that sidechain by providing a list of hashes to the > mainchain, and the mainchain can return a list of boolean values telling > the sidechain if the LD data exists. That way the data never even has to > go over the network, just a verification that it exists on the mainchain > and > Since you seem to be talking about the initial block download process for the drivechain. It seems that we might as well request the set of *valid* blocks from a bitcoin peer first, since at the end of the day they are in control of the mining process on the sidechain. Here is what I envision: 1. Request all hashes for sidechain from a bitcoin peer 2. Request all sidechain block header's for the hashes the bitcoin peer gave us 3. Order the set of sidechain block headers by looking at hashPrevBlock. 4. Request full sidechain blocks and start validating against the consensus rule set of the sidechain we can drop the sidechain_id from the script. I agree the 'sidechain_id' is unneeded in the coinbase tx output. We should just fix these based on index. This should be reflected in my latest commit if we are talking about the same thing: https://github.com/Christewart/bitcoin/blob/c355e39fbe2ea48856ea86b25cb8a97710feb032/src/script/script.cpp#L254 and have the sidechain handle filtering out invalid LD data / > only requesting the verification of LD data that they know to be valid > as far as chain order goes. > I agree, the whole point of BMM is to have bitcoin miners indifferent to what happens in the sidechain (although Paul argues in a wonky way they do care sort of). If there is an invalid (in the sense the block it represents does *not* follow the sidechain's consensus rule set) OP_BRIBEVERIFY that pays *more* money than a valid OP_BRIBEVERIFY output, we need to assume that a 'blind' bitcoin miner will choose the one that pays them the most money. >I might be wrong but I thought that OP_RETURN outputs do not go into the UTXO set. Anyone else want to chime in? I'm fairly certain you are right. It just feels like we should be able to exploit the fact that *only* miners can claim these OP_BRIBEVERIFY outputs. I'll have to think about this more, maybe some one else can come up with something clever that exploits that fact. On Mon, Jun 19, 2017 at 10:24 AM, Chris Stewartwrote: > Since the sidechain has the sidechain BMM headers that they want the LD >> (bribe) data for, I think that they could specifically request LD data >> relevant only to that sidechain by providing a list of hashes to the >> mainchain, and the mainchain can return a list of boolean values telling >> the sidechain if the LD data exists. That way the data never even has to >> go over the network, just a verification that it exists on the mainchain >> and >> > > Since you seem to be talking about the initial block download process for > the drivechain. It seems that we might as well request the set of *valid* > blocks from a bitcoin peer first, since at the end of the day they are in > control of the mining process on the sidechain. Here is what I envision: > >1. Request all hashes for sidechain from a bitcoin peer >2. Request all sidechain block header's for the hashes the bitcoin >peer gave us >3. Order the set of sidechain block headers by looking at >hashPrevBlock. >4. Request full sidechain blocks and start validating against the >consensus rule set of the sidechain > > > we can drop the sidechain_id from the script. > > I agree the 'sidechain_id' is unneeded in the coinbase tx output. We > should just fix these based on index. This should be reflected in my latest > commit if we are talking about the same thing: https://github.com/ > Christewart/bitcoin/blob/c355e39fbe2ea48856ea86b25cb8a9 > 7710feb032/src/script/script.cpp#L254 > > > and have the sidechain handle filtering out invalid LD data / >> only requesting the verification of LD data that they know to be valid >> as far as chain order goes. >> > > I agree, the whole point of BMM is to have bitcoin miners indifferent to > what happens in the sidechain (although Paul argues in a wonky way they do > care sort of). If there is an invalid (in the sense the block it represents > does *not* follow the sidechain's consensus rule set) OP_BRIBEVERIFY that > pays *more* money than a valid OP_BRIBEVERIFY output, we need to assume > that a 'blind' bitcoin miner will choose the one that pays them the most > money. > > >I might be wrong but I thought that OP_RETURN outputs do not go into the > UTXO set. Anyone else want to chime in? > > I'm fairly certain you are right. It just feels like we should be able to > exploit the fact that *only* miners can claim these OP_BRIBEVERIFY outputs. > I'll have to think about this more, maybe some one else can come up with >
Re: [bitcoin-dev] BIP Proposal: Compact Client Side Filtering for Light Clients
Just to give you a number: based on the statistics of the Bitcoin Wallet app there are at least 2 million wallets depending on BIP37. Not all would need instant notification but based on the daily support enquiries instant notificaton is the most asked property of Bitcoin. On 06/19/2017 02:26 PM, bfd--- via bitcoin-dev wrote: > Several times. It's been debated if unconfirmed transactions are > necessary, methods of doing more private filtering have been suggested, > along with simply not filtering unconfirmed transactions at all. My > collected data suggests that there is very little use of BIP37 at > present, based on incoming connections to nodes I know end up in the DNS > seed responses (no "SPV" clients do their own peer management). > > > On 2017-06-19 12:58, Andreas Schildbach via bitcoin-dev wrote: >> I'm not sure if this has been brought up elsewhere in this thread. >> >> This proposal doesn't seem to be a complete replacement of BIP37: It >> doesn't provide a filter for unconfirmed transactions like BIP37 does. >> >> That means that most light clients will continue to use BIP37 even if >> they may use this BIP as a supplement. Otherwise users would not get >> timely notification of incoming payments any more. >> >> >> On 06/01/2017 09:01 PM, Olaoluwa Osuntokun via bitcoin-dev wrote: >>> Hi y'all, >>> >>> Alex Akselrod and I would like to propose a new light client BIP for >>> consideration: >>>* >>> https://github.com/Roasbeef/bips/blob/master/gcs_light_client.mediawiki >>> [...] >> >> ___ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP Proposal: Compact Client Side Filtering for Light Clients
On Monday, 19 June 2017 14:26:46 CEST bfd--- via bitcoin-dev wrote: > It's been debated if [filtering of] unconfirmed transactions are > necessary, Why would it not be needed? Any SPV client (when used as a payment-receiver) requires this from a simple usability point of view. -- Tom Zander Blog: https://zander.github.io Vlog: https://vimeo.com/channels/tomscryptochannel ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP Proposal: Compact Client Side Filtering for Light Clients
Several times. It's been debated if unconfirmed transactions are necessary, methods of doing more private filtering have been suggested, along with simply not filtering unconfirmed transactions at all. My collected data suggests that there is very little use of BIP37 at present, based on incoming connections to nodes I know end up in the DNS seed responses (no "SPV" clients do their own peer management). On 2017-06-19 12:58, Andreas Schildbach via bitcoin-dev wrote: I'm not sure if this has been brought up elsewhere in this thread. This proposal doesn't seem to be a complete replacement of BIP37: It doesn't provide a filter for unconfirmed transactions like BIP37 does. That means that most light clients will continue to use BIP37 even if they may use this BIP as a supplement. Otherwise users would not get timely notification of incoming payments any more. On 06/01/2017 09:01 PM, Olaoluwa Osuntokun via bitcoin-dev wrote: Hi y'all, Alex Akselrod and I would like to propose a new light client BIP for consideration: * https://github.com/Roasbeef/bips/blob/master/gcs_light_client.mediawiki [...] ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP Proposal: Compact Client Side Filtering for Light Clients
I'm not sure if this has been brought up elsewhere in this thread. This proposal doesn't seem to be a complete replacement of BIP37: It doesn't provide a filter for unconfirmed transactions like BIP37 does. That means that most light clients will continue to use BIP37 even if they may use this BIP as a supplement. Otherwise users would not get timely notification of incoming payments any more. On 06/01/2017 09:01 PM, Olaoluwa Osuntokun via bitcoin-dev wrote: > Hi y'all, > > Alex Akselrod and I would like to propose a new light client BIP for > consideration: >* https://github.com/Roasbeef/bips/blob/master/gcs_light_client.mediawiki > [...] ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev