sipa changed the topic of #bitcoin-wizards to: This channel is for discussing theoretical ideas with regard to cryptocurrencies, not about short-term Bitcoin development | http://bitcoin.ninja/ | This channel is logged. | For logs and more information, visit http://bitcoin.ninja
<tulip>
SomeT: stenography probably isn't what you're looking for at any rate, it's obfuscation rather than security.
<AdrianG>
tulip: you could splice in encrypted data that looks nearly random, even if extracted.
<nsh>
*steganography is not necessarily obfuscation and can be used with high security strong cryptography
<nsh>
(in fact it's kinda silly to use it without first strongly-encrypting)
<AdrianG>
steganography is about plausible deniability, rather than obfuscation, imo.
<tulip>
it's still obfuscating the cipher text though, rather than having any security in itself though.
<SomeT>
I mean I was looking at using it at that level not just adding one layer of stenography to it
<SomeT>
I am still in the extreme early stages, I just thought this would be an interesting project to help me get from intermediate c++ to advanced kinda level
<tulip>
AdrianG: maybe, I personally filed it away as something neat but with limited real world application.
<bramc>
Steganography generally speaking adds a ridiculous amount of overhead, the covertext:ciphertext ration is about 500:1 on a warm day
<SomeT>
ok but logically that over head can be managed somehow?
jcluck has joined #bitcoin-wizards
<tulip>
depends what you're thinking of doing with it in relation to Bitcoin.
<SomeT>
I mean firstly it would be to see if its possible, then to see if people would buy into the idea, then hopefully branch off into some sort of alt coin
<SomeT>
(obviously in not a simplistic way)
cluckj has quit [Ping timeout: 250 seconds]
<tulip>
I don't see any use for classical stenography in Bitcoin really. trying to obscure transaction or block traffic by stuffing it into other unrelated streams of data might be interesting, but that's a p2p protocol layer rather than anything consensus related.
<SomeT>
um your points are interesting
<SomeT>
think still I might start by reading up on stenography
<SomeT>
and see if I can notice anything and I may be back in that respect with a few more questions
<tulip>
as you wish.
<erasmospunk>
anybody would like a peer review a BIP I am drafting?
<tulip>
sure.
<SomeT>
I am not ignoring what has been said to me
<SomeT>
I am not going to invest time in something that is not amicable
<SomeT>
anyway thanks again
<SomeT>
cya
SomeT has left #bitcoin-wizards [#bitcoin-wizards]
<Jeremy_Rand>
Hello. In a hypothetical coin where unspent outputs expire after some time of not being spent, what additional attack vectors get introduced if the outputs expire based on a fixed time difference in block timestamps, as opposed to a fixed difference in block height?
<Jeremy_Rand>
(I assume there are additional attack vectors?)
<erasmospunk>
Jeremy_Rand: it would get complicated to combine inputs
<Jeremy_Rand>
erasmospunk: can you elaborate on that?
cluckj has joined #bitcoin-wizards
Lightsword has quit [Quit: Lightsword]
<erasmospunk>
Jeremy_Rand: say that I have 2 UTXOs with one expiring in 1 day and the other in 7 days. When should the new output expire?
jcluck has quit [Ping timeout: 250 seconds]
<Jeremy_Rand>
erasmospunk: let's say that the expiry time is a fixed duration (common to all UTXO's) after the UTXO is mined
<Jeremy_Rand>
(so if you want to keep your coins, you must spend them at least once per duration)
<erasmospunk>
Jeremy_Rand: give me a couple of minutes to formulate a response
<Jeremy_Rand>
erasmospunk: ok
<aj>
Jeremy_Rand: i'd be worried about clumping -- bunch of outputs in one block all expire in the same future block, so might all get spent at the same time so they don't get lost
<Jeremy_Rand>
I should probably disclose that I'm primarily interested in this question in the context of naming coins, where name outputs have to expire in some way. (Although I'm also interested in responses about currency applications, because it interests me abstractly too.)
<Jeremy_Rand>
as one example of an attack vector I'm curious about, is there a way that miners could steal coins or force them to expire by messing with the block timestamps, if expiry is based on block timestamp?
<aj>
Jeremy_Rand: bip113 avoids miners messing with block timestamps a bit
<aj>
s/avoids/prevents/
* Jeremy_Rand
goes to lookup BIP113, as I don't remember what it does off the top of my head
Guest46010 has quit [Changing host]
amiller has joined #bitcoin-wizards
Guest46010 is now known as amiller
<erasmospunk>
Jeremy_Rand: In that case instead of measuring the value of an output in satoshis, we apply the formula number of satoshis * 2^(1/number of blocks)
<erasmospunk>
this value will degrade 10x
Lightsword has joined #bitcoin-wizards
<Jeremy_Rand>
aj: ah, BIP 113 does indeed seem like an improvement in this respect.
Quanttek has quit [Ping timeout: 264 seconds]
<Jeremy_Rand>
aj: hypothetically, could BIP 113 be modified to use a much longer period? Let's say, thousands of blocks instead of 11? Would it have any bad effects if it were done?
<Jeremy_Rand>
(I guess another question is, would that have any beneficial effects either?)
<Jeremy_Rand>
e.g. more time to detect misbehaving or malicious miners?
<Jeremy_Rand>
err, thinking about it, I guess that would make the exact time specified by the lock time, much less precise?
<erasmospunk>
Jeremy_Rand: I think the mean previous time is pretty accurate of the reality
<bramc>
okay I've written my proof checking functions. An amusingly insidious and easy to write bug is to accept proofs of inclusion as proofs of exclusion.
<Jeremy_Rand>
erasmospunk: ok. So relying on the BIP 113 timestamps is believed to be acceptable security-wise for preventing undesired expiration/theft of coins?
<aj>
Jeremy_Rand: median time of the last 10 blocks should usually be about 50 minutes ago; median time of the last 1000 blocks would be a week ago...
<aj>
Jeremy_Rand: "acceptable" is a judgement call, it's an improvement though...
DougieBot5000 has joined #bitcoin-wizards
<Jeremy_Rand>
aj: right. But I guess the last 1000 blocks would have substantially higher uncertainty, since it's more suceptible to hashrate changes?
dEBRUYNE has quit [Ping timeout: 250 seconds]
<Jeremy_Rand>
aj: so, a number of Namecoin users are unhappy that they can't predict exactly when their 36000 block expiry time will hit. It sounds like using the BIP 113 timestamps would be an improvement in terms of certainty. Unless I'm misunderstanding something about threat model differences between the approaches.
<aj>
Jeremy_Rand: the more blocks the more any manipulation should be averaged out
pozitron has quit [K-Lined]
<Jeremy_Rand>
aj: yeah, it averages out, I guess, but aren't the latter half of the blocks going to be influenced by whether the mining hashrate of the network is increasing or decreasing over that time period?
<Jeremy_Rand>
like, if the network is accelerating its hashrate, then 500 blocks is over a shorter clock time span
<Jeremy_Rand>
whereas 5 blocks doesn't really matter as much given the same accelerating hashrate?
<aj>
Jeremy_Rand: if you're using median time past, you're comparing actual time to block timestamps; block height doesn't matter
ttttemp_ has joined #bitcoin-wizards
<Jeremy_Rand>
aj: but the difference between the median time past and the time that the current block was mined, will be fuzzier, no? Or am I highly confused?
<aj>
Jeremy_Rand: hmm, i'm not sure. you could do some statistics on past block times to work it out though
ttttemp has quit [Remote host closed the connection]
<Jeremy_Rand>
aj: hmm, yes, empiricism would probably resolve my confusion. I'll run some statistics sometime when I have a chance.
Lightsword_ has joined #bitcoin-wizards
Lightsword has quit [Ping timeout: 250 seconds]
Lightsword_ is now known as Lightsword
kang_ has joined #bitcoin-wizards
Lightsword_ has joined #bitcoin-wizards
lmatteis has quit [Quit: Connection closed for inactivity]
Lightsword has quit [Read error: Connection reset by peer]
Lightsword_ is now known as Lightsword
Lightsword_ has joined #bitcoin-wizards
Yoghur114 has quit [Remote host closed the connection]
Lightsword has quit [Ping timeout: 260 seconds]
Lightsword_ is now known as Lightsword
JackH has quit [Quit: Leaving]
but_seriously has joined #bitcoin-wizards
<but_seriously>
Hey all.
<but_seriously>
I have an idea.
<but_seriously>
A theoretical idea.
<but_seriously>
It has probably been thought of many times before...
<but_seriously>
Anyone?
<kang_>
go on
<but_seriously>
It occured to me that people mine for crypto's, just hashing blocks until the find a block that produces a hash that starts with the target string.
<but_seriously>
I also see people wasting a lot of labour mining for "fictional" diamonds (etc) in minecraft.
<but_seriously>
What we need is a fun way of combining the two.
<but_seriously>
A minecraft that lets a player literally mine for blocks that produce an ore (or whatever) that can be converted to a crypto currency.
<smk>
i think huntercoin addressed this concept a while back.. there are some others that have cropped up
<but_seriously>
Everyone plays on the same map, and just like with the blockchain, P2P tech determines who found the ore first.
<Jeremy_Rand>
but_seriously: yes, Huntercoin is basically exactly that
<but_seriously>
And provides a method for distributing modified chunks with a little delay as possible.
<but_seriously>
Cool.... huntercoin. Thanks.
<kang_>
but_seriously: Also see BitQuest
<but_seriously>
Yeah, it looks like huntercoin is asking people to buy "hunters" with bitcoin. That ain't what I'm talking about. I want a mining game that has no barrier to entry -- like conventional crypto's.
<but_seriously>
Replete with a difficulty.
<but_seriously>
I'll take a look at BitQuest.
<but_seriously>
Thanks.
Ylbam has quit [Quit: Connection closed for inactivity]
<aj>
but_seriously: if you do a game like that that's decentralised you won't be able to avoid people using bots to play it; if you centralise it, it's not really bitcoin-like
<aj>
but_seriously: (IMO; feel free to prove me wrong)
<but_seriously>
Yeah, BitQuest uses bitcoin micropayments as an in game currency, but does not allow you to mine anything that generates new bitcoins.
moa has joined #bitcoin-wizards
<but_seriously>
I don't mind people using bots to play it, if they have to code the behaviour of the bots. A 3d world, like minecraft, is not trivially easy to survive in and difficult to code for. Add to that lava pools and the usual fare and you'r bots are gonna need some good coding.
<but_seriously>
And that's presuming there's now way round the problem you propose...
<but_seriously>
no*
<but_seriously>
It would have to be decentralised though, and that poses it's own problems. Updating the changes other players are making to the map would be tricky to achieve in near real time. As you approach another player on the map you would have to create a secondary P2P link, outside the blockchain/ledger that allows for realtime updates.
<but_seriously>
Complicated, but there's bound to be a way.
<but_seriously>
Obviously if changes are occurring elsewhere on the map, they can take there time to update. If a change has occurred thousands of voxels away and it would take your character 15 mins to travel there, then you don't need to receive those changes for 15 mins.
justanotheruser has quit [Ping timeout: 250 seconds]
<but_seriously>
Actually, it's not to say that the mined ore and subsequent production of crypto's from it wouldn't be something, but just figuring out a way to decentralise minecraft would be the real money spinner.
<but_seriously>
MMMC
<but_seriously>
Massively Multiplayer MineCraft.
<but_seriously>
Anyway... work to do...
but_seriously has quit []
melvster has quit [Quit: Leaving]
justanotheruser has joined #bitcoin-wizards
alex_____ has quit [Remote host closed the connection]
melvster has joined #bitcoin-wizards
Lightsword has quit [Read error: Connection reset by peer]
bendavenport has quit [Quit: bendavenport]
Lightsword has joined #bitcoin-wizards
Jeremy_Rand has quit [Read error: Connection reset by peer]
Jeremy_Rand has joined #bitcoin-wizards
bramc has quit [Quit: This computer has gone to sleep]
Lightsword has quit [Quit: Lightsword]
AaronvanW has quit [Ping timeout: 250 seconds]
alex__ has joined #bitcoin-wizards
alex__ has quit [Ping timeout: 260 seconds]
Lightsword has joined #bitcoin-wizards
calibre720 has joined #bitcoin-wizards
bramc has joined #bitcoin-wizards
wallet42 has joined #bitcoin-wizards
wallet42 has quit [Ping timeout: 250 seconds]
belcher has quit [Quit: Leaving]
wallet42 has joined #bitcoin-wizards
calibre720 has quit [Ping timeout: 260 seconds]
CodeShark_ has joined #bitcoin-wizards
Guest19817239 has joined #bitcoin-wizards
the`doctor has quit [Quit: the`doctor]
roconnor has joined #bitcoin-wizards
<Guest19817239>
Hey everyone, I am taking a course on Bitcoin at uni and have to present on a project soon. Is there anyone who would be willing to discuss some things with me such that I can preempt questions that may be asked?
p15 has joined #bitcoin-wizards
<moa>
Guest19817239: I'll PM you
Jeremy_Rand has quit [Ping timeout: 260 seconds]
p15 has quit [Ping timeout: 260 seconds]
p15 has joined #bitcoin-wizards
Giszmo has quit [Quit: Leaving.]
calibre720 has joined #bitcoin-wizards
bramc has quit [Quit: This computer has gone to sleep]
dEBRUYNE has joined #bitcoin-wizards
lorenzo_ has joined #bitcoin-wizards
dEBRUYNE has quit [Ping timeout: 250 seconds]
lorenzo_ has quit [Client Quit]
CodeShark_ has quit [Ping timeout: 245 seconds]
a5m0 has joined #bitcoin-wizards
erasmospunk has quit [Remote host closed the connection]
wallet421 has joined #bitcoin-wizards
wallet421 has joined #bitcoin-wizards
wallet42 is now known as Guest72270
Guest72270 has quit [Killed (wolfe.freenode.net (Nickname regained by services))]
wallet421 is now known as wallet42
wallet42 has quit [Quit: Leaving.]
the`doctor has joined #bitcoin-wizards
the`doctor has quit [Quit: the`doctor]
jtimon has quit [Ping timeout: 245 seconds]
roconnor has quit [Quit: Konversation terminated!]
sparetire_ has quit [Quit: sparetire_]
CodeShark_ has joined #bitcoin-wizards
rustyn has quit [Read error: Connection reset by peer]
rustyn has joined #bitcoin-wizards
pozitron has joined #bitcoin-wizards
CodeShark_ has quit [Ping timeout: 260 seconds]
rusty has joined #bitcoin-wizards
kang_ has quit [Quit: Page closed]
Guest19817239 has left #bitcoin-wizards [#bitcoin-wizards]
Guest70448 is now known as [Derek]
[Derek] has quit [Changing host]
[Derek] has joined #bitcoin-wizards
calibre720 has quit [Ping timeout: 250 seconds]
matsjj has joined #bitcoin-wizards
matsjj_ has joined #bitcoin-wizards
matsjj has quit [Ping timeout: 250 seconds]
nivah has joined #bitcoin-wizards
ThomasV has joined #bitcoin-wizards
alex_ has joined #bitcoin-wizards
bendavenport has joined #bitcoin-wizards
ebfull has quit [Read error: Connection reset by peer]
ebfull has joined #bitcoin-wizards
calibre720 has joined #bitcoin-wizards
calibre720 has quit [Ping timeout: 260 seconds]
bramc has joined #bitcoin-wizards
p15_ has joined #bitcoin-wizards
p15 has quit [Ping timeout: 250 seconds]
calibre720 has joined #bitcoin-wizards
ThomasV has quit [Ping timeout: 250 seconds]
Jeremy_Rand has joined #bitcoin-wizards
bendavenport has quit [Ping timeout: 265 seconds]
alex_ has quit [Remote host closed the connection]
Jeremy_Rand_ has joined #bitcoin-wizards
Jeremy_Rand has quit [Ping timeout: 250 seconds]
<maaku>
So I've become very interested in seeing if there is a mechanism for user voting on certain security parameters that can be made safe
<maaku>
In particular I'm looking for a solution that is compatible with all the existing infrastructure out there
<maaku>
Which really means there's not much to work with in terms of knobs to tweak .. if you assume that it is wallet authors not users that control e.g. tx.nVersion or nSequence
<maaku>
Has anyone looked at this problem?
calibre720 has quit [Ping timeout: 260 seconds]
bendavenport has joined #bitcoin-wizards
Quanttek has joined #bitcoin-wizards
paveljanik has joined #bitcoin-wizards
paveljanik has joined #bitcoin-wizards
Ylbam has joined #bitcoin-wizards
Quanttek has quit [Ping timeout: 246 seconds]
tripleslash has quit [Ping timeout: 260 seconds]
Jeremy_Rand_ has quit [Ping timeout: 250 seconds]
damethos has joined #bitcoin-wizards
tripleslash has joined #bitcoin-wizards
tripleslash has quit [Ping timeout: 265 seconds]
cinik has quit [Read error: Connection reset by peer]
bendavenport has quit [Quit: bendavenport]
Londe2 has joined #bitcoin-wizards
cinik has joined #bitcoin-wizards
Londe has quit [Ping timeout: 260 seconds]
CodeShark_ has joined #bitcoin-wizards
DougieBot5000 has quit [Quit: Leaving]
ThomasV has joined #bitcoin-wizards
tripleslash has joined #bitcoin-wizards
tulip has quit []
waxwing has quit [Read error: Connection reset by peer]
waxwing has joined #bitcoin-wizards
<petertodd>
maaku: I have, nSequence seems to be the sane thing to do; tricky bit is miner censorship of voting, which means you need jdillon's insight in asymmetric voting
alex_ has joined #bitcoin-wizards
<maaku>
petertodd: the avenue I'd been working off of was to disincentivise censorship by e.g. having the miner's vote determine which transactions can be included
<maaku>
i believe that was actually your work to the mailing list some months back
<maaku>
the thing is I'm wondering if a practical construction can be made which works with e.g. blockchain.info or coinbase wallets
<maaku>
e.g. by having the vote be determined by a bit set in P2PKH and P2SH hashes
<petertodd>
maaku: I can't see how that'd be practical, as that'd conflict with exiting uses of those fields
<petertodd>
maaku: though you could make the argument that at least the distribution of votes in that case would be random, and thus cancel out
alex_ has quit [Ping timeout: 260 seconds]
<maaku>
petertodd: it wouldn't conflict.. maybe i'm not explaining well. if the LSB of a hash is set, it is a vote for, if the LSB is clear it is a vote against
<petertodd>
maaku: the conflict is of intent, not strictly speaking a technical issue
<maaku>
the user has the responsibility of generating an address that votes the way they want, but statistically those who aren't voting just add some unbiased noise
<maaku>
but the problem is base58 .. you can't have an easy, simple rule that a user can go by, e.g. by looking at the leading chars
Guyver2 has joined #bitcoin-wizards
matsjj_ has quit [Ping timeout: 260 seconds]
<petertodd>
yeah, that's a pain
<maaku>
anyway that seems really messy.. maybe there's a cleaner way of doing this
<maaku>
it's annoying many wallets don't support setting extra information e.g. nSequence or tx.nVersion
<petertodd>
well, they can add support for all that pretty easily
<maaku>
petertodd: my adversarial assumption is that the wallet author would rather cast the vote for the user
<petertodd>
maaku: sure, but that's what social media ruckesses are for
<maaku>
I don't want to hand over control of this ballot to a cabal of coinbase, circle, blockchain.info, etc.
<maaku>
true but i'd be more comfortable with a stronger guarantee
<maaku>
at least the address thing the wallet author can't muck with without redirecting / destroying your coins
joesmoe has joined #bitcoin-wizards
matsjj has joined #bitcoin-wizards
<maaku>
hrm. using the checksum byte (last char of address) is maybe the cleanest (relatively speaking) way to do that
<petertodd>
maaku: what makes you think the likes of coinbase, circle, etc. wouldn't just limit what addresses your wallet can generate?
<maaku>
gah this is also true
<maaku>
although less so for HD wallets
<petertodd>
maaku: HD can be brute-forced
<petertodd>
maaku: also, now we have to change HD infrastructure that expected you to be able to generate addresses from child chians
matsjj_ has joined #bitcoin-wizards
bramc has quit [Quit: This computer has gone to sleep]
matsjj has quit [Ping timeout: 260 seconds]
<maaku>
hrm. other bits to play with: LSB of fee (not bias-free, unfortunately)
<maaku>
petertodd: where would you have stuck this? nSequence?
pozitron has quit [Ping timeout: 260 seconds]
<petertodd>
maaku: yes, nSequence, that's why I asked for the nSequence soft-forks to reserve some bits for future use
<gmaxwell>
did we both independantly ask for that?
<petertodd>
gmaxwell: probably!
Graet has joined #bitcoin-wizards
<maaku>
i believe so
rubensayshi has joined #bitcoin-wizards
matsjj has joined #bitcoin-wizards
Graet is now known as Guest21417
matsjj_ has quit [Ping timeout: 250 seconds]
dEBRUYNE has joined #bitcoin-wizards
<maaku>
petertodd: have you written any code for this?
Guest21417 is now known as Graet
Graet is now known as Guest78012
<maaku>
actually n/m just thought of a simpler way to do it. should be pretty straightforward
<maaku>
you could even check a vote in CSV if you wanted to ensure it as part of a contract
<Taek>
maaku: what is the end goal with the user voting? I imagine it would be easy to manipulate via Sybils, etc.
<maaku>
up/down vote on security parameter which indirectly regulates block size, weighted by coin days destroyed
<gmaxwell>
maaku: I have an extra constraint, which maybe would make it easier, you'd want your voting scheme to at least have compact fraud proofs for the results.
<maaku>
i'm not sure it makes it easier, but it's simple enough to do with a merkle sum tree commitment
<maaku>
Taek: the coin-days-destroyed weighting should make this sybil-reistant
<Taek>
maaku: is the user the best person to be voting on security parameters? You might get mob-effects.
<Taek>
I do agree that coin-days-destroyed is probably a reasonable route to sybil resistance
<maaku>
Taek: if the users weighted by coin-days can't be sensible we're fucked anyway
<maaku>
but it's part of a larger proposal to make block "size" regulated by paid-for user demand rather than a fixed schedule or miner vote
<maaku>
note it is explicitly, purposefully not democratic. more bitcoins = more votes, more age on those coins = more vote
<Taek>
another problem, as bitcoin grows corporations are likely to start owning much larger sums of bitcoin than other users
<Taek>
maybe not a problem, just an observation rather
<maaku>
right
<maaku>
i'm worrying about custodians voting on behalf of the coins rightful owners
<maaku>
not so worried about large coin holders owning the vote. that's rather the goal
Yoghur114 has joined #bitcoin-wizards
* Taek
wonders if something like this would create a marketplace for coin-days-destroyed
Yoghur114 has quit [Remote host closed the connection]
<Taek>
"Tunable consensus parameters via voting based on long term coin ownership."
<Taek>
That's a research paper I'd probably read
tulip has joined #bitcoin-wizards
sparetire_ has joined #bitcoin-wizards
<stonecoldpat>
I don't think coin age may be the greatest metric to use... it would give advantage to people who invest in the currency, as opposed to those who use it on a regular basis?
<Taek>
I was thinking something similar. Especially because you can spend $3 and use up an output that's got way more coin-days
ThomasV has quit [Ping timeout: 260 seconds]
<Taek>
it's yet another optimization that wallet writers have to worry aobut
<gmaxwell>
it's not about the "metric" it's about preventing people from double voting by bouncing coins around, but not depriving the next owner of a coin from participating and making coins non-fungible.
<Taek>
gmaxwell: I don't grok. If you choose to use coin days destroyed as the method for weighting votes, you favor people with habits that accumulate coin-days destroyed (long term speculators), and isolate others (ie merchants that don't hold large coin reserves)
<tulip>
large shared wallets will also have cold wallets with very high days destroyed.
c-cex-finch has joined #bitcoin-wizards
<gmaxwell>
taek: it's not a question of "people" it's about bitcoin. CDD gives all bitcoin ownership equal weight in an ongoing measurement.
<gmaxwell>
it doesn't have anything to do with how much you transact... if you transact often you make many transactions with low weight and have the same influence as if you transacted infrequently.
<gmaxwell>
Each bitcoin owned is one foo millionth of the influence regardless of how often you transact. (and sure it should probably not count days before the scheme starts, but thats a implementation detail mostly.)
<Taek>
gmaxwell: to me, it's about the ecosystem. I have not analyzed carefully, but I think that there would be a poor mapping between CDD ownership and ecosystem-relevance
<gmaxwell>
It does bias control towards parties that hold more bitcoin; but that seems inescable in a decenteralized system.
<gmaxwell>
Taek: the mapping is 1:1 with coin ownership.
<Taek>
it may be inescapable
<Taek>
gmaxwell: right, but merchants may have a high level of importance without having much ownership.
<Taek>
especially if their business model optimizes for low variance -> minimal ownership
<gmaxwell>
Every bitcoin then is a 'voting share' in control of the parameter; it could be argued to be more socially just another way; but there is a logically consistent moral argument for this approach: Who owns bitcoin? The owners of Bitcoin.
<gmaxwell>
Taek: then there is an additional factor in their decision, I guess.
<Taek>
It does have this nice property of 'put your money where your mouth is'
<gmaxwell>
(I can also argue this other ways but I think this approach has a uniquely good property of being realizable.; schemes that give weight to future or prospective bitcoin users-- for example-- do not. Schemes that counter people, are not, .. etc)
<gmaxwell>
er count people*
<Taek>
CDD is wonderfully simple.
frankenmint has joined #bitcoin-wizards
<gmaxwell>
Taek: My bigger concern with those things is payment processors that would get huge weight by default and perhaps not have really much alignment with bitcoin long term (including because the coin isn't really theirs) ... but one can only go so far.
<Taek>
I think it's really just an extension of the huge weight that they already have. And, it might be good motivation for users to actually move their coins to their own control, since there's tangible political power associated with keeping your coins to yourself.
lmatteis has joined #bitcoin-wizards
<gmaxwell>
taek: doubtful, (the threat of them being stolen should be enough) -- but sometimes you have to just say "this is a failure mode, and not a bad one all considered. If this is the way the system dies, I can come to terms with that."
<Taek>
(failure mode in general, or just with regards to CDD voting?)
<gmaxwell>
I think CDD voting, at least the kind that avoid the vote censorship problems, failure modes are ones I can cope with. If the people with control of some supermajority bitcoins want to dump the system into a lake; what can I really say?
roxtrongo has quit [Remote host closed the connection]
<Taek>
"I told you so"
<gmaxwell>
yea, indeed. I mean; it's not ideal: better one person shouldn't have power over another at all... but if there must be common choice, and the forced part is reduced to the minimum possible...
ThomasV has joined #bitcoin-wizards
<Taek>
There's definitely value to accepting that there's only so much you can do.
<Taek>
I think CDD voting merits more exploration
atgreen__ has joined #bitcoin-wizards
atgreen_ has joined #bitcoin-wizards
<Taek>
prediction markets have enormous power to bring forward information, routinely being more accurate than any other method for figuring stuff out. (ie expert panels)
<Taek>
and I think the generally accepted reason for their power is that there is financial cost to being wrong, and fiancial gain from leveraging knowledge
<gmaxwell>
prediction markets used for decisions though... they get called decision markets in the lit, and its full of reasons they don't work; I prefer to call them "all pay auctions"
<gmaxwell>
or "dollar auction"
<Taek>
gmaxwell: can you link to literature on decision markets?
<gmaxwell>
it's googlable, I'd have to go dig around a bit to find again the papers I found most interesting.
<gmaxwell>
I basically summed up the most signficant criticism of them; it's very easy for them to become dollar auctions.
alex__ has quit [Remote host closed the connection]
dEBRUYNE has quit [Ping timeout: 260 seconds]
Aesthetic has joined #bitcoin-wizards
Aesthetic is now known as Logicwax
alex__ has joined #bitcoin-wizards
malte has joined #bitcoin-wizards
CoinMuncher has quit [Quit: Leaving.]
adam3us has joined #bitcoin-wizards
Yoghur114 has joined #bitcoin-wizards
Logicwax has quit [Read error: Connection reset by peer]
nivah has joined #bitcoin-wizards
Logicwax has joined #bitcoin-wizards
prosody has quit [Remote host closed the connection]
nivah has quit [Ping timeout: 260 seconds]
<bsm117532>
The incentive formula I have for a DAG incentivizes fast block transmission, and will force us to optimize p2p relay of blocks...
<bsm117532>
kanzure: I've said it before but we're going to be talking at Scaling about faster underlayers for bitcion blocks, and I think the thinking will converge (to a DAG. ;-)
<bsm117532>
I do think that block relay should occur after verifying PoW but before verifying the rest...
<bsm117532>
Because verifying PoW is enough to discourage any kind of block spam attack.
nabu has joined #bitcoin-wizards
GAit has quit [Quit: Leaving.]
zookolaptop has quit [Ping timeout: 260 seconds]
zwick has quit [Quit: WeeChat 1.0.1]
<kanzure>
do weak blocks eliminate the effect of block size on orphan rates?
<kanzure>
a miner's competitor's orphan rate is reduced by the competitor publishing weak blocks that others accept/validate/propagate, which presumably can make up for the competitor's lower bandwidth or lower connectivity for pushing out their blocks to a sufficient hashrate-wielding portion of the network.
<kanzure>
but larger miners can just flood and saturate the network with larger weak blocks anyway, reducing available bandwidth to handle smaller miner low-bandwidth smaller weak blocks.
<kanzure>
you could use dynamic-adjustment flexcap proposal stuff to enforce a preference for smaller weak blocks, but if you prefer smaller weak blocks then a larger miner can simply produce more smaller weak blocks
cocoBTC has joined #bitcoin-wizards
<kanzure>
s/produce more smaller weak blocks/produce more (as in additional/extra numerous) smaller weak blocks
<kanzure>
in http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-November/011707.html taek talks about the adversarial case for high-bandwidth larger miner propagation of big blocks with possibly pathological validation (or just big blocks, whatever), but no mention of big weak blocks as pushing out small weak blocks and thus big block miners winning out over small block miners even in the weak block rac.e
<gmaxwell>
The elimination is only obviously true absent strageic behavior. If a large miner intentionally doesn't go along with the scheme, the effect comes back and it's in their favor.
a5m0 has joined #bitcoin-wizards
<gmaxwell>
But this is intutive handwave, I'm not actually sure how that breaks down with any particular weak block scheme.
<kanzure>
"The orphan rate for weak blocks is going to be substantially higher for smaller miner, due to the increased rate of appearance. I do not think that this is going to create any issues, because small miners are still going to have high visibility of the longest weak-block chain, and are still going to be able to create blocks that are nearly as full as the blocks created by larger miners."
<kanzure>
i think this quote might have accidentally flipped the concerns regarding orphan rates, but not sure.. still thinking.
<bsm117532>
One thing I'm excluding from my talk: my DAG construction can allow each node to choose an incoming difficulty that they will accept. Separate from that one can have miners "bundle" blocks into a higher work block.
<bsm117532>
However all you're really saving is PoW headers, maybe a factor of 2 in bandwidth at most. There's a natural max (weak/DAG) block rate and that's the transaction rate. Don't send PoW blocks with no transactions.
GAit has quit [Read error: Connection reset by peer]
GAit has joined #bitcoin-wizards
<kanzure>
i think that if the weak blocks are too large, then not only do you have to worry about smaller miner weak block orphan rate, but you also have to worry about smaller miner ability to get the big weak blocks. i think that the size of blocks and the size of weak blocks is going to have some proportional relationship. (just a guess)
<gmaxwell>
kanzure: my assumption was always that the weak blocks themselves were sent relative to other weak blocks and using contextual compresison or set reconcilliation.
<kanzure>
big weak blocks don't help smaller miners if the smaller miners are unable to download all the big weak blocks. iirc initial propagation of low-bandwidth smaller miner big blocks is also going to effect download of big weak blocks and big blocks by smaller miners..... as long as the smaller miners are validating (sigh).
<kanzure>
er, by which i mean to say, just as initial propagation, by smaller miners of their own big blocks, can effect their orphan rate in a big block world, the same can be said for a network with big weak blocks that they are unable to download quickly enough (it's similar to the reasons why smaller miners had initial propagation problems for their big blocks).
erasmospunk has quit [Remote host closed the connection]
<bsm117532>
BTW, do weak blocks contain transactions? Or only the leaves for the Merkle tree?
dEBRUYNE has joined #bitcoin-wizards
<bsm117532>
I still wonder why Bitcoin blocks contain transactions...why not exclude them since they can be obtained by p2p?
<kanzure>
and not to beat a dead horse, but to make my other statement more clear regarding relationship of weak block size to block size, the received weak blocks ideally have to encode all of the transactions that are going to be appearing in the big block later, so the number of weak blocks times the weak block size will determine the amount of data that has to be downloaded by the smaller miner, in a world with big blocks and weak blocks ...
<kanzure>
... (possibly a world with big blocks and big weak blocks).
<sipa>
bsm117532: latency
<kanzure>
doesn't matter, at some point the transactions have to be sent. it's true that the block headers can be propagated far more quickly, but the transactions still have to be sent and validation still has to happen at some point.
robmyers has joined #bitcoin-wizards
<kanzure>
plus, you don't want vulnerabilities regarding network propagation of unvalidated block announcements because yikes
<kanzure>
(flooding, bandwidth competition, etc)
<sipa>
there are certai ly more efficient encodings possible, but you can only validate the block with whole blocks
<bsm117532>
sipa: latency to verify the block? Because it will take me longer to retrieve missing transactions? It wouldn't be so bad if we relayed the header before verifying.
<sipa>
bsm117532: block withholding attacks
<sipa>
you don't want a miner to withhold the tx data from the network, and have the network build on top
<bsm117532>
Yeah I'm going to bury that horse. There's no block withholding attack in my DAG.
<sipa>
ok, curious about that
<bsm117532>
No one would mine on top of a block they can't verify...
<kanzure>
isn't that what we said about uh..
<bsm117532>
you eliminate orphans, you eliminate block withholding. Also I've explicitly made a block reward which incentivizes fast transmission.
roxtrongo has joined #bitcoin-wizards
damethos has quit [Quit: Bye]
jbenet has quit [Remote host closed the connection]
<kanzure>
the origin of orphan rate is lack of bandwidth so seems intuitively hard to imagine that somehow transitioning from "small miners have problems uploading big blocks" to "small miners have problems downloading lots of (possibly big) weak blocks" will somehow fix lack of bandwidth
<bsm117532>
The origin of orphans is one of the 8 fallacies of distributed computing.
<bsm117532>
It's is simply impossible for causally disconnected miners to have synchronicity.
<bsm117532>
I've converted orphans to "siblings" in a DAG. BOTH miners get a fair share, and their work is proportional to their difficulty.
<bsm117532>
A "sibling" is a block that cannot be ordered to come before or after mine using the DAG's partial order.
gielbier has joined #bitcoin-wizards
gielbier has quit [Changing host]
gielbier has joined #bitcoin-wizards
<bsm117532>
*their reward is proportional to difficult. (not work...)
Jeremy_Rand_ has joined #bitcoin-wizards
GGuyZ has quit [Quit: GGuyZ]
<kanzure>
(big) weak block propagation is subjected to same effects as big block propagation, so will probably use speedups like IBLT etc. etc... in which case small miner bandwidth/download problem goes away for those (big) weak blocks. but if transaction rate goes above available bandwidth anyway, you are still not going to be able to see everything.
rustyn has joined #bitcoin-wizards
<bsm117532>
Scaling bitcoin means scaling bandwidth. There's no way around that.
<kanzure>
transaction cut through works without "scaling bandwidth".
waxwing has quit [Read error: Connection reset by peer]
<bsm117532>
Also makes bitcoin less useful. Yes we could stay with 1MB block sizes and do nothing...
<kanzure>
why is that perceived as doing nothing and less useful?
waxwing has joined #bitcoin-wizards
<bsm117532>
I thought there was consensus on growing to higher transaction rates?
<bsm117532>
If not, I'll make an altcoin for it. :-P
<kanzure>
that doesn't answer my question
<kanzure>
transaction cut through can have insanely high transaction rate. i gave you an example of non-bandwidth scaling. your retort was that it's "doing nothing and less useful".
<bsm117532>
I don't know what "transaction cut through" means.
<kanzure>
lightning is not a good way to describe the superset of.. this stuff.
<bsm117532>
Perhaps not...
<kanzure>
((yesterday i wrote what i consider to be a good comment that points out that for payment channels the idea of lightning and other methods is to add constraints around the possible behavior for zero-conf transactions. hopefully this helps as far as perspective about zero-conf but who the hell knows.))
<rusty2>
kanzure: weak blocks can also be thought of as spreading the load, "pre-sending" blocks and then finishing it at the last minute. Depends whether constraint is total bw or block transmission latency.
rusty2 is now known as rusty
<bsm117532>
Lightning is an answer to zero-conf, AFAICT.
jlyndon has quit [Write error: Connection reset by peer]
<kanzure>
yes i had briefly considered that more temporally-consistent load during the periods between block finding might be helpful, but not sure whether that is enough to say eliminates orphan rate effect of big blocks
<bsm117532>
Let's make the orphan rate zero.
<kanzure>
bsm117532: there's so many ways to scale bitcoin without sacrificing bandwidth that i'm not convinced that doing both is necessary
<bsm117532>
Rather than arguing about how large is too large.
<kanzure>
bsm117532: you just got done saying it's impossible to have zero orphan rate, you know :)
<bsm117532>
Lightning is only a way to scale bandwidth if you don't count the bandwidth of lightning itself.
<kanzure>
i did not claim that lightning stuff scales bandwidth
<bsm117532>
kanzure: I didn't say that! It's impossible in Bitcoin. ;-)
<kanzure>
lightning bandwidth stuff is unrelated to bitcoin bandwidth requirements, as far as i know
<bsm117532>
Argh fingers.
<bsm117532>
Lightning is only a way to scale *bitcoin* without scaling bandwidth if you don't count the bandwidth of lighting itself.
Jeremy_Rand__ has joined #bitcoin-wizards
<kanzure>
why should i count lightning bandwidth?
<bsm117532>
Why not? What are you interested in?
<kanzure>
i could see an argument for counting lightning bandwidth when everything gets dumped to bitcoin in the event of a tremendous catastrophe, but dunno
<kanzure>
*gets dumped to bitcoin blockchain
Jeremy_Rand_ has quit [Ping timeout: 260 seconds]
roxtrongo has quit [Remote host closed the connection]
<kanzure>
we should probably just stop talking about lightning and instead mention zero-confirmation transactions that are collectively linked to anchoring confirmed commitment transactions, might make it easier on the zero-conf people to understand abilities to restrict previously-undefined behavior of zero-conf transactions.
kumavis has quit [Write error: Connection reset by peer]
c-cex-yuriy has quit [Remote host closed the connection]
erasmospunk has joined #bitcoin-wizards
melvster has quit [Quit: Leaving]
<kanzure>
bsm117532: btw i still consider my question "why is that perceived as doing nothing and less useful?" as unanswered. i have also successfully refuted your "scaling bitcoin means scaling bandwidth" claim.
<bsm117532>
I'm using lighting as a synonym for what you wrote. I haven't seen other proposals than lightning itself.
<bsm117532>
kanzure: Transaction volume *will* go up. Bitcoin has a number of arbitrary, artificial limits. What's the point of those limits? I seek to remove them.
<kanzure>
stroem, atomic swaps, bluematt's micropayment channel stuff in bitcoinj, thunder network (matsjj), amiko pay, lots of other payment channel designs have been proposed in the past (probably a few by tiernolan that i can't remember)
<kanzure>
bsm117532: perhaps you should seek first to understand heh
<bsm117532>
kanzure: let me reverse the question: what's the benefit of keeping transaction volume low?
<kanzure>
smaller miners
<kanzure>
we just had this conversation yo
<kanzure>
but also, i showed that you can offload transaction volume without impacting bitcoin blockchain bandwidth requirements
<kanzure>
(while still using bitcoin transaction data structures)
<kanzure>
((or at least the necessary pieces? w/e))
jbenet has joined #bitcoin-wizards
<bsm117532>
yo. ;-)
<kanzure>
yea keeping it real
<bsm117532>
what do you mean "smaller miners"?
<bsm117532>
Let me show you how to get rid of pools with a DAG...
<kanzure>
what was the point of reversing the question? i can only assume that you expected that my answer would help me understand why you perceive scaling bitcoin in a non-bandwidth capacity to be "doing nothing and less useful", but i have to admit, my answer does not help me see how you could believe that.
jlyndon has joined #bitcoin-wizards
<bsm117532>
What you call "cut-through" is a damn good idea and needs to be done. Perhaps you wouldn't call my work "scaling" then. Rather it's miner decentralization, orphan elimination, and smoothing the income distribution for miners. (And it comes with the possibility that the tx rate is proportional to bandwidth and CPU alone, free of artificial restrictions)
kumavis has joined #bitcoin-wizards
SheffieldCrypto has joined #bitcoin-wizards
<kanzure>
btw for clarity about zero-conf stuff: bandwidth requirements for passing zero-conf transactions around can be entirely out-of-band of blockchain transaction propagation and blockchain block propagation. there can be far more zero-conf transactions that exist that will never be using the bitcoin blockchain bandwidth. so the bandwidth should not be counted. i gave a specific example of where the bandwidth of offloaded zero-conf ...
<kanzure>
... transactions should be considered, namely in protocols like lightning when many many transactions get dumped to the blockchain due to unfortunate systemic risk regarding misbehaving parties. but lots of tools can be built to help try to mutually resolve those problems in a timely manner that nobody has explored yet (to my knowledge). not worried about that really. (or, instead of tools for after the event has occurred, you could ...
<kanzure>
... have tools that check the systemic risk prior to any catastrophic event too. but same as the other, i don't think anyone has proposed this yet.)
<instagibbs>
bsm117532, (trying to be nice) stop insinuating you've solved decentralized distributed ledgers and write up a technical whitepaper that relates it to the previous DAG attempts.
<instagibbs>
that is to say, write up your idea. Not the first DAG idea, and most will simply ignore unless you do the work.
<bsm117532>
instagibbs: I have. I am.
<instagibbs>
great!
runeks has joined #bitcoin-wizards
<bsm117532>
Sitting at 14 pages right now. Doing some simulations.
<kanzure>
er, to further clarify my previous comment, zero-conf transactions can still be relayed over the bitcoin blockchain for when they are intended to get into the blockchain, but parties can easily transact with each other in a way where they agree not to transmit the zero-conf transactions over the p2p bitcoin network. as you increase the number of parties privy to your individual zero-conf transaction, you of course increase the risk ...
<kanzure>
... that someone is going to dump it on the blockchain because they are poopheads.
alex__ has quit [Remote host closed the connection]
<instagibbs>
then until then don't expect people to believe you, especially when you call real-world limitations artificial, with respect to Bitcoin at least
<bsm117532>
instagibbs: FWIW this isn't my first rodeo. I've got 30+ academic papers. I don't expect anyone to believe me. This whole IRC thing is weird.
<kanzure>
irc is definitely weird and full of butts
<instagibbs>
you're the millionth person on wizards with a FANTASTIC idea. Not the first DAG one either :P
<bsm117532>
instagibbs: I'm well aware. ;-)
<instagibbs>
so yeah, I hope you're right, but like, yeah
<instagibbs>
;)
<kanzure>
so was that transaction rate proportional to global net average bandwidth, or was that proportional to local per-node bandwidth in the same sense as sharding schemes?
<instagibbs>
In the end you'd still be bounded by bandwidth to participate, I assume. Which means there still are "artificial" limitations.
<bsm117532>
global. You don't get local without sharding.
<bsm117532>
instagibbs: 10 minutes is more artificial than global bandwidth (which can be optimized/upgraded)
<kanzure>
so you mean global bandwidth assumptions or do you mean actual global bandwidth? and why would a 100 kilobyte/sec miner not count as global bandwidth?
artifexd has joined #bitcoin-wizards
<bsm117532>
Each miner needs to able to suck down the entire blockchain, right? That's the limit...
<kanzure>
for new nodes? yes
<bsm117532>
And technically with 3tps we're at like 3kbps, which is nothing...
<kanzure>
*for new miner nodes? yes
Jeremy_Rand__ has quit [Ping timeout: 260 seconds]
<kanzure>
yes but you still have to say whether you are making assumption about new miner bandwidth requirements, or if you are somehow measuring actual new miner bandwidth. and also, existing miner bandwidth matters somehow.
mappum has joined #bitcoin-wizards
mikolalysenko has joined #bitcoin-wizards
<kanzure>
oops sorry i don't mean requirements
<bsm117532>
It's the required synchronicity of adding a node to a linked list that causes all the problems. It requires locking for multiple writers, and we have no locking. Another model is to allow non-conflicting simultaneous writes. That's what you get with a DAG.
<kanzure>
it's true that a new miner has to download the entire blockchain. however, existing miners do not. they only have to keep up with the blockchain. and the limit to "keeping up" is... tada, bandwidth.
<bsm117532>
kanzure: I'm referring to the steady state (already have blockchain) bandwidth.
mably has joined #bitcoin-wizards
<bsm117532>
If we just had smaller, faster blocks, we could divide the 1MB blocks into 3kbps, and everyone has that much. further scaling of transaction rate is then proportional to the bandwidth.
<kanzure>
why was i talking about "keeping up"? wasn't i supposed to be talking about miners? i'm not convinced that i am listening to myself at the moment.
* kanzure
wanders off
bassguitarman has joined #bitcoin-wizards
damethos has joined #bitcoin-wizards
matsjj has quit [Remote host closed the connection]
PsychoticBoy has joined #bitcoin-wizards
GGuyZ has joined #bitcoin-wizards
wpalczynski has joined #bitcoin-wizards
melvster has joined #bitcoin-wizards
melvster has quit [Remote host closed the connection]
Luke-Jr has quit [Read error: Connection reset by peer]
GAit has quit [Quit: Leaving.]
Luke-Jr has joined #bitcoin-wizards
adams__ has joined #bitcoin-wizards
adam3us has quit [Quit: Leaving.]
c-cex-yuriy has joined #bitcoin-wizards
GAit has joined #bitcoin-wizards
melvster has joined #bitcoin-wizards
Jeremy_Rand__ has joined #bitcoin-wizards
GGuyZ_ has joined #bitcoin-wizards
lomax__ has joined #bitcoin-wizards
GGuyZ_ has quit [Read error: Connection reset by peer]
GGuyZ__ has joined #bitcoin-wizards
roxtrongo has joined #bitcoin-wizards
GGuyZ__ has quit [Read error: Connection reset by peer]
adam3us has joined #bitcoin-wizards
GGuyZ has quit [Ping timeout: 260 seconds]
GGuyZ has joined #bitcoin-wizards
melvster has quit [Quit: Leaving]
<bramc>
Here's a depressing thought: Let's say that China passed laws including a list of 'bad' utxos, and had a policy that all miners in china needed to attempt to orphan any block which included a transaction which included a descendant of one of those for a block or two. If the list was public, then other miners would have incentive to orphan those blocks as well, which would lead to other miners having a yet even stronger i
<bramc>
ncentive, until it became a de facto soft fork that those utxos were unspendable.
catcow has joined #bitcoin-wizards
alex__ has joined #bitcoin-wizards
<kanzure>
i think that's another way of saying it's important to have lots of mining that is smaller than the level where it becomes necessary to operate as a business entity
<kanzure>
by mining i mean fully-validating mining
<bsm117532>
Down with pools! They're full of pee anyway.
GGuyZ has quit [Read error: Connection reset by peer]
<kanzure>
also it is interesting to point out the differences between business broadband pricing vs consumer/residential bandwidth pricing in most areas. for the longest time i have seen bizarre workshops (like machine shops) totally skip on internet connectivity, but only recently realized that it's probably because of the insane prices...
GGuyZ has joined #bitcoin-wizards
<aj>
the above would make it illegal to SPV mine, at least on top of any blocks that might mine blocks spending those verboted UTXOs...
<bramc>
aj None of the big miners in china are spv mining
<bsm117532>
We need some kind of "proof of validation". There's no reason we shouldn't take measures to force them to stop mining, or to do full validation.
GGuyZ has joined #bitcoin-wizards
<instagibbs>
soft-fork in a recursive snark proof. simple!
<kanzure>
bramc: i dunno where this was mentioned but gmaxwell might have had at some point a method for discouraging transaction censorship
<bsm117532>
instagibbs is snarky today. ;-)
roxtrongo has quit [Remote host closed the connection]
<instagibbs>
im also containing zero knowledge
<bsm117532>
Hahaa
justice has joined #bitcoin-wizards
rustyn has quit [Read error: Connection reset by peer]
<instagibbs>
seriously though, I think that'd be the answer to your question: proof of faithful computation
Jeremy_Rand__ has quit [Quit: Konversation terminated!]
<bsm117532>
It is the answer. It's also computationally intractible.
rustyn has joined #bitcoin-wizards
<kanzure>
would be interesting to see if non-profit-motivated small mining is sustainable (e.g. miners not in a race to get as huge as possible compared to their competitors)
<kanzure>
i think the argument was that if you are not getting any of the blocks then why bother mining? something about orphan rate increase due to size of competitor's big blocks.
<kanzure>
not sure how that argument goes
<bsm117532>
Nothing to do with large blocks, just to do with large block rewards. If my expectation is that I'll get one block per year, I'm not going to bother. We need smaller rewards.
<kanzure>
why are you not going to bother?
<bsm117532>
Push it to 10 years. At some point no one will bother.
<bsm117532>
If my income was 25BTC/year, but I don't know when I'm going to get it...you can't plan expenses around that unless you subsidize the operation...
melvster has joined #bitcoin-wizards
<kanzure>
if the operaton is subsidized (with small enough mining, that's trivially doable), my question was why would you not bother if low reward rate?
<bsm117532>
At that point you're not doing it for the money...
Jeremy_Rand__ has joined #bitcoin-wizards
Jeremy_Rand__ is now known as Jeremy_Rand
Jeremy_Rand has quit [Client Quit]
<bsm117532>
You asked if "non-profit-motivated small mining is sustainable" -- i guess I'm interpreting that as making a profit. ;-)
Jeremy_Rand has joined #bitcoin-wizards
<kanzure>
well i guess the question is really asking about the sustainability of whatever the other motivations are, heh
<kanzure>
or, rather, if the subsidy is sufficient to keep up with linear blockchain growth
<bsm117532>
Which is really asking how much money are people willing to throw away on a hobby?
<kanzure>
actually no, i mean presumably it should be possible to stick more towards the lower end of that rather than how much they would at most be willing to "throw away"
<bsm117532>
Heh we have a couple mining rigs in the office, because our office lease includes free electricity! (just for demonstration, really) But we have to mine on a pool, so not validating. :-(
<kanzure>
you mean your example is only a demonstration, or the rig was real and the reason was for in-office demos?
erasmospunk has quit [Remote host closed the connection]
erasmospunk has joined #bitcoin-wizards
<kanzure>
hashrate consolidation even in absence of pools would be almost samely problematic, i think
adam3us has quit [Quit: Leaving.]
bitcoin-wizards6 has joined #bitcoin-wizards
alex__ has quit [Remote host closed the connection]
alex__ has joined #bitcoin-wizards
alex__ has quit [Remote host closed the connection]
alex__ has joined #bitcoin-wizards
a5m0 has quit [Ping timeout: 245 seconds]
bitcoin-wizards6 has quit [Ping timeout: 252 seconds]
simba has joined #bitcoin-wizards
Lightsword_ has joined #bitcoin-wizards
damethos has quit [Quit: Bye]
SwedFTP has joined #bitcoin-wizards
Lightsword has quit [Ping timeout: 260 seconds]
Lightsword_ is now known as Lightsword
frankenmint has joined #bitcoin-wizards
melvster has quit [Quit: Leaving]
frankenmint has quit [Ping timeout: 246 seconds]
DougieBot5000 has joined #bitcoin-wizards
frankenmint has joined #bitcoin-wizards
zookolaptop has joined #bitcoin-wizards
notj_ has joined #bitcoin-wizards
adam3us has joined #bitcoin-wizards
adam3us has quit [Client Quit]
a5m0 has joined #bitcoin-wizards
Jeremy_Rand_ has joined #bitcoin-wizards
damethos has joined #bitcoin-wizards
notj_ has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
Jeremy_Rand has quit [Ping timeout: 250 seconds]
adam3us has joined #bitcoin-wizards
damethos has quit [Quit: Bye]
Ylbam has joined #bitcoin-wizards
adam3us has quit [Client Quit]
notj_ has joined #bitcoin-wizards
notj_ has quit [Client Quit]
nabu has quit [Ping timeout: 260 seconds]
nabu has joined #bitcoin-wizards
Jeremy_Rand_ has quit [Ping timeout: 246 seconds]
Jeremy_Rand__ has joined #bitcoin-wizards
copumpkin has joined #bitcoin-wizards
notj has joined #bitcoin-wizards
fkhan has quit [Ping timeout: 245 seconds]
Guyver2 has quit [Quit: :)]
notj has quit [Client Quit]
Jeremy_Rand__ has quit [Ping timeout: 260 seconds]
notj has joined #bitcoin-wizards
zookolaptop has quit [Ping timeout: 250 seconds]
notj has quit [Client Quit]
notj has joined #bitcoin-wizards
bramc has quit [Quit: This computer has gone to sleep]
<kanzure>
re: "block propagation time is already irrelevant because of the existence of spv mining activity". no, block propagation was about the competitor's orphan rate.
cocoBTC has quit [Quit: Leaving]
fkhan has joined #bitcoin-wizards
fkhan has quit [Changing host]
fkhan has joined #bitcoin-wizards
notj has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
c-cex-yuriy has quit [Quit: Connection closed for inactivity]
notj has joined #bitcoin-wizards
ThomasV has quit [Ping timeout: 260 seconds]
notj has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
notj has joined #bitcoin-wizards
melvster has joined #bitcoin-wizards
zookolaptop has joined #bitcoin-wizards
mably has quit [Ping timeout: 260 seconds]
GAit has quit [Quit: Leaving.]
dEBRUYNE has quit [Read error: Connection reset by peer]
notj has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
<el33th4x0r>
so funny to see people think that selfish mining was debunked.
<kanzure>
yeah i think the argument he might be thinking of is "miners wont behave in a way that breaks the network, because then their BTC becomes worthless" but miners can easily not care about BTC, and we should not dramatically reduce barriers for attacks
<el33th4x0r>
i thought that argument had been debunked. :-)
<kanzure>
i have no idea, i sort of lost track.
<el33th4x0r>
every argument that begins "no one would do that, because [in my model and according to my limited understanding where I project my goals onto others] it would not be in their rational self-interest" is flawed.
<el33th4x0r>
more seriously though, I think he is pointing out that slow propagation of blocks is in some way akin to a block withholding attack.
<kanzure>
well he's certainly not being lucid about that point
<el33th4x0r>
well, take large miner, say >33%. if his blocks are taking a while to propagate to the network, he is, in essence, launching an unintentional SM attack.
<kanzure>
"The effect of slower propagation on mining is not punishing the party "with" slow propagation. "With" implies a privileged reference frame. From the point of view of a miner behind a tin-can-and-string link, it's the world that has slow connectivity."
<el33th4x0r>
right, you were right on the dot with that.
<kanzure>
(note: that was gmaxwell not me)
hsmiths__ has joined #bitcoin-wizards
<el33th4x0r>
ok gmaxwell was right. And the other fellow's bringing up SM is apropos, because to the rest of the world, it looks like the miner is selfish mining, because he is holding his blocks back from the rest of the network.
<kanzure>
trying to visualize a bitcoin mining network graph with all of the bandwidth asymmetries represented, hard to visualize but i think they might be edge weights or something that count higher over time
<kanzure>
er i guess you also have to visualize hashrate consolidation over time on same graph structure, so nevermind. not gonna try that one.
go1111111 has joined #bitcoin-wizards
<kanzure>
not sure what to do about resemblance to selfish mining, if anything that sounds like his argument is "miners wont buy mega-awesome bandwidth and connectivity, because they will be basically performing a selfish-mining attack"?
<kanzure>
the orphan rate stuff was re: increasingly big blocks, so maybe his argument was "larger miners won't both buy mega-awesome bandwidth and also won't be sending over increasingly big blocks, because that would be essentially similar to selfish mining"