Note: this change will not be merged before the initial release as long as the one-patch-project policy is in effect.

Can you reference the PR in Core in which the change which you are proposing reverting was made?

That would be this PR.

Oh, gotcha. Do you want to do some research and try to dig out the context for this? It's a lot easier to read the arguments for why this was done in the first place than to try to think of the arguments from scratch.

We do have other priorities, though. Right now, it's just blocksize related stuff that we're going to allow (unless the vote changes on consider.it), so the zero-conf related stuff will have to wait a bit.

One thing that could be useful to pull from XT is the thin blocks code in XT PR 109. I'm not sure if it's ready to be deployed, but I think it's pretty close, and it's probably also ready to be tested.

Our first release will probably be based on 0.11.2, by the way. Not the 0.11.2 branch that's in our repo right now, because that's actually derived from BitPay's 0.11.2 branch, but Core's 0.11.2 branch. I guess I need to make a branch for that...

Perhaps we could talk on another channel so we can make sure you make it to the dev meetings? It would be nice to get things coordinated so we're not wasting or duplicating efforts, and so we can all work together as a team.

@jtoomim The trickle code appears to have been designed to make IP tracing of transaction origins harder and breaks out transaction IP origin tracking capability. We mass connect to all bitcoin nodes and probe them for transactions in order to bypass any trickle delays(which makes it more difficult to find out where transactions are originating from). Since we are in the business of double spend tracking and compliance tracking(for sites that aren't legally allowed to serve certain jurisdictions) it makes our jobs more difficult. Should I make a consider.it proposal for this?

(edit: Removed, I got this confused with another instance.)

I think we should collect more information first. I think people have been putting half-baked ideas on consider.it a lot, and would much rather have a discussion with arguments for and against in place before it makes it to consider.it. Consider.it doesn't work very well for negotiating complicated concepts.

We need a proper email list.

Hey @cointracker, we've got a list of PRs merged by Core between 0.11.2 and master that we've been sorting through. Perhaps you want to help with that?

https://stackedit.io/editor#!provider=couchdb&id=utbv9YT5uzpRAyXJjzgW6tdb

@jtoomim Well I think his logic was that it was privacy invading but it would basically destroy our business model, there isn't really a good way to track transactions otherwise. If we can't track transactions it's a little bit tricky to monitor double spends and transaction origins. I'd like to remove the trickle logic altogether.

I've marked bitcoin#7125 in the stackedit as needing more thorough conceptual review once we get to working on the master branch.

@jtoomim @cointracker:

I had to move the list off of stackedit due to the risk of defacement by trolls. Please send people to https://gist.github.com/christophebiocca/259470c579065af9f469 from now on.

Do you think #4 might solve it?

This change in 0.12 would make our 0-conf tracking much less reliable if deployed.

NACK. This justification makes no sense. What 0-conf tracking?

Sounds like they've got a way to figure out which IP address initially sent a transaction by using the timings, and the change in Core breaks that.

Why we would want to revert a change that improves senders' privacy is unclear to me.

@christophebiocca It's unclear to me too brother.

@dgenr8 The trickle code causes problems with our transaction tracking capability it makes it harder for us to determine accurately which nodes have received a particular transaction and when.

@christophebiocca Yes accurate timing is critical for being able to accurately track transaction IP origins and propagation of the transaction to various nodes on the network.

ACK.

Merge window is open only for 2 MB HF stuff.

An exception for this PR is not justified. A vote has been started on consider.it. It does not appear to be a favorable change.

I am closing this. It may be reopened after the fork.

@cointracker this functionality might make for a nice business model, but it goes against the original concept of censorship-proof P2P electronic cash.

If you know the originating node of a transaction, it increases the likelihood that 'the bad guys' will also be able to find out and be able to censor them.

Revisit at a later date. RAALD

@NanoAkron We realize some consider this a privacy issue however leaving the trickle code would significantly hurt our ability to prevent double spends.

NACK.

@ghost Looks like you need to find a new business model, if your current model relies on breaking Bitcoin's privacy. As @NanoAkron said, Bitcoin is censorship-resistant P2P cash. Cash is typically private & fungible, and these are core values of the Bitcoin project. Moving forward, you should expect increased privacy, so I'd advise to rework your business model.

the extent to which this should be alarming cannot be understated.

@Leviathn the proposer has deleted their github account. It is not clear if they were ever serious about reverting this change or were just trying to create drama.