gribble 2017-01-09 12:15:53
#bitcoin: Beware of scams! Scammers are sending users private messages with bitcoin-stealing malware and offers to trade. We are unable to stop them, so you must protect yourself. NEVER download or run programs from strangers! When in doubt, ask the ops.
luke-jr 2017-01-09 12:15:56
Dizzle: as in, you won't convince trolls to stop trolling.
abpa 2017-01-09 12:16:10
How does that work?
marijnfs 2017-01-09 12:16:16
LND lools pretty cool
Iriez 2017-01-09 12:16:29
people simply bid tx price as they always have and as always miners decide which tx's to pickup in the block
Iriez 2017-01-09 12:16:34
they prioritize by value
abpa 2017-01-09 12:16:35
You can't have a market system because nodes can't participate as a cost
cluelessperson 2017-01-09 12:16:53
mryandao, which white paper describes proof of work?
Iriez 2017-01-09 12:17:03
abpa: the price of the space is determined by the value of fee's
Iriez 2017-01-09 12:17:10
so the market decides.
Iriez 2017-01-09 12:17:20
the miner is going to pickup the most valuble tx's for the space
abpa 2017-01-09 12:17:22
I don't understand
Iriez 2017-01-09 12:17:24
as its more money to him
Iriez 2017-01-09 12:17:36
ok, maybe we are just not thinking along the same lines :)
abpa 2017-01-09 12:17:44
Why doesn't the miner just add all the transactions that are available?
Iriez 2017-01-09 12:17:50
blocks are full?
abpa 2017-01-09 12:17:58
I thought this was a way to bypass that
Iriez 2017-01-09 12:18:00
this is "Excess" transactions
Iriez 2017-01-09 12:18:02
no
Iriez 2017-01-09 12:18:09
well yes or maybe, not sure what you are thinking
Iriez 2017-01-09 12:18:23
this allows the miner to expand blocksize, and to retrieve 10% of availible rewards
Iriez 2017-01-09 12:18:34
but only if he agree's to subtract 90% of that same amount from his subsidy
abpa 2017-01-09 12:18:42
Why doesn't the miner just always expand to the maximal degree
Iriez 2017-01-09 12:18:48
to put in a future reward to be delivered to the miner who wins the block 10 blocks from that block
Dizzle 2017-01-09 12:18:49
luke-jr: sure, but if my mind could be changed (it was), someone else's could too. A lot of earlier Unlimited supports (like myself) had issue with how long it would take segwit to be ready. Well, it's here and we've put up with the "full blocks" for months without a collapse of the Bitcoin economy.
abpa 2017-01-09 12:18:50
Please don't say orphan risk :D
Iriez 2017-01-09 12:19:10
abpa: the miner is going to expand it. He's going to collect as many fee's as he can
Iriez 2017-01-09 12:19:26
and if the market has put the money on the table to be taken, then he should take it.
abpa 2017-01-09 12:19:41
Right so let's say I put a billion transactions on the network, and I pay 1 btc total. Why doesn't he include all 1 billion in one block even if he only gets 0.1 btc reward?
Iriez 2017-01-09 12:19:50
but only if he agree's to take 90% from his subsidy towards future rewards
Iriez 2017-01-09 12:20:02
abpa: he gets 10% of the reward
abpa 2017-01-09 12:20:09
Still, he has no cost
Iriez 2017-01-09 12:20:12
and agree's to give 90% from the subsidy
Iriez 2017-01-09 12:20:18
so he keeps net 10%
abpa 2017-01-09 12:20:23
OK so this is a temporary system that is based on the subsidy
Iriez 2017-01-09 12:20:31
he has a economic reason to do it, and also a economic cost to not fraudulently create fake tx's
Iriez 2017-01-09 12:20:35
abpa: yes
Iriez 2017-01-09 12:20:39
it does not work without the subsidy
Iriez 2017-01-09 12:20:51
but, as you said before, it extends the life of hte subsidy
Iriez 2017-01-09 12:21:03
or we can change it so that it pools into a bigger resource that lasts long
Iriez 2017-01-09 12:21:18
for example, it could put it in a global pool, and then whoever wins the next block gets 1% of the pool rewards
Iriez 2017-01-09 12:21:51
it could be delayed further, but i think its good to have shorter term rewards that the miners can see happen sooner than later, so it feels "real" to them.
Iriez 2017-01-09 12:22:11
but this solves the fraud tx issue
Iriez 2017-01-09 12:22:15
because there is a real cost to the miner
Iriez 2017-01-09 12:22:25
he has to subtract from his subsidy to get the reward
Iriez 2017-01-09 12:22:31
so no incentive to fake tx's with fake fee's
Iriez 2017-01-09 12:22:52
if 10% is too high, lets make it 5% or 2% ....whatever would make more sense.
Iriez 2017-01-09 12:23:08
But enough to create a incentive, but not too much that it skews the game theory
gmaxwell 2017-01-09 12:23:29
please don't spin your wheels assuming subsidy, it will be nothing in not that many years and bitcoin can't afford to give ammo to people saying "It _can't work_ after N years."
Iriez 2017-01-09 12:23:53
2036 subsidy: 0.390625 BTC
Iriez 2017-01-09 12:24:06
I imagine BTC will be worth a LOT in 20 years, or nothing
Iriez 2017-01-09 12:24:21
for all we know, 2036 0.390625 BTC might be worth more than 12.5 BTC today
Iriez 2017-01-09 12:24:31
thinking 20 years into the future is pretty far out.
gmaxwell 2017-01-09 12:24:41
It's already worth a lot, "our system is great only if the price is driven to hights that are unimaginable by the many small minded people of today" is not a good argument.
Iriez 2017-01-09 12:24:42
Im just trying to think of good solutions now, that will work for the next few decades.
abpa 2017-01-09 12:25:07
The subsidy ratio still has the same pricing problem
gmaxwell 2017-01-09 12:25:21
A solution which inserts _failure_ N years out propagates that valueness back to today, simply not having oodles of capacity is a limitation but not a failure.
Iriez 2017-01-09 12:25:43
gmaxwell: a perfect solution that does not exist is no better than a non-perfect solution.
gmaxwell 2017-01-09 12:25:47
in particular making things that depend on subsidy will create more future pressure to make bitcoin inflationary.
Iriez 2017-01-09 12:26:01
I agree with your statements btw.
Iriez 2017-01-09 12:26:19
Its just that all the smartest minds dont seem to have a long term solution. That is worrying.
gmaxwell 2017-01-09 12:26:52
Iriez: taking bitcoin from a system that is obviously viable for all time, but perhaps limited, to one which is obviously NOT viable for all time, is not a good tradeoff. Especially when an obvious answer to that non-viability is making it inflationary. :)
Iriez 2017-01-09 12:27:12
gmaxwell: subsidy eventually disappears, as you know.
Iriez 2017-01-09 12:27:17
its the same problem under both scenario's
gmaxwell 2017-01-09 12:27:20
We have a fine "long term solution"-- leave it how it is. Not /ideal/ perhaps, but it's a viable system that results.
gmaxwell 2017-01-09 12:27:43
Iriez: yes and we have fees, we're not counting on subsidty to continue and fees are already high enough to provide for non-trivial security.
Iriez 2017-01-09 12:28:06
unless your argument is that we must allow for a fee market to establish a strong foothold without flexibility?
TheButterZone 2017-01-09 12:28:10
https://www.reddit.com/r/btc/comments/5mzoeq/new_proof_of_concept_service_called_preferred/dc7utks/ womp womp
piqure 2017-01-09 12:28:11
^^^ WARNING: any URL may lead directly or indirectly to COIN-STEALING MALWARE! ^^^
Iriez 2017-01-09 12:28:12
If so, I get that.
___Charlie 2017-01-09 12:28:53
Hi!
Iriez 2017-01-09 12:28:59
Is your position that any flexcap would eventually disappate the fee market, thereby destroying the incentive to mine?
gmaxwell 2017-01-09 12:29:02
Iriez: hm? well it almost has now.-- its certantly easier to reason about these things when the proposals aren't tained by people trying to prevent a functioning fee market from existing at all. But nah, that wasn't my point.
gmaxwell 2017-01-09 12:29:08
Iriez: no no no
Iriez 2017-01-09 12:29:12
ok, sorry
gmaxwell 2017-01-09 12:29:58
Iriez: It sounded above like you were making proposals that depended on subsidy. And I was making a general argument that even though proposals like that would work in the short term, they would erode bitcoin's value by leaving us in a position where we honestly could say "we don't know how this could work long term"
Iriez 2017-01-09 12:30:13
Ok, what if we replace the subisy with pre-owned btc?
Iriez 2017-01-09 12:30:20
what if a mienr has to put up collateral for the system?
Iriez 2017-01-09 12:30:26
miner*
Iriez 2017-01-09 12:30:32
subsidy* jesus.
gmaxwell 2017-01-09 12:30:43
thats an improvement-- though incentives are tricky and you lose a bit of permissionlessness of mining, but probably not a substantial amount.
Iriez 2017-01-09 12:30:48
right.
Iriez 2017-01-09 12:31:14
Because in that system, if the miner doesnt have collateral, he simply cannot expand the blocksize
Iriez 2017-01-09 12:31:20
so no harm
gmaxwell 2017-01-09 12:31:47
Meni had a proposal in that space, I had made some parallel proposal about twiddling difficulty to pay for these things.
gmaxwell 2017-01-09 12:31:54
interesting point.
gmaxwell 2017-01-09 12:32:35
so the next problem then is how do you deal with floating bitcoin value?
gmaxwell 2017-01-09 12:33:00
I think I've forgotten meni's proposal
Iriez 2017-01-09 12:33:02
https://bitcointalk.org/index.php?topic=1078521.0
piqure 2017-01-09 12:33:03
^^^ WARNING: any URL may lead directly or indirectly to COIN-STEALING MALWARE! ^^^
Iriez 2017-01-09 12:33:04
this one?
Iriez 2017-01-09 12:33:12
Elastic block cap with rollover penalties ?
Iriez 2017-01-09 12:33:54
tl; dr: I propose replacing the hard cap on the data size of a block (1MB, 20MB, or whatever it is) with an elastic one, where resistance to larger blocks accumulates progressively. Miners will be required to pay a superlinear penalty for large blocks, to be paid into a rollover fee pool. This will greatly increase Bitcoin's robustness to a situation where the block cap is approached, and
Iriez 2017-01-09 12:33:54
allow a healthy fee market.
Iriez 2017-01-09 12:34:12
yea, thats pretty much what im saying, heh.
Iriez 2017-01-09 12:35:10
I think it would be nice if this "super lineral penalty" paid into the "rollover fee pool", if that pool also paid out for full nodes as well.
Iriez 2017-01-09 12:35:41
but of course, then we get into the "how do we prove full node" discussion, which is annoying.
Iriez 2017-01-09 12:35:56
I recall your "proof of storage" idea from a while back. I wish we would see some progress in that space
Iriez 2017-01-09 12:38:43
gmaxwell: Does value really need to be assigned? I suppose it would if we wanted to reward fairly. With decentralized marketplaces with the advent of LN, we might be able to programatically pull value from marketplaces. Until then, I dont see any good solutions that dont require trust from centralized providers.
abpa 2017-01-09 12:39:21
Algorithmically determining value sounds super hard to me
gmaxwell 2017-01-09 12:39:41
oh that isn't my point. it's that when you connect size to bitcoin values, you don't know the constant factor to relate the units because the value of a bitcoin could be anything.
Iriez 2017-01-09 12:39:52
right
Iriez 2017-01-09 12:40:06
one solution is to say fuckit, and ignore $ value and denominate always in btc
Iriez 2017-01-09 12:40:16
the pool could allocate x amount of satoshi's per block
gmaxwell 2017-01-09 12:40:17
really $ doesn't come into it.
Iriez 2017-01-09 12:40:30
and that could be constant regardless of market price
trotski2000 2017-01-09 12:40:36
"Iriez: taking bitcoin from a system that is obviously viable for all time, but perhaps limited, to one which is obviously NOT viable for all time, is not a good tradeoff. Especially when an obvious answer to that non-viability is making it inflationary. :)" (gmaxwell) -> that should be stickied
gmaxwell 2017-01-09 12:41:41
I mean how much should you defer? the reason that I liked (in spite of its other limitations) the proposal that ignored fees and used miners optionally increasing their difficulty to increase space is because there was no free floating constant factor.
Iriez 2017-01-09 12:42:21
would the increase to difficulty be for that miner/pool, or for everyone?
gmaxwell 2017-01-09 12:43:14
just yourself, to make a block X bigger than the Y-percentile of recent history you must mine at a difficulty f(X) higher.
gmaxwell 2017-01-09 12:43:39
and the f(X) is setup so capacity is still increased even though the interblock interval slows.
gmaxwell 2017-01-09 12:44:00
and for the chain selection logic you are still selected based on the base difficulty work.
gmaxwell 2017-01-09 12:44:28
basically its a pay x% of your income to increase y% scheme, but without having to measure your income, so it's not defeated by fee bypass.
Iriez 2017-01-09 12:44:30
I see, that makes sense.
Iriez 2017-01-09 12:44:42
And why do you think this might not work?
Iriez 2017-01-09 12:44:59
(im asking you to play devils advocate against yourself)
Iriez 2017-01-09 12:45:14
or, what criticisms have you received?
gmaxwell 2017-01-09 12:45:24
Lots of details to work out, including f(x) -- I concluded before that it has to be at least quadratic in shape to result in increasing capacity, no linear formula will do so.
Iriez 2017-01-09 12:45:53
Well, I'll buy you some coffee to work them out? ;)
Iriez 2017-01-09 12:46:02
I promise to pay in bitcorn.
gmaxwell 2017-01-09 12:46:36
There is basically one proble, with it: it's very expensive to increase the blocksize when subsidy is much larger than typical fees.
gmaxwell 2017-01-09 12:46:59
Because you increase by y% and get some small additional fees, but then take a big chunk out of your subsidy.
gmaxwell 2017-01-09 12:47:17
that issue is artifical and only exists because subsidy is radically higher than typical fees.
gmaxwell 2017-01-09 12:48:04
Otherwise-- Not too many in fact, more that a lot of people just didn't get it. Gavin went pyric about it on the list, because he did the math with the function I threw out with a straw man and saw that it was really expensive to increase the blocksize with the 25 btc subsidy at the time.
Iriez 2017-01-09 12:48:12
Hrm, perhaps i misunderstood. I didn't think that the subsidy was effected by the taking of extra fee revenue by increasing blocksize, i thought that the difficulty was just adjusted for your *next* block work.
gmaxwell 2017-01-09 12:49:24
the subsidy isn't adjusted. If you want to make a block X% bigger, you say so in your block, then you have to meet a difficult target of diff*f(x).
gmaxwell 2017-01-09 12:49:50
because your difficulty is higher your probably of getting your income (all forms, including out of band fees and subsidy) is decreased.
gmaxwell 2017-01-09 12:50:00
so it totally escapes the fee bypass problem.
Iriez 2017-01-09 12:50:21
Oh, ok, I see what you are saying. The subsidy is reduced for the next block probability overall
Iriez 2017-01-09 12:50:26
not from that current block.
abpa 2017-01-09 12:50:31
It might have strange interactions with the market, the demand for transactions seems to be very oriented towards very quick or very slow confirmations and not so much in the middle
gmaxwell 2017-01-09 12:50:33
but when fees are highly non-isotropic you end up taking a cut on the high fee transactions you take (including the subsidy) in order to include a few more low fee ones...
mryandao 2017-01-09 12:50:41
is there an off-chance that other miners might try to orphan your chain to reap your high paying transactions off your high-diff block?
gmaxwell 2017-01-09 12:51:00
Iriez: no not for the next block. the subsidy values and fees and what not all stay the say-- just your probablity of finding a block at all goes down.
Iriez 2017-01-09 12:51:11
right, i get it now.
Iriez 2017-01-09 12:51:24
how long does the adjusted difficulty last?
gmaxwell 2017-01-09 12:51:31
mryandao: sure, but thats always the case (and one of the reasons the system needs constant fee pressure in order to be stable)
gmaxwell 2017-01-09 12:51:50
Iriez: just that one block, if the next block is a normal maxsize then it's normal difficulty.
Iriez 2017-01-09 12:51:59
Then that seems like a excellent tradeoff to me.
Iriez 2017-01-09 12:52:16
your guaranteed income instead of theoretical income
Iriez 2017-01-09 12:52:25
always take the money off the table when its there.
Iriez 2017-01-09 12:52:48
the liklihood of finding 2 blocks in a row is very low except for bigger pools
gmaxwell 2017-01-09 12:52:57
I think it's elligant in a lot of ways, you can easily decide the income maximizing size, which will normally be the base-maximum... but if there is a big backlog the income maximixing size will be larger.
gmaxwell 2017-01-09 12:53:37
which is what we want-- the size should only increase when it's not undermining the backlog but when the rate of high fee paying txn is simply higher.
Iriez 2017-01-09 12:54:18
Is it on your todo list to formalize a proposal?
gmaxwell 2017-01-09 12:54:47
I haven't really been thinking about at all, the initial response was abusive, and I don't think it's very inmportant in the short term.
Iriez 2017-01-09 12:55:22
Well perhaps the initial response would be more positive under current conditions? And with the details worked out.
Iriez 2017-01-09 12:55:30
We are in a different situation than we were 1.5 years ago.
gmaxwell 2017-01-09 12:56:16
Iriez: climate around bitcoin has not really gotten better; I'm also concerned that it's just too hard for people to get.
abpa 2017-01-09 12:56:33
What's the best case scenario of a flex cap in the short term?
mryandao 2017-01-09 12:56:37
wouldn't block reorg happen a lot more frequently if said scheme was in place?
abpa 2017-01-09 12:57:07
You mean fee sniping?
mryandao 2017-01-09 12:57:10
yes
cotix 2017-01-09 12:57:12
gmaxwell: What do you mean by get? Like understanding how it works on a technical level?
TandyUK 2017-01-09 12:57:18
any new mining hardware on the horizon?
TandyUK 2017-01-09 12:57:47
got a client looking to invest £100k+ in hardware for a new project, if i can find anything for him to spend his dosh on!
mryandao 2017-01-09 12:57:49
miners take on high risk to mine bigger blocks only to be sniped later on
abpa 2017-01-09 12:57:55
Sounds likely to me, fee sniping is a potential problem if you reduce the relevance of the subsidy
gmaxwell 2017-01-09 12:57:57
mryandao: I don't think so, why do you think that?
gmaxwell 2017-01-09 12:58:08
mryandao: they are risking the block though, nothing else.
gmaxwell 2017-01-09 12:58:17
mryandao: which is always what you risk in sniping.
gmaxwell 2017-01-09 12:58:42
abpa: yes, that is why there _must_ be a backlog. otherwise you're a moron who will go broke if you don't snipe.
abpa 2017-01-09 12:58:45
You also have a problem where if you snipe how do you get other miners to not snipe you?
mryandao 2017-01-09 12:58:57
cartels might form
mryandao 2017-01-09 12:58:59
collusion
gmaxwell 2017-01-09 12:59:00
(must be a backlog or some yet non-invented magic)
mryandao 2017-01-09 12:59:03
:/
gmaxwell 2017-01-09 12:59:30
mryandao: or just all the small miners that get sniped all the time have to yield to a 50%+ miner (or cartell) that rarely/never gets sniped.
abpa 2017-01-09 12:59:47
I think it was proposed to come up with some kind of "Merchant's Association" for miners to promote long term stability
abpa 2017-01-09 13:00:03
But it could be very unstable since it could fall apart
gmaxwell 2017-01-09 13:00:43
Iriez: one of my frustrations is that I think the block size is _much_ less important than issues like fee sniping, and worse, done poorly could greatly complicate improving fee sniping and such. I think blocksize is one of those things that everyone can kind of understand and so gains a vastly disrpoportionate amount of attention.
mryandao 2017-01-09 13:01:26
i think pool mining deserves more attention
mryandao 2017-01-09 13:01:30
it needs to be solved!
gmaxwell 2017-01-09 13:01:52
If Bitcoin's blocksize stayed 1mb forever (e.g. even no segwit)-- it would be a perfectly viable system that could be very valuable. Right now we process more txn per day than there are commercial transfers of physical gold. I think it would be _dumb_ and wasteful to be forever limited to the current capacity, but it wouldn't stand in the way of bitcoin being very important and very valuable.
mryandao 2017-01-09 13:01:55
non-poolable mining
cotix 2017-01-09 13:02:00
Why? Pool mining is the only thing that allows small players to still make profit mining
mryandao 2017-01-09 13:02:38
it also encourages centralisation
TandyUK 2017-01-09 13:02:46
roughly how many txn does a 1mb block equate to?
cotix 2017-01-09 13:02:50
Not really, individual miners can still switch
gmaxwell 2017-01-09 13:02:55
But there are many other interesting questions that we don't have ready to go solutions... not so fundimental that we can't be sure the system will work out, but we do need to fix these other things.
TandyUK 2017-01-09 13:03:02
im so oldskool with btc i never forsaw the 1mb block being a problem
cotix 2017-01-09 13:03:02
If there were no pools, only the very very big miners could mine
mryandao 2017-01-09 13:03:02
but really, how often does an individual miner switch?
abpa 2017-01-09 13:03:09
If the alternative to pool mining is cloud mining you might be jumping from the frying pan into the fire
gmaxwell 2017-01-09 13:03:15
TandyUK: typical blocks right now have about 3k txn-ish.
mryandao 2017-01-09 13:03:29
what even is "cloud mining"????? *asking sarcastically"
TandyUK 2017-01-09 13:03:38
so 3k per 10 mins, i suppose as a global currency/market that is pretty small
Veriphant 2017-01-09 13:03:46
Hey, what are the rules regarding linking to my new platform? Am I allowed to link to it?
cotix 2017-01-09 13:03:57
mryandao: Often enough, a lot of times people were jumping on the bandwagon that some pool had 40% of the hashrate and people switched
TandyUK 2017-01-09 13:04:04
Veriphant: from my earlier experiences id advise against it :P
Veriphant 2017-01-09 13:04:20
Okay!
gmaxwell 2017-01-09 13:04:20
Veriphant: if it's bitcoin related, feel free to tell us what it is and link to it.
TandyUK 2017-01-09 13:04:24
although tbf i did post an address
Veriphant 2017-01-09 13:04:33
https://veriphant.com/
piqure 2017-01-09 13:04:34
^^^ WARNING: any URL may lead directly or indirectly to COIN-STEALING MALWARE! ^^^
TandyUK 2017-01-09 13:04:42
what is it?
gmaxwell 2017-01-09 13:04:43
just don't drive by and leave links and say nothing else.
Veriphant 2017-01-09 13:04:50
Veriphant allows you to irrevocably store cryptographic finger-print representations of any data no matter how large or in what format, allowing verification of immutability and proof of existence of any such data.
gmaxwell 2017-01-09 13:05:01
(it's usually a bad idea to just follow links here)
Veriphant 2017-01-09 13:05:02
That good enough for you gmaxwell?
Veriphant 2017-01-09 13:05:13
I kept it to the point
gmaxwell 2017-01-09 13:05:13
Veriphant: fair enough. So how does it relate to opentimestamps?
TandyUK 2017-01-09 13:05:18
Veriphant: so essentially a different form or md5sum/sha1 hash
TandyUK 2017-01-09 13:05:27
s/or/of
Veriphant 2017-01-09 13:05:53
I guess so - it uses SHA-256 mostly
abpa 2017-01-09 13:06:25
Why not use a merkle tree aggregation so you can fold together proofs more efficiently?
Veriphant 2017-01-09 13:06:44
I will eventually - getting funding first
abpa 2017-01-09 13:07:01
Are these transactions on the Blockchain?
Veriphant 2017-01-09 13:07:09
Yup
gmaxwell 2017-01-09 13:07:42
bleh.
Veriphant 2017-01-09 13:07:57
Be nice :)
gmaxwell 2017-01-09 13:07:58
so you know there is already an open network that uses merkle tree aggregation called opentimestamps.
Veriphant 2017-01-09 13:08:20
Yeh
gmaxwell 2017-01-09 13:08:22
And it also can digitally sign the timestamps to give higher resolution (though with trusting the signer a bit)
abpa 2017-01-09 13:09:21
One feature I'd suggest Veriphant is a way to make a chain of proofs so that you can know that there aren't multiple proofs
abpa 2017-01-09 13:09:53
How do I know that you didn't "prove existence" of multiple conflicting records
Veriphant 2017-01-09 13:11:09
The finger-prints of the snapshots are made using the same bitcoin wallet in order. Each snapshot shows a progression of additions only.
abpa 2017-01-09 13:11:21
I also agree that it would be better if everyone could work together to bundle their proofs into a single proof instead of everyone making new OP_RETURN outputs
mryandao 2017-01-09 13:21:17
that'd still require a user to trust the aggregation service to do the right thing
abpa 2017-01-09 13:22:02
Not really because you present the proof still
abpa 2017-01-09 13:22:18
The rest of the aggregation can just be represented as some hashes you don't care about
mryandao 2017-01-09 13:22:29
maybe trust is not the right word
mryandao 2017-01-09 13:22:36
but the user has to depend on
mryandao 2017-01-09 13:22:51
service could still be denied to the user
abpa 2017-01-09 13:23:05
The failure scenario is just that no proof is entered yeah
abpa 2017-01-09 13:24:13
Maybe it could be distributed with a multisig
abpa 2017-01-09 13:25:03
I wonder if open timestamps has covered censorship resistance
mryandao 2017-01-09 13:25:05
schnorr signature aggregation
abpa 2017-01-09 13:25:55
Something simple like 1 of 10 might work, you'd need all 10 servers to be uncooperative
abpa 2017-01-09 13:27:22
The only censorship I can remember being discussed in open timestamps was resisting miner censorship
mryandao 2017-01-09 13:28:10
isn't it just a generic P2SH transaction?
abpa 2017-01-09 13:28:29
It could be, I thought it was an OP_RETURN though
mryandao 2017-01-09 13:29:18
if that's the case, then yea miners could censor
abpa 2017-01-09 13:29:31
If it's a chain of transactions then miners can censor no matter what
mryandao 2017-01-09 13:30:20
but game theory would suggest miners would never censor
mryandao 2017-01-09 13:30:45
its like the prisoner's dilemma
mryandao 2017-01-09 13:30:45
if one miner isn't gonna reap the fees, another will!
abpa 2017-01-09 13:31:02
That might be oversimplifying things
