1 2017-06-28 03:03:30 <decentony> here is an idea and feedback appreciated
  2 2017-06-28 03:04:23 <decentony> in order to promote miner decentralization in the light of increasing importance of fees for miner profit
  3 2017-06-28 03:04:53 <decentony> a miner blacklisting feature on the bitcoin wallets
  4 2017-06-28 03:07:10 <decentony> when a user blacklists certain miners this info will be given to a third party service and 3rd party provides a subset of self-identifying miner addresses/ports using a secure channel
  5 2017-06-28 03:07:59 <decentony> size of the subset is proportional with the speed of being included in a block
  6 2017-06-28 03:09:05 <decentony> if a transaction ends up going to the blacklisted miner, the each miner's distrust score in the subset is incremented.
  7 2017-06-28 03:09:28 <decentony> later this score is used for choosing new subsets
  8 2017-06-28 03:10:55 <decentony> i'd expect a high distrust score to indicate cheating miners in this blacklisting.
  9 2017-06-28 03:14:33 <decentony> eventually these 3rd party services would act as a place to estimate miners share in finding the blocks. And 3rd party services are encouraged share their findings with other services; such as miner x, y, z were blacklisted but got the fee based on this subset of miners.
 10 2017-06-28 03:15:38 <decentony> an adversary would prefer dividing their hashrate to identify as separate entities.
 11 2017-06-28 03:16:26 <decentony> * be identified
 12 2017-06-28 03:17:34 <decentony> while this may help them for a while, eventually users would get some idea about the new entity's ownership
 13 2017-06-28 03:18:37 <decentony> end result is blacklisted miner's trying to look much more smaller.
 14 2017-06-28 03:20:20 <decentony> wallets may have presets like ignore top 3 etc to make it easier and latency estimation to see what the user is giving away to promote latency.
 15 2017-06-28 03:29:39 <decentony> notice this is not direct miner selection or whitelisting which harms small miners.
 16 2017-06-28 03:31:08 <decentony> 3rd parties may prefer asking participitating miner/pool their ideas about future roadmap items such as scaling, fungibility and quantum resistance.
 17 2017-06-28 03:34:15 <decentony> 3rd parties may be obliged to justify their scoring (maybe broadcasting the end result with timestamp proofs and checking the tx was not already in the mempool.
 18 2017-06-28 03:34:20 <decentony> )
 19 2017-06-28 03:57:17 <decentony> * promote decentralization
 20 2017-06-28 04:18:29 <adam3us> a problem is mining is anonymous by design.  and that's useful to help with censor resistance.  you cant demand a miner censor a transaction if you dont know which miner mined the block.
 21 2017-06-28 04:19:51 <decentony> in this case owner of the fee is asking a voluntary censorship
 22 2017-06-28 04:20:49 <decentony> tx info will be denied to the blacklisted miner, only the subset receives the info and keep for themselves
 23 2017-06-28 04:20:56 <decentony> nope?
 24 2017-06-28 04:23:10 <adam3us> problem is you cant (easily) blacklist a miner who is anonymous
 25 2017-06-28 04:23:55 <decentony> 3rd party service accepts voluntary miner registration and self identification
 26 2017-06-28 04:24:32 <decentony> a service like coin dance which already recognizes the miner who mined the block
 27 2017-06-28 04:26:17 <decentony> as long as miners keep totally anonymous, no problem. nobody can invite them for a consensus meeting room.
 28 2017-06-28 04:26:29 <Chicago> decentony, How would your centralized service defend against a pool/miner who rewards a new address with each minted block ---  while relaying the new block through a network of proxy daemons?
 29 2017-06-28 04:27:16 <decentony> a new address a new miner you mean?
 30 2017-06-28 04:27:39 <Chicago> Also, why would you punish the users and diminish the utility of the blockchain by making the transactions which are included by a miner be considered invalid since the block would be invalidated.
 31 2017-06-28 04:28:09 <decentony> nothing is invalid
 32 2017-06-28 04:28:52 <decentony> just punished with denying the next blacklisting user's fee next time
 33 2017-06-28 04:29:06 <Chicago> In fact if you introduce a centralized service which causes coin daemons to not relay blocks from specific miners, then you've delayed the user's transactions until they're included in a next block.
 34 2017-06-28 04:29:29 <decentony> blocks are relayed no issue with that
 35 2017-06-28 04:30:14 <Chicago> A proof-of-work solution is a proof-of-work solution any attempt to reduce it to less diminishes the security of the Bitcoin network and introduces great potential for abuse.
 36 2017-06-28 04:30:14 <decentony> blacklisted miner just can not include the tx in their block since they do not know about the tx
 37 2017-06-28 04:30:45 <Chicago> There is no way you can prevent a miner from knowing about a transaction unless you know every single one of the nodes they use to attach to the network.
 38 2017-06-28 04:30:52 <decentony> proof-of-work still works no question on that
 39 2017-06-28 04:31:30 <decentony> if i send the transaction to only one miner
 40 2017-06-28 04:31:44 <decentony> and he does not broadcast to any other node?
 41 2017-06-28 04:31:59 <Chicago> You *could* propose a coalition of miners where transactions are only relayed to them because the transactions were only given to the coalition - but this would be silly because the coalition's mining power would be nowhere near convenient for a user to expect their transaction to be included in a next block.
 42 2017-06-28 04:32:30 <decentony> that's why blacklisting
 43 2017-06-28 04:32:41 <decentony> that's why blacklisting
 44 2017-06-28 04:32:56 <decentony> lets say 20% hashrate is blacklisted, and a subset of 60% selected
 45 2017-06-28 04:33:00 <Chicago> picking winners and losers _IS_ centralization
 46 2017-06-28 04:33:12 <decentony> user experience 40% latency
 47 2017-06-28 04:33:53 <decentony> mining reward is still there given to the one mining the block
 48 2017-06-28 04:34:14 <decentony> but the fee belongs to the user, he shall have a choice
 49 2017-06-28 04:34:51 <Chicago> This proposal is anti-competitive and violates the ethos of decentralization.
 50 2017-06-28 04:35:59 <Chicago> try it
 51 2017-06-28 04:36:06 <Chicago> ... see if the miner incentive disappears
 52 2017-06-28 04:36:09 <decentony> miners can compete by also improving PR other than their mining tech
 53 2017-06-28 04:36:20 <Chicago> ... see if the user's tolerate the delay for no incentive
 54 2017-06-28 04:37:22 <decentony> miner incentive consists of reward (their technological investment) and fee (in this design as a result of good PR)
 55 2017-06-28 04:38:46 <decentony> this also provides a leverage for avoiding a veto against fungibility and quantum resistance.
 56 2017-06-28 04:39:46 <Chicago> First it starts by saying some miners are blacklisted... and then it continues by saying their colored coins aren't to be accepted by a merchant... this decreases fungibility and does not increase it.
 57 2017-06-28 04:39:48 <decentony> some stake holders may not want those future proposals but possibly users may want and show their support with fees
 58 2017-06-28 04:40:45 <decentony> actually this is a step to get fungibility : )
 59 2017-06-28 04:41:02 <Chicago> - so you're suggesting the fee, which would be earned by the good miner is nothing more than a donation -- because it certainly wasn't to get the transaction included in a block any faster
 60 2017-06-28 04:41:22 <decentony> otherwise little adversarial thinking reveals fungibility and quantum resistance will possibly face veto
 61 2017-06-28 04:42:09 <decentony> fee for playing well in line with the user's opinion
 62 2017-06-28 04:43:13 <decentony> since user's are decentralized noone shall claim this will hurt themselves unless they are thinking about users and the system as a whole
 63 2017-06-28 04:45:02 <Chicago> You're telling me -- to only send my transaction to a very small subset of miners and hope it will be included in a block eventually; and suppose this coalition of miners has just 0.5% of the mining power... why would a user wait a few days longer than they ordinarily would to have their transaction confirmed by the network?
 64 2017-06-28 04:45:15 <decentony> any technical issue with sending a tx to some miners and their keeping to their own block only?
 65 2017-06-28 04:46:06 <decentony> parameters can be find out using some simulation
 66 2017-06-28 04:46:15 <decentony> but the subset is not that small
 67 2017-06-28 04:46:28 <decentony> you can take a 40% subset
 68 2017-06-28 04:46:42 <Chicago> Okay... 40%
 69 2017-06-28 04:46:52 <Chicago> ... now we have another very serious centralization issue
 70 2017-06-28 04:47:06 <Chicago> The last thing the network needs is a new untrusted player owning 40% of the network hash rate.
 71 2017-06-28 04:47:13 <decentony> since this is selected randomly, dishonest miner (one sharing with blacklisted) will score higher
 72 2017-06-28 04:47:27 <decentony> no random 40%
 73 2017-06-28 04:48:12 <decentony> 0.001 + .1 + .. so on to make 40%
 74 2017-06-28 04:48:20 <Belxjander> decentony: given enough computing power and historical records...it IS possible to begin predicting pseudo-random number generator responses...
 75 2017-06-28 04:48:28 <decentony> it may involve thousands of miners
 76 2017-06-28 04:49:25 <decentony> randomness is not issue here 3rd party is sampling the miners excluding the blacklisted one
 77 2017-06-28 04:49:37 <Belxjander> decentony: and on a computer any set of rules to make an RNG is at best Pseudo-Random...maybe you need to rethink how you present this idea since the presentation seems to be showing flaws... and I'm not quite sure what you are trying to "solve" with this kindof "solution" idea?
 78 2017-06-28 04:50:28 <Belxjander> decentony: so basically an *optional* service where miners can become blacklisted if they share details with that service ?
 79 2017-06-28 04:51:12 <decentony> yes if they do not share they do not get anything from users opting to use blacklisting
 80 2017-06-28 04:51:41 <Chicago> decentony, have a look at how the blacklisting patches for spam transactions were received by the community when Gentoo GNU/Linux included them.
 81 2017-06-28 04:51:49 <Belxjander> then youi are splitting the userbase andhow miners receive blocks from the new transaction pooling
 82 2017-06-28 04:52:30 <Belxjander> Chicago: I remember that ... it went down like a lead balloons halo jump...
 83 2017-06-28 04:52:41 <Chicago> yes
 84 2017-06-28 04:52:43 <Belxjander> terminal velocity only one way
 85 2017-06-28 04:53:12 <decentony> sure i can have a look at that. but this idea relies on the owner of the fee must have a say about where is does not go.
 86 2017-06-28 04:54:19 <decentony> and this may be the only way to empower users until millions of users start mining with usb miners expecting no profit
 87 2017-06-28 04:54:59 <Chicago> decentony, you are correct.  Essentially, the user has no say unless the user mines the block on their own.
 88 2017-06-28 04:55:26 <decentony> is there a way to prevent a miner/pool exceeding 50% hashrate now?
 89 2017-06-28 04:55:30 <decentony> nope
 90 2017-06-28 04:55:33 <Chicago> sure!
 91 2017-06-28 04:55:52 <Chicago> The incentive of total system failure prevention leads miners to abandon such a pool and redistribute their hash rate.
 92 2017-06-28 04:56:16 <Chicago> If the abuse were pervasive then there would be an emergency correction in one way or another, perhaps by changing the PoW algorithm.
 93 2017-06-28 04:56:16 <decentony> such a blacklisting may deny significant percent of income making it unprofitable to maintain that.
 94 2017-06-28 04:56:27 <decentony> yes exactly
 95 2017-06-28 04:56:37 <decentony> this is what we need
 96 2017-06-28 04:57:00 <decentony> distributing the hashrate until you can not fit more than 50
 97 2017-06-28 04:57:04 <decentony> % into a room.
 98 2017-06-28 04:57:08 <Chicago> You're proposing a fix to symptoms of a problem and not a fix to the actual problem.
 99 2017-06-28 04:58:08 <decentony> with the current consensus system this fix (which can not be blocked by any entity) may stand the only option.
100 2017-06-28 04:58:12 <Chicago> Plus, you cannot have consensus _unless_ you bring along the inherent 51% attack risk.
101 2017-06-28 04:58:53 <decentony> yes they should not come together in a room
102 2017-06-28 04:59:16 <decentony> consensus shall not be reached in a room
103 2017-06-28 04:59:24 <decentony> maybe a stadium better
104 2017-06-28 04:59:37 <decentony> maybe dozens of stadiums
105 2017-06-28 04:59:39 <Chicago> consensus does not come from the miners, consensus comes from network protocol and full nodes
106 2017-06-28 05:01:00 <Belxjander> Chicago: has anyone documented what he essential elements to dealing with the blockchain, and separately what is essential for a "wallet" along with transaction processing in a general sense outside the source code ?
107 2017-06-28 05:01:03 <decentony> yes sure, it should come from nodes. but they may be called Sybil then
108 2017-06-28 05:01:39 <Chicago> Belxjander, gosh I don't know.
109 2017-06-28 05:02:02 <Belxjander> ahh okay...
110 2017-06-28 05:02:53 <Chicago> decentony, Please describe the core behaviors of a miner which should be blacklisted.
111 2017-06-28 05:04:13 <decentony> this is not a political discussion users will decide that. some may like democratic pools some may like the pool enforcing an idea
112 2017-06-28 05:05:13 <decentony> some may try avoiding top 3
113 2017-06-28 05:05:17 <Chicago> Your proposal may be more accurately described as a transaction sieve where transactions are to only be sent to a very specific subset of the network.
114 2017-06-28 05:06:07 <decentony> yes something like that
115 2017-06-28 05:06:49 <decentony> now anyone can do this no change in protocol, just an additional optional protocol
116 2017-06-28 05:07:23 <Chicago> And what liability would their be for your service if the transaction ends up being broadcast to the greater Bitcoin network and included by a "bad miner" in the next block?
117 2017-06-28 05:07:34 <decentony> better providing a reference for easier adoption, and score broadcasting to other services
118 2017-06-28 05:08:45 <decentony> if blacklisted miner gets the fee by including it in the block, all miners in the subset are incremented with equal distrust score
119 2017-06-28 05:09:26 <Chicago> Also, the law of supply and demand states those miners who are "bad" will not suffer because there is a surplus of transactions to fill a 1MB block already -- and unless you're telling me the users will both pay higher fees _and_ wait a substantial amount of time for their transaction to be included in a block - I cannot see how the bad miners will lose a thing.
120 2017-06-28 05:09:41 <decentony> dishonest one is expected to do it again always collecting and reducing the probability of being selected in the next subset
121 2017-06-28 05:10:09 <Belxjander> Perception bubbles....
122 2017-06-28 05:10:34 <decentony> lets say we have 10k txs
123 2017-06-28 05:10:45 <decentony> half of these people are politically active
124 2017-06-28 05:10:55 <decentony> and have non-urgent txs
125 2017-06-28 05:11:25 <decentony> lets say 80% wants to avoid one miner
126 2017-06-28 05:12:02 <decentony> blacklisted miner loses 40% fees assuming no mempool
127 2017-06-28 05:12:10 <Chicago> problem
128 2017-06-28 05:12:30 <Chicago> blacklisted miner loses nothing -- because there is a surplus of high fee transactions for them to include in the next minted block
129 2017-06-28 05:13:24 <decentony> no mempool
130 2017-06-28 05:13:39 <Belxjander> Chicago: this comes across similart to how people self-select associating with others who agree with a point of view formnig clique bubbles of perception leading towards general ignorance
131 2017-06-28 05:13:42 <decentony> and continuous 40% loss
132 2017-06-28 05:14:17 <Chicago> so
133 2017-06-28 05:14:42 <Chicago> from the other side -- let's say you have a politically aligned miner who is one of the good guys, who formerly mined with a pool earning a steady income
134 2017-06-28 05:14:45 <Belxjander> decentony: only half your 10,000 transaction pool are political and even with 80% (8,000 listing that one miner as please ignore) that miner still has a 2000 transaction pool to pickup and mine
135 2017-06-28 05:14:59 <decentony> and assume mining near empty blocks is not an option due to pending halvings
136 2017-06-28 05:15:27 <Belxjander> decentony: so there is no real loss for the miner at all regardless of generating the next block with or without your idea
137 2017-06-28 05:16:07 <Chicago> You are now asking that miner to forgo the mining incentive and steady rewards because they've now become such an insignificant player in relative terms to the current total network hashrate that their participation in mining may be largely ignored.
138 2017-06-28 05:16:29 <decentony> yes blacklisted makes blocks with 6000 txs, another miner with 10000 txs
139 2017-06-28 05:17:03 <Chicago> Also -- let's suppose you are successful in users selecting your option.  At what point will your transaction backlog become so large you choose to start broadcasting them to the rest of the network in an emergency?
140 2017-06-28 05:17:35 <Belxjander> decentony: and is there anything stopping or an incentive for miners to support your idea?
141 2017-06-28 05:17:44 <decentony> wallet can notify the estimated latency and user may delay their political acts
142 2017-06-28 05:18:15 <decentony> an incentive to get political users fees
143 2017-06-28 05:18:47 <Chicago> You will find the blockchain already successfully resists political influence very easily.
144 2017-06-28 05:18:49 <decentony> a miner not so good with users may start a campaign to stop this
145 2017-06-28 05:18:52 <Belxjander> decentony: If I were to do mining I would ignore your service and run anonymous nodes with various settings to make sure I always had a chance to obtain the block reward and not care about your blacklisting
146 2017-06-28 05:19:12 <decentony> if you do that
147 2017-06-28 05:19:57 <decentony> you will not get an invitation to the meetings like hong kong or new york
148 2017-06-28 05:20:18 <Belxjander> decentony: the only produced effect of such selections would be that the mining population would no longer trust the transaction producing wallets in relation to this optional service and therefore the service would have to resort to underhanded tactics in order to validate that they *are*not*lied*to*
149 2017-06-28 05:21:21 <Belxjander> decentony: so what? this is dividing the community of users and miners and leading towards active mistrust, not passive mistrust along with active deceptive practise becoming the normal
150 2017-06-28 05:21:42 <decentony> users already choose one wallet vs another
151 2017-06-28 05:21:50 <decentony> based on their futures
152 2017-06-28 05:21:55 <decentony> * featues
153 2017-06-28 05:22:21 <decentony> nobody knows your political idea
154 2017-06-28 05:22:26 <Belxjander> and all wallets have *extended* features in trying to obtain market mindshare...
155 2017-06-28 05:22:28 <decentony> only you and your wallet
156 2017-06-28 05:22:31 <decentony> no division
157 2017-06-28 05:22:44 <Belxjander> you are pushing that selections into the basic foundations of how bitcoin works and not extra "this might be nice" features
158 2017-06-28 05:22:47 <decentony> only some disappearing miner/pools
159 2017-06-28 05:22:51 <decentony> silently
160 2017-06-28 05:23:31 <Belxjander> fragmentation of the network opening up isolation attacks and critical divisions
161 2017-06-28 05:23:45 <Chicago> so... why not just offer a bitcoin proxy service, where the users who want to opt-in have to go through your gateway and they only send/receive with nodes in your network?
162 2017-06-28 05:24:00 <Chicago> btw, that would be madness because of the filtering and largely destructive.
163 2017-06-28 05:24:34 <Belxjander> isolate / modify and then push *modified* transactions to the larger mining comunity from your isolated groups who can not see by self-selected blindness
164 2017-06-28 05:25:09 <Belxjander> those wallets using this service would become blinded to if they are truly isolated (your proposal here would enable a bad-actor man in the middle isolation)
165 2017-06-28 05:25:31 <decentony> here is the problem geeks can still do this despite some hassle, the value is making this a straight forward feature of wallets
166 2017-06-28 05:25:49 <Chicago> Do not mistake your proposal as a wallet feature.
167 2017-06-28 05:25:55 <Chicago> It is merely a network segment.
168 2017-06-28 05:26:17 <Chicago> You can do this already without one single change to Bitcoin Core.
169 2017-06-28 05:26:29 <Belxjander> basically report different miners as "good" or "bad" based on your search criteria and then cut your bitcoins out of the network... attack the isolated hardware as a target of opportunity...and once your bitcoin wallet keys are obtained... keep you isolated and drain your wallet without your awareness of the network beyond your self-imposed blindness
170 2017-06-28 05:26:36 <decentony> yes exactly no change needed on core
171 2017-06-28 05:27:34 <Belxjander> sigh...
172 2017-06-28 05:27:37 <decentony> good and bad is decided by users
173 2017-06-28 05:27:47 <decentony> wallet does not say anything
174 2017-06-28 05:27:48 <Chicago> no
175 2017-06-28 05:27:55 <Chicago> good and bad must only be decided by network protocol
176 2017-06-28 05:28:02 <Chicago> otherwise there is further potential for political abuse
177 2017-06-28 05:29:00 <Belxjander> decentony: and bad-actor mitm attacks would respond to your search queries... work out what you think is "good" based on your miner selection criteria... and then set themselves up...towards isolateing you from the rest of the network
178 2017-06-28 05:29:19 <Belxjander> once you are isolated... your done
179 2017-06-28 05:29:37 <Chicago> He still hasn't answered how he would defend against an adversary who mines every next block to pay to a unique scriptPub
180 2017-06-28 05:29:39 <decentony> this is just like choosing uber vs lyft, pepsi vs coke. it is your fee you shall be at least able to deny it to someone you oppose politically or just because they are big
181 2017-06-28 05:29:56 <decentony> i anwsered
182 2017-06-28 05:30:21 <decentony> this is already a good thing if the miner pretends like a new miner all the time
183 2017-06-28 05:30:55 <decentony> 1. they need to take to hassle to register again identifying themselves
184 2017-06-28 05:31:28 <Belxjander> decentony: with regards to political or other "objection"s about the miner... that is just being pissy-^assed pedantic and self-isolating within an "everyone I know agrees with this" perception bubble...
185 2017-06-28 05:31:53 <decentony> 2. if they manage to automate this, it will look like another mining = loss of show of power = no invitation to meetings
186 2017-06-28 05:31:57 <Belxjander> once the network becomes segmented in such bubbles it also becomes easier to assualt, divide and destroy
187 2017-06-28 05:32:49 <Chicago> decentony, why not just do what you are proposing the old fashion way by mining your own blocks?
188 2017-06-28 05:33:00 <Belxjander> decentony: if I was a miner...I wouldn't care about your service or the meetings as long as I received transactions and was able to mine enough fees from transactions
189 2017-06-28 05:33:14 <Chicago> ^^ a certainty
190 2017-06-28 05:33:26 <Belxjander> decentony: there is no incentive for your service to be essential
191 2017-06-28 05:34:06 <decentony> users cant be simply miners in large scale but they can choose to deny their fees.
192 2017-06-28 05:34:30 <decentony> can we improve it to make it appealing that
193 2017-06-28 05:34:34 <decentony> then?
194 2017-06-28 05:34:36 <Chicago> "It is hard" is not the same as "cannot".
195 2017-06-28 05:34:46 <decentony> but hopefully you get the idea behind this
196 2017-06-28 05:34:59 <Chicago> Yes, you want aristocoin.
197 2017-06-28 05:35:23 <decentony> user shall be ok with you if you do not go to meetings and reveal your opinion
198 2017-06-28 05:35:36 <Belxjander> decentony: I see it as "I'm X, I want miners who agree with X"... being pushed as an extended attribute into the money system of bitcoin...
199 2017-06-28 05:35:38 <decentony> be a neutral miner then no reason to be blacklisted
200 2017-06-28 05:35:55 <Belxjander> where it is irrelevant, useless and totally meaningless to operational requirements
201 2017-06-28 05:36:09 <Chicago> The core ethos of mining from Satoshi's whitepaper is the miner incentive to earn as much as possible.
202 2017-06-28 05:36:44 <Belxjander> Chicago: exactly...beyond that incentive there is nothing introduced here as a positive net gain for any miner who agrees to the scheme
203 2017-06-28 05:36:46 <Chicago> It doesn't matter if there is an ASIC with a more competitive mathematical method.
204 2017-06-28 05:37:42 <decentony> competitive ASIC will guarantee you mining reward but not the fee without good PR
205 2017-06-28 05:38:23 <decentony> getting political users' fees shall be enough incentive for miners to join this
206 2017-06-28 05:38:30 <Chicago> SO...  you propose acceptance of your organization usurping transaction ingress for the betterment of all Bitcoin?
207 2017-06-28 05:38:59 <decentony> may be not now exactly but after halving it will make more and more sense
208 2017-06-28 05:39:35 <Chicago> After halving, is also irrelevant.  Do you not expect miner's to demand the same payment at that time?
209 2017-06-28 05:40:28 <decentony> yes this looks to be the only way to prevent vetoes against future proposals such as fungibility and quantum resistance
210 2017-06-28 05:41:04 <Belxjander> decentony: this seems more of a veto of consensus being possible as it is now
211 2017-06-28 05:41:05 <Chicago> What are you trying to say exactly, do you think bitcoin are not fungible already or do you have an example of this?
212 2017-06-28 05:41:18 <Belxjander> just a means of fragmenting and destroying bitcoin entirely
213 2017-06-28 05:41:22 <decentony> miners will demand/need for fees right, so good incentive to enroll in this
214 2017-06-28 05:41:46 <decentony> yes they are not fungible
215 2017-06-28 05:42:11 <Belxjander> decentony: WHY? ... *what*incentive*???
216 2017-06-28 05:42:19 <Chicago> so you're saying you would refuse to accept bitcoin which had been partially associated w/ a Silk Road transaction?
217 2017-06-28 05:42:30 <decentony> a hacker stealing btc from an exchange is caught if he exchanges those at another exchange
218 2017-06-28 05:42:43 <decentony> so we know the previous source
219 2017-06-28 05:43:33 <Chicago> Okay -- and suppose some exchange rejects them and another exchange accepts them -- and they are then used by the other exchanges users on withdrawal.  Will you then say those innocent users who obtained bitcoins which were part of a theft 3 transactions in the past are now shit out of luck?
220 2017-06-28 05:43:40 <Chicago> This is why we don't have colored coins.
221 2017-06-28 05:43:43 <Belxjander> decentony: would you refuse to handle any USD paper money that had contact with cocaine?
222 2017-06-28 05:44:50 <decentony> paper money's serial number might have been recorded if thats a setup so no fungibility
223 2017-06-28 05:45:05 <decentony> other than paper money has better fungibility
224 2017-06-28 05:45:32 <decentony> satoshi can not spend his btcs w/o revealing he is satoshi : )
225 2017-06-28 05:45:43 <Chicago> Also... with atomic swaps and decentralized exchange on the horizon, there is no reason to except any bad actor couldn't spend their inputs unless they lose their private key or don't want to be detected on the network.
226 2017-06-28 05:46:56 <decentony> any reason for miners to accept quantum as a danger? acceptance = their miners are bricks
227 2017-06-28 05:48:37 <Chicago> You could also rephrase the complaint of your users to be "I want to participate in an economy and it is unfair someone profits from it."
228 2017-06-28 05:50:25 <decentony> for the betterment of the consensus/community it may be unfair for someone to profit from it
229 2017-06-28 05:51:22 <Chicago> Transactions being there or not being there do not change the outcome of consensus at the network protocol level.
230 2017-06-28 05:51:36 <decentony> mining reward is fair share of every miner, but fee belongs to user
231 2017-06-28 05:51:50 <Chicago> fees do not belong to the user the moment they broadcast the transaction
232 2017-06-28 05:52:32 <decentony> loss of fee makes pressure on miner to mind the balances
233 2017-06-28 05:53:08 <Chicago> A surplus of transactions means the miner has no pressure other than to continually participate in the arms race and have a higher hashrate.
234 2017-06-28 05:53:19 <Belxjander> decentony: but regardless... there is NOTHING in your proposal where there is any actual loss of fees,...
235 2017-06-28 05:53:44 <Belxjander> no losses and no actual incentive to participate
236 2017-06-28 05:53:55 <Belxjander> so it becomes irrelevant
237 2017-06-28 05:54:00 <Chicago> oh I get it now
238 2017-06-28 05:54:05 <Chicago> It is just virtue signaling.
239 2017-06-28 05:54:11 <decentony> it is hard to see now since still mining near empty blocks makes sense for a rational player
240 2017-06-28 05:54:53 <Chicago> not really decentony, the merkle tree can be assembled from existing waiting transactions well before the hash of the previous block is known
241 2017-06-28 05:55:32 <decentony> 60% fee 40% reward after one or two halving good luck with arms race to compansate the fee loss
242 2017-06-28 05:55:43 <Chicago> there will be no loss
243 2017-06-28 05:56:04 <Chicago> I'm telling you, the halvening simply brings the laws of supply and demand to a focal point where the BTC cost increases.
244 2017-06-28 05:56:26 <Chicago> production cost of BTC remains the same
245 2017-06-28 05:56:46 <decentony> cost same return is same you mean?
246 2017-06-28 05:57:59 <Chicago> At the next halvening, production cost of a bitcoin will remain the same because the cost of electricity and the cost of an ASIC will be approximately the same.  However, because the new supply of bitcoin will be diminished and the demand will dictate the price -- saying 60% fee and 40% reward is only relative in terms of BTC not in terms of fiat.
247 2017-06-28 05:58:11 <decentony> thank you guys for the brainstorming, lets reconsider after mining near full blocks makes more economic sense
248 2017-06-28 05:59:01 <decentony> i appreciate your inputs i will reevaluate my idea as well.
249 2017-06-28 05:59:15 <Chicago> decentony, are you saying this visualization is irrational?  https://blockchain.info/charts/avg-block-size
250 2017-06-28 05:59:49 <Chicago> I think the average block size speaks for itself.
251 2017-06-28 06:00:18 <decentony> daily average
252 2017-06-28 06:00:35 <decentony> we have real low data points
253 2017-06-28 06:01:53 <Chicago> You are suggesting every miner is incentivized to ignore transactions entirely to be competitive.  The data does not tell the same story.
254 2017-06-28 06:38:10 <sturles> decentony: I haven't read the complete discussion, but it seems you want to promote decentralization by intruducing a centralized service (the 3rd party)?
255 2017-06-28 06:42:34 <decentony> as long as 3rd parties are provided with an open spec to score miners and share their scoring with proofs to sync other 3rd parties
256 2017-06-28 06:42:37 <decentony> why not?
257 2017-06-28 06:43:20 <decentony> a decentralized scoring system may be considered also.
258 2017-06-28 06:48:40 <decentony> decentralized one would work like a smart contract, wallet commits encrypted tx and only non-blacklisted subset is allowed to decrypt is by sharing key with them as opposed to tx
259 2017-06-28 06:49:55 <decentony> and smart contract performs scoring fairly, the subset selection belongs to wallet in this case
260 2017-06-28 06:50:07 <decentony> getting the score list
261 2017-06-28 06:51:26 <decentony> havent thought of decentralized one but looks promising when i think about it.
262 2017-06-28 06:52:53 <decentony> ( now)
263 2017-06-28 07:02:28 <decentony> decentralized one may also accept registration only by locking certain amount of BTC
264 2017-06-28 07:03:08 <decentony> miners are free to keep registering again again as different miners as long as they can afford it.
265 2017-06-28 07:03:32 <Chicago> This fee would be considered extortion by many.
266 2017-06-28 07:04:12 <Chicago> It is essentially "protection money".
267 2017-06-28 07:04:19 <decentony> they can take it back fully after certain time
268 2017-06-28 07:05:31 <decentony> (just brainstorming about this now guys havent thought about this before so it might be completely stupid, i am ready to step back if you can point some issues)
269 2017-06-28 07:05:51 <decentony> yes protection monet
270 2017-06-28 07:06:00 <decentony> in the end miners will follow the money
271 2017-06-28 07:06:18 <decentony> if mempool is not enough to fill in the block
272 2017-06-28 07:06:36 <Chicago> "If you won't pay me then you won't be able to conduct business."  This is extortion.
273 2017-06-28 07:07:04 <decentony> they will know where to look for if they are given some tx key (notice this is not user's private key for sure)
274 2017-06-28 07:07:57 <decentony> nope if you want more fees from politically active users there you are.
275 2017-06-28 07:08:29 <decentony> fee may be good for preventing registering as a new miner for each block
276 2017-06-28 07:08:50 <Chicago> Have a 2016 block waiting period for inclusion, make them wait an entire timespan.
277 2017-06-28 07:09:16 <decentony> but as i said before it can be waived since miner is decentralizing themselves by identifying as new miner
278 2017-06-28 07:09:38 <decentony> yes this is also possible
279 2017-06-28 07:09:58 <Chicago> Is this just a way for you to collect BTC to trade while they're letting you hold their bitcoin before you return it to them?  We call it a loan.
280 2017-06-28 07:10:07 <decentony> waiting is possible too
281 2017-06-28 07:11:44 <decentony> consider it like the amount equivalent to the amount they would expect to get avoid the blacklisting by identifying themselves as a new miner
282 2017-06-28 07:11:58 <decentony> calculation might be dynamic as well
283 2017-06-28 07:12:37 <decentony> miner would be sacrificing liquidity
284 2017-06-28 07:12:40 <decentony> only
285 2017-06-28 07:12:55 <decentony> in the they will get it after certain time
286 2017-06-28 07:13:04 <decentony> *in the end
287 2017-06-28 07:24:38 <decentony> 2016 block waiting time sounds good
288 2017-06-28 07:26:26 <decentony> it would be great if the registered miners and their block shares is regarded as only source of truth in determining miner power by the community
289 2017-06-28 07:27:06 <Chicago> except for those who are aligned with other political beliefs in opposition to yours -- who is to say which is right?  (the network protocol)
290 2017-06-28 07:28:56 <decentony> this system does not really care about who is right or wrong, just indicates the wisdom of the crowd having an impact on miners
291 2017-06-28 07:29:29 <decentony> otherwise tons of in-fights on subreddits/twitter etc.
292 2017-06-28 07:31:10 <decentony> miners may expect a loss of income due to a senseless tweet for instance
293 2017-06-28 07:32:07 <decentony> expect to see billboards of pools trying to show how much they love users (even their full nodes) and decentralization : )
294 2017-06-28 07:33:48 <decentony> this creates a feedback loop between users and miners
295 2017-06-28 07:34:56 <decentony> resignations or apologies by pool CEO may be expected to revive their business
296 2017-06-28 07:36:22 <Chicago> What happens when there are no BIPs signaling in version bits or other "controversy"?  At that time what will the users be voting on to show support?
297 2017-06-28 07:36:37 <Chicago> popularity contest?
298 2017-06-28 07:38:40 <decentony> then comes the philosophical choices rather than political
299 2017-06-28 07:38:53 <decentony> avoid top 1 preset
300 2017-06-28 07:38:58 <decentony> avoid top 3 etc
301 2017-06-28 07:39:20 <Chicago> In other words a perpetual attack for the sake of wealth redistribution.
302 2017-06-28 07:39:29 <decentony> sure some users will not forget history
303 2017-06-28 07:39:31 <Chicago> The blockchain and Bitcoin do not need this.
304 2017-06-28 07:40:48 <decentony> sure yours is an idea too, you in this case can blacklist mostly non-blacklisted ones too.
305 2017-06-28 07:41:20 <decentony> to disrupt the user fee power
306 2017-06-28 07:41:47 <decentony> but wisdom of the crowd and collective high fees may be hard to beat
307 2017-06-28 14:33:10 <xenog> I am working on segwit compatibility for bitcoinJ. I'd like to write tests that will assure that I am counting sigops correctly, is there a way using the RPC interface of Bitcoin Core to get the sigop count of a block?
308 2017-06-28 14:47:06 <wumpus> I don't think that information is in getblock by default, you could add it for testing ofc
309 2017-06-28 17:17:42 <xenog> Thanks wumpus, I found some tests that I can adapt.