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
MaxSan_ has quit [Ping timeout: 240 seconds]
Guyver2 has quit [Quit: :)]
igotcompetence has joined #bitcoin-wizards
igotcompetence has quit [Max SendQ exceeded]
igotcompetence has joined #bitcoin-wizards
belcher has quit [Read error: Connection reset by peer]
belcher has joined #bitcoin-wizards
MaxSan_ has joined #bitcoin-wizards
rusty2 has joined #bitcoin-wizards
Chris_Stewart_5 has joined #bitcoin-wizards
hashtagg has joined #bitcoin-wizards
hashtag has joined #bitcoin-wizards
hashtagg_ has quit [Ping timeout: 246 seconds]
hashtag_ has quit [Ping timeout: 240 seconds]
Ylbam has quit [Quit: Connection closed for inactivity]
copumpkin has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
igotcompetence has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
N0S4A2 has quit [Quit: WeeChat 1.5]
copumpkin has joined #bitcoin-wizards
Chris_Stewart_5 has quit [Ping timeout: 276 seconds]
MaxSan_ has quit [Ping timeout: 264 seconds]
tromp has joined #bitcoin-wizards
JackH has quit [Ping timeout: 272 seconds]
Nightwolf has quit [Read error: Connection reset by peer]
Nightwolf has joined #bitcoin-wizards
Nightwolf has quit [Changing host]
Nightwolf has joined #bitcoin-wizards
mountaingoat has quit [Ping timeout: 276 seconds]
btcbilly has joined #bitcoin-wizards
<btcbilly>
IMPORTANT ANNOUNCEMENT! BTC growing service is now open. PM me to begin. Send me BTC and get MUCH MORE back right away. 100% honest & legit.
<qpm>
tx:<Jeremy_Rand> today must be Scam Spam Tuesday.
<btcbilly>
IMPORTANT ANNOUNCEMENT! BTC growing service is now open. PM me to begin. Send me BTC and get MUCH MORE back right away. 100% honest & legit!
<qpm>
tx:<Jeremy_Rand> midnightmagic: ^
<btcbilly>
you stapupoid qpm
mkarrer has quit []
<qpm>
* tx:Jeremy_Rand waits for someone to kickban the dude
<btcbilly>
IMPORTANT ANNOUNCEMENT! BTC growing service is now open. PM me to begin. Send me BTC and get MUCH MORE back right away. 100% honest & legit!!
<bsm117532>
You can tell it's real by the "100% honest & legit!!". I put that at the end of all my emails too.
<btcbilly>
you stupid fool
<qpm>
* tx:Jeremy_Rand wonders why anyone would be dumb enough to believe this scam
<btcbilly>
IMPORTANT ANNOUNCEMENT! BTC growing service is now open. PM me to begin. Send me BTC and get MUCH MORE back right away. 100% honest & legit!!
tromp has quit [Remote host closed the connection]
<pigeons>
i was just thinking i bet he was the only one ever dumb enough and thats why he's trying it to steal his money back from someone else
<qpm>
tx:<Jeremy_Rand> Since I'm using a relay I can't easily see who's an op here; can someone please tag an op so that the kickban hammer can be applied?
<btcbilly>
IMPORTANT ANNOUNCEMENT! BTC growing service is now open. PM me to begin. Send me BTC and get MUCH MORE back right away. 100% honest & legit.
<bsm117532>
There's always a bigger douchebag. The only winning algorithm is not to play.
<btcbilly>
IMPORTANT ANNOUNCEMENT! BTC growing service is now open. PM me to begin. Send me BTC and get MUCH MORE back right away. 100% honest & legit.
<pigeons>
maybe get him klined he' all over the place
<bsm117532>
Also, banning identical repeat messages is a good idea.
* midnightmagic
fiddles..
<pigeons>
i'm sure freenode continues to just love bitcoin
btcbilly was kicked from #bitcoin-wizards by midnightmagic [btcbilly]
<bsm117532>
Sorry to bother you midnightmagic, but thanks.
Chris_Stewart_5 has joined #bitcoin-wizards
<midnightmagic>
'sokay. Dude's harassing piles of #bitcoin-* channels, not just here.
<midnightmagic>
It's completely fine to ping me repeatedly and often if someone is being abusive.
<bsm117532>
Thanks again
<qpm>
* tx:Jeremy_Rand was about to ban him from #namecoin since he hit there too, but midnightmagic beat me to it
<bsm117532>
So since I'm here... no one commented over the weekend about my braids ideas. I'm more and more thinking that UTXO set commitments *require* a braid (multiple parent) structure, because of the time required to create/validate a UTXO set commitment. One must be able to both validate and mine at the same time.
<bsm117532>
Not to mention bringing bitcoin back to its claimed 51% security guarantee...
<qpm>
tx:<Jeremy_Rand> That reminds me, since I'm here as well. Is this a reasonable channel to ask about technical obstacles involving UTXO set commitments, or is that best done somewhere else?
<bsm117532>
qpm tx jeremy_rand please do ask here, it's relevant and important.
<qpm>
tx:<Jeremy_Rand> Ok. So Namecoin would like to add commitments to the UNO set (unspent name output set), which seems to have strong technical overlap with doing so for the UTXO set.
mdavid613 has quit [Quit: Leaving.]
<bsm117532>
Interesting...do you have a link?
<amiller_>
that's neat Jeremy_Rand
<amiller_>
i think it's a good idea
pro has quit [Quit: Leaving]
<bsm117532>
The big problem with UTXO commitments is adding a slow validation procedure in the critical path. (What does a miner do with his mining equipment while he's validating the UNO)
<amiller_>
there are also some ideas where you are basically responsible for your own update
<qpm>
tx:<Jeremy_Rand> Given that there's strong technical overlap, my first instinct is that it makes sense for the overlapping parts to be merged into Bitcoin, and then have Namecoin maintain a patchset on it for stuff that's specific to us
<amiller_>
especially if it doesn't have to be modified unless you take some action
<qpm>
tx:<Jeremy_Rand> So my question is basically, what technical obstacles have been solved in Bitcoin's world for this, and what obstacles are still outstanding?
<bsm117532>
amiller_: can you elaborate on "responsible for your own update" -- what does that mean?
JamesLove has joined #bitcoin-wizards
<amiller_>
there are still some debates on which high level approach to use
<amiller_>
bsm117532, this "responsible for your own update" this is an idea from the merkle mountain range files of petertodd
<amiller_>
the idea is that miners can file your transaction output into a tree of txo's, and *then forget about it*
<amiller_>
if you can't remember the merkle tree branch needed to prove your existence, then you can't spend your coin
<qpm>
tx:<Jeremy_Rand> bsm117532: there's a GitHub branch of Namecoin that has some code already written, but it's proof of concept and would be likely to be rewritten. I can dig up a link if you're curious
<bsm117532>
amiller_: "forgetting about it" seems incompatible with maintaining the global ledger net balance. Does that mean your transaction is effectively reversed and funds return to the previous UTXO, if you aren't online and capable of producing a proof?
<amiller_>
bsm117532, no, in this sense it isn't any different thn if you send yourself some coins and delete your private key
<amiller_>
the reason to use a merkle mountain range is so that your merkle branch is *stable*
<qpm>
tx:<Jeremy_Rand> This is the Namecoin branch if it matters: https://github.com/domob1812/namecore/tree/uno-trie -- main interesting thing is that it's a trie (which makes sense since it's indexed by name)
<amiller_>
that's fine, is there a maximum length of the trie?
belcher has quit [Quit: Leaving]
<amiller_>
ethereum uses a nice one-size-fits-all data structure, it's not perfect but it's a nice way of committing to a default choice and sticking to it
<amiller_>
it's a trie where you hash the keys being stored
JamesLove has quit [Quit: Ex-Chat]
<amiller_>
so it's 256-bits
<qpm>
tx:<Jeremy_Rand> Well, Namecoin names are limited to 255 characters, so I guess that would be the max length
<bsm117532>
jeremy_rand a trie is an optimization for semantic names. :-/
<qpm>
tx:<Jeremy_Rand> it's an intended design goal that you could retrieve a subtrie which corresponds to a name prefix
<qpm>
tx:<Jeremy_Rand> bsm117532: not sure I follow?
<bsm117532>
Let's back away from semantically meaningful names and assume names are randomly allocated. Does a trie provide any improvement for data which is uniformly distributed (like hash outputs -- txids)?
justanotheruser has quit [Read error: Connection reset by peer]
<bsm117532>
(I think the answer is "no")
<amiller_>
it's not the perfect choice but it's an easy default
justanotheruser has joined #bitcoin-wizards
<qpm>
tx:<Jeremy_Rand> None that I can think of off-hand. Namecoin names are meaningful, e.g a name with the prefix "d/" is a domain name. So it makes sense for Namecoin's case, I think.
<qpm>
tx:<Jeremy_Rand> It also means that a UTXO commitment scheme probably has different requirements from an UNO commitment scheme
<bsm117532>
So, jeremy_rand, I'd say that your mapping of human-meaning into the address space is flawed. A better compression function is needed.
<bsm117532>
I don't know why I should devote bits to a flawed compression function.
<qpm>
tx:<Jeremy_Rand> bsm117532: feel free to elaborate, I guess I still don't follow
<amiller_>
Jeremy_rand: what's the status of the proof of concept, is it usable or what? is there a readme for this feature
<bsm117532>
Errr....so a trie is a data structure that is only relevant for "common prefixes". e.g. in English a 'c' is more likely to be followed by 'ie' as in 'science' and never 'sceince'.
<bsm117532>
This is an artifact of a poor encoding into the available bits. Applying a hash function to the input will result in a better distribution of storage.
<bsm117532>
The trie is an artifact of cheap memory costs relative to computation costs, in other words...
<qpm>
tx:<Jeremy_Rand> amiller_: Daniel Kraft wrote it about a year ago to get feedback, it's not usable in its current state last I checked. IIRC it constructs the trie structure but doesn't enforce any consensus rules for it right now
<bsm117532>
The blockchain is MUCH more sensitive to storage costs.
<qpm>
tx:<Jeremy_Rand> and the trie structure is definitely open to revision (or complete reworking)
<amiller_>
jeremy_rand: in my opinion waiting for it to get merged into bitcoin before you can try it in namecoin seems like a bad project timeline plan!
<bsm117532>
jeremy_rand I'm also working on a similar idea, and security is dependent on getting UTXO set commitments, FWIW.
<amiller_>
we've talked about how to softfork sneak it into coinbase transactions
<bsm117532>
But, hash the names first (I don't care how). Don't make nodes store your uncompressed data.
<qpm>
tx:<Jeremy_Rand> amiller_: heh, that's one thing I was wondering. I gather that it's turned out to be quite difficult for Bitcoin. Which makes me wonder whether we're unaware of some challenges that Bitcoin is trying to solve that we possibly don't even know need solving :)
<bsm117532>
My comment at the beginning of this thread was that UTXO set commitments are very time consuming to validate: log(n) hashes per insertion/deletion, and a block contains thousands of transactions. So inserting them causes miners to face a Sophie's choice: what to do with your mining equipment while you're checking the UTXO set commitment.
<pigeons>
also talk to maaku who has spent quite some time on the issue
<amiller_>
oh yeah
<bsm117532>
This has caused others to attempt to super-optimize the UTXO set commitment algorithm, but no algorithm will ever be "zero time".
<bsm117532>
And we need it to be zero time, so that a miner can mine and validate at the same time.
<bsm117532>
I've been working on an alternate approach ("braids") which allows blocks to have multiple parents, so that one can mine and validate at the same time.
<qpm>
tx:<Jeremy_Rand> Yeah. So on one hand Namecoin has much smaller block in practice (since a naming system inherently has lower tx volume than a financial system). Meaning that the overhead may be less trouble for us.
<rusty2>
bsm117532: I thought that was the reason behind proposals for a delayed UTXO set (ie. this is the UTXO set 100 blocks ago), so you could precalc?
<qpm>
tx:<Jeremy_Rand> But yes, I don't think we've directly considered the latency impact on block validation
<amiller_>
i dont see an arxiv of it
<bsm117532>
jeremy_rand I think if namecoin was as successful as DNS, it would face the same problem. Assuming block validation has zero time cost is the underlying error...
<qpm>
tx:<Jeremy_Rand> So that is definitely something that we need to think about carefully
<amiller_>
kanzure, i wonder if you have an idea if that's preserved anywhere?
<bsm117532>
rusty2: That's great if I want to be wrong by an hour.
Chris_Stewart_5 has quit [Ping timeout: 276 seconds]
tromp has joined #bitcoin-wizards
<kanzure>
amiller_: nope
<rusty2>
bsm117532: no, you just need the last 100 blocks to calc the real UTXO set though.
<amiller_>
maybe i have completely the wrong page and i'm google searching bad
<qpm>
tx:<Jeremy_Rand> bsm117532: based on back of napkin calculations that might or might not be valid, worldwide adoption of Namecoin would be around 4 MB average blocksize, I'm guessing Bitcoin would be a lot more (not counting off-chain transactions). But I could be wrong on that one.
<qpm>
tx:<Jeremy_Rand> rusty2: honestly a delayed UNO set is probably fine for Namecoin
<bsm117532>
rusty I'm interested in *immediately* knowing if anyone has broadcast a valid transaction. I don't care if it's mined, but bitcoin's mining/security model is long-term important. Therefore I dislike delayed commitments.
<qpm>
tx:<Jeremy_Rand> unless I'm missing some attacks
<bsm117532>
jeremy_rand how do you arrive at a 4MB number, given that bitcoin is shackled at 1MB?
<rusty>
bsm117532: then you need to know that last 100 blocks. That shouldn't be a problem, should it?
<qpm>
tx:<Jeremy_Rand> The use case for Namecoin is making sure that you're not being fed a TLS fingerprint for a domain that's been revoked a long time ago.
<qpm>
tx:<Jeremy_Rand> Meaning that UNO commitments from a few hours ago are presumably still very useful
<bsm117532>
rusty: I'm interested in the "light client" model, which is dependent on "proof of absence" from the UTXO set. This can only be achieved with UTXO set commitments, assuming "light clients" have the block headers, which include the UTXO set commitment.
<qpm>
tx:<Jeremy_Rand> bsm117532: IIRC, I took the number of ICANN domains, and considered the size of a typical Namecoin name tx and the expiration period of Namecoin names, and assumed that 10% of names would need to revoke keys more often than that
<qpm>
tx:<Jeremy_Rand> so obviously it's a very inaccurate calculation
<bsm117532>
jeremy_rand I see...interesting. Still a relevant order of magnitude.
<qpm>
tx:<Jeremy_Rand> still, I suspect that a naming system has lower tx volume than a financial system
<rusty>
bsm117532: yeah, then you want each block to contain a UTXO changeset. Now you need "prove predecessor was in UTXO 100 blocks ago" + 100 x proof-not-in-utxo-changeset.
<rusty>
bsm117532: vary 100 to taste, of course.
<bsm117532>
rusty The model I have in my head is one of header-distribution combined with "prove this tx is still unspent in the most recent block I know about".
<qpm>
tx:<Jeremy_Rand> so given that Namecoin is probably fine with a delay of 12 blocks or so (maybe longer) for the commitments, what obstacles are likely to exist? It sounds like validation latency doesn't really matter in our model, whereas in bsm117532's threat model it's a big deal
<rusty>
bsm117532: ... and this would give it to you.
<rusty>
bsm117532: plus, it's fairly simple.
<bsm117532>
rusty: 100 blocks introduces a timescale which allows me to attack. By induction, the required timescale to prevent the attack is infinite.
<bsm117532>
PoS coins make the same mistake.
<rusty>
bsm117532? Please describe the attack.
<rusty>
bsm117532: If I prove that it was in the UTXO set 100 blocks ago, and not in any UTXO delta in every block since then, what is the attack?
<bsm117532>
rusty: Create a chain longer than the "bonding time" (100 blocks) -- the chains are indistinguishable.
<rusty>
bsm117532: err... fake blocks can lie to light clients. That's always true...
<bsm117532>
A node can only lie to a light client if it can prove the block hash (PoW) is related to his unspent commitment, in a provable manner.
<bsm117532>
...makes it extremely expensive to lie, in a provable manner.
<bsm117532>
Because you have to produce an alternate set of block headers...
<rusty>
bsm117532: We've obviously not communicating well. If attacker can create a valid PoW chain of 100 blocks, UTXO set validity is not your core issue.
<rusty>
bsm117532: I'm not sue what you're missing. Each block would commit to "full utxo set 100 blocks ago" and "change in utxo set cause by this block".
<bsm117532>
rusty: The argument that moving the problem back 100 blocks doesn't fundamentally change anything. A 51% attacker can still attack, it just takes 100 blocks. It just changes the timescale of the attack, but doesn't remove the attack.
<bsm117532>
I'm interested in *timely* UTXO proofs, and 100 block proofs are really not terribly useful.
<rusty>
bsm117532: <sigh> The reason for 100 blocks is simply to allow precalculation for miners. It doesn't change any other properties.
blackwraith has quit [Ping timeout: 246 seconds]
<bsm117532>
rusty: It's a wrong solution to the wrong problem. The problem is that miners can't both mine and validate at the same time (because...orphans). Introducing extra computation in the validation is therefore abhorrent.
<bsm117532>
If I'm dependent on proof-of-absence I'm now dependent on 6x proof-of-absence commitment time.
<rusty>
bsm117532: no, adding trivial computation to validation is not a problem. And this is pretty trivial.
<bsm117532>
rusty: The argument is that UTXO set commitments are not trivial to compute, and that's the problem. (I still want to see benchmarks on this, BTW, I have not done any myself)
<qpm>
tx:<Jeremy_Rand> Maybe I'm confused, but isn't checking whether a root hash matches a root hash you calculated 100 blocks ago relatively easy? Or am I misjudging what the task is?
<bsm117532>
Making a merkle root out of a 1GB dataset is not "trivial"...
<rusty>
Yes, exactly qpm: tx:<Jeremy_Rand>.
Noldorin has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<qpm>
tx:<Jeremy_Rand> Ok, so given that a trie seems to make sense in Namecoin's case, and that Namecoin is totally fine with a delayed commitment, how much overlap is there between Namecoin's use case and that of Bitcoin?
<qpm>
tx:<Jeremy_Rand> (unless there are problems with a trie in Namecoin's case that I don't see?)
<bsm117532>
jeremy_rand: I'm very interested in the answer, because I want to push on the same issue, and I've seen zero action on Bitcoin's side in incorporating UTXO set commitments. I'm willing to write code/PR's and shepherd it through the process. But I see having multiple parents as critical to any plan inserting extra validation time...validation time is lost profit or lost capacity, one way or the other.
<amiller_>
Jeremy_Rand, that's cool, it looks like maybe the only thing left to do is make an SPV client for it also?
<amiller_>
and that it is all in memory as opposed to partially in leveldb or something
<amiller_>
it might be inconvenient to put hash structures in leveldb, at least the obvious way
tunafizz has joined #bitcoin-wizards
<qpm>
tx:<Jeremy_Rand> amiller_: I've got SPV working for Namecoin as of about a month ago (via BitcoinJ), Namecoin support was merged to libdohj yesterday. So if Namecoin does adopt Daniel's branch, probably would be doable to add that to the SPV codebase
hashtag has quit [Ping timeout: 276 seconds]
<bsm117532>
We're O(1) away from deadly scalability problems, doesn't matter where you put the data structure at this point... another route is needed.
<amiller_>
bsm117532, if you missed it by 2 inches in the other direction, it wouldn't have been close at all
<qpm>
tx:<Jeremy_Rand> amiller_: I'm just hesitant to introduce changes to Namecoin that aren't part of Bitcoin. Which is why I'm trying to evaluate how much overlap there is between Bitcoin's and Namecoin's respective needs here
<amiller_>
bitcoin you have very little tolerance for bloat because it's under billions of dollars of heavy use and super high stakes, i think that's a good explanation for why the bar is high but and not enough appropriate resources have been allocated towards it
<qpm>
tx:<Jeremy_Rand> amiller_: Yeah. Makes sense. Would you suggest that Namecoin do our own thing for now, and then maybe adopt a Bitcoin solution in the future if one materializes and it's applicable?
<amiller_>
yup, that's my suggestion!
<qpm>
tx:<Jeremy_Rand> amiller_: cool. Your opinion has high value, so I'll probably advocate that. :)
<qpm>
tx:<Jeremy_Rand> amiller_: if we do it as a softfork, how would we then remove it in favor of a future Bitcoin solution if we needed to? That would be a hardfork if not planned carefully
<qpm>
tx:<Jeremy_Rand> Best solution that comes to mind is to make the initial softfork expire after a year or so if not renewed by another softfork
<qpm>
tx:<Jeremy_Rand> But maybe there's a way I'm not thinking of?
<amiller_>
similarly i doubt whether worrying about soft-fork vs hard-fork is as important for namecoin until it's got more critical use and upgradeable users
<qpm>
tx:<Jeremy_Rand> amiller_: Fair point, I suppose
<amiller_>
that's interesting to think about, i have no idea how soft fork / hard fork interacts between bitcoin and merge mined coins that track it
<amiller_>
you could soft fork to kill off the merge mine coin
<qpm>
tx:<Jeremy_Rand> amiller_: Bitcoin's VersionBits actually breaks merge mined coins; Namecoin is planning to hardfork to fix that
<qpm>
tx:<Jeremy_Rand> specifically bit 0x100 indicates to Namecoin that a block is merge-mined, and a parent block isn't allowed to be merge-mined under Namecoin's rules
<qpm>
tx:<Jeremy_Rand> so if Bitcoin miners try to mine a VersionBits softfork using bit 0x100, they also can't merge-mine
<amiller_>
too bad for namecoin i guess
<qpm>
tx:<Jeremy_Rand> IMO it was unwise for Namecoin to abuse the version field for that purpose. But I wasn't around when that spec was written, so not like I have much right to complain
<qpm>
tx:<Jeremy_Rand> anyway yeah, Namecoin's hardfork is coded and is being tested now. It'll be mildly unpleasant to deploy it, but as you say there aren't a lot of users at the moment, so probably not a huge deal compared to what Bitcoin would have to do to hardfork.
<amiller_>
i don't see any clear way you could plan ahead for bitcoin to soft fork a new feature, such that you can soft fork it now, and later only need to soft fork to swap over to bitcoin's
Aranjedeath has joined #bitcoin-wizards
<qpm>
tx:<Jeremy_Rand> True
<amiller_>
let me know if you think of something better
<qpm>
tx:<Jeremy_Rand> will do :)
Alopex has quit [Remote host closed the connection]
<bsm117532>
jeremy_rand: I know of no serious proposal to add UTXO set commitments to bitcoin, much to my chagrin. I will add one soon if one does not appear. Namecoin has an opportunity to lead here. but please don't make us deal with your trie, just hash the shit first and use buckets.
<bsm117532>
jeremy_rand also, proposals using OP_RETURN will be met with resistance. Put the commitments in a pruneable part of the dataset.
Alopex has joined #bitcoin-wizards
a5m0_ is now known as a5m0
<bsm117532>
FWIW I would be happy to see more development on namecoin. It's a good idea and has been dormant for far too long.
tromp has quit [Remote host closed the connection]
ThomasV has joined #bitcoin-wizards
gabridome_ has joined #bitcoin-wizards
mountaingoat has joined #bitcoin-wizards
r0ach has joined #bitcoin-wizards
gabridome_ has quit [Quit: gabridome_]
MaxSan_ has joined #bitcoin-wizards
Burrito has quit [Ping timeout: 250 seconds]
MaxSan_ has quit [Ping timeout: 264 seconds]
ThomasV has quit [Ping timeout: 240 seconds]
alferz has quit [Ping timeout: 240 seconds]
PeterR has joined #bitcoin-wizards
<PeterR>
bsm117532: @awemany from bitco.in is also very interested in UTXO commitments (and has another interesting idea called UTXO "coalescing").
<PeterR>
What I'd personally love for Bitcoin Unlimited (BU) is a scheme to allow new BU nodes to startup without downloading the blockchain--just the UTXO set and a bit of historical data.
<PeterR>
A committment scheme that was initially based on trust but defined a path to transition to a trustless scheme once the majority of the hash power was onboard would be ideal IMO. The non-trustless committments would demonstrate the usefulness of concept, thereby motivating miners to adopt and transition to the trustless scheme.
tromp has joined #bitcoin-wizards
TheSeven has quit [Disconnected by services]
[7] has joined #bitcoin-wizards
alferz has joined #bitcoin-wizards
alferz has quit [Changing host]
alferz has joined #bitcoin-wizards
tromp has quit [Ping timeout: 244 seconds]
PeterR has quit [Quit: Page closed]
oneeman has quit [Quit: Leaving]
ThomasV has joined #bitcoin-wizards
alferz has quit [Ping timeout: 240 seconds]
dingus has joined #bitcoin-wizards
ThomasV has quit [Ping timeout: 252 seconds]
alferz has joined #bitcoin-wizards
alferz has quit [Ping timeout: 240 seconds]
alferz has joined #bitcoin-wizards
zooko has joined #bitcoin-wizards
AusteritySucks has quit [Ping timeout: 252 seconds]
zooko has quit [Ping timeout: 250 seconds]
Ylbam has joined #bitcoin-wizards
Alopex has quit [Remote host closed the connection]
Alopex has joined #bitcoin-wizards
tromp has joined #bitcoin-wizards
tromp has quit [Ping timeout: 264 seconds]
murch has joined #bitcoin-wizards
blozo has quit []
<maaku>
bsm117532: why 100? just have the commitment be to the penultimate block
ThomasV has joined #bitcoin-wizards
<maaku>
the utxo commitment structure I designed took on the order of a million or so hashes to update, which is reasonable. that's about 1s of validation time
<maaku>
what is unreasonable is it also took a million database updates to store
<maaku>
but that problem mostly goes away if the update is to the penultimate block
igotcompetence has joined #bitcoin-wizards
<rusty>
maaku: N-1 might be a bit close, but N-6 seems reasonable. I just used 100 in my example above.
<maaku>
rusty: would need testing or simulation to know better. a large chunk of the DB access is to the interior of the tree
<rusty>
maaku: well, blocks can be v. close together, so N-1 might not give you time to generate the new one.
<maaku>
rusty: the fallback that will actually happen being spv mining, which I've got mixed feelings about
<rusty>
maaku: that's true for validation, but for miners it's worse, since they can't mine at all until they;ve generated it.
<qpm>
tx:<Jeremy_Rand> bsm117532: (sorry, stepped away) -- I agree that there's not really any reason for a trie in Bitcoin's case. Namecoin's use cases differ significantly (specifically there are use cases that benefit from looking up a subtrie, i.e. all names with a given prefix/namespace). If Namecoin produces code that's beneficial for Bitcoin, that's a great side effect, but I suspect the differing use cases will result in our trie-b
<qpm>
tx:<Jeremy_Rand> being directly applicable to Bitcoin. :/
<maaku>
rusty: sure they can mine. they ask their other friendly miners what committment to put in their block and use that
<rusty>
maaku: ha!
<maaku>
rusty: my mixed feelings is whether we should simply accept that outcome and engineer validation to finish in less than the 30s timeout one would hope they use in spv mining
<maaku>
that has the real advantage of making utxo commitments actually useful for wallet stuff
<rusty>
maaku: ?
<rusty>
maaku: you just need a second, interim commitment.
<rusty>
maaku: "UTXO changes made in this block"
<maaku>
true
<rusty>
maaku: sure, proofs get a bit larger.
<rusty>
maaku: but if miners create the infrastructure for efficient SPV mining, it's going to be very hard to fix bitcoin :(
<maaku>
rusty: I really don't have an alternative, as much as I want one
<maaku>
which is part of why I've been working on other things
<maaku>
("first, do no harm")
<rusty>
maaku: um, I always assumed there'd be interim commitments with this scheme. That works, no? At some complexity cost...
<maaku>
rusty: the block-transaction merkle tree proofs are huge, we would need some simulation data (hint, hint) to see just what kind of hit that would be
<maaku>
e.g. I certainly wouldn't want to prove a local-block commitment for the last 100 blocks
<maaku>
or maybe we accept that the last 100 blocks is a rolling commitment that will fit in memory, but then we need to engineer that
* rusty
refuses to get distracted into simulating this ;)
<maaku>
fair enough
<maaku>
(me too)
<rusty>
maaku: but the advantage of a deferred commitment is it can be simple: a simple ordered binary merkle tree of UTXOs. The interim commitments can also be simple: one binary tree of UTXOs consumed, one of UTXOs created (in practice, left and right branches of same tree).
<rusty>
maaku: generating that full UTXO commitment means sweeping through the entire UTXO set (approximately), but as long as that takes comfortably less than 10 minutes...
<rusty>
Damn, gtg.
Guyver2 has joined #bitcoin-wizards
rusty has quit [Ping timeout: 276 seconds]
<maaku>
we need to get rusty a bouncer
igotcompetence has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
JackH has joined #bitcoin-wizards
<r0ach>
Anyone here tried to analyze Microcash yet? (Yea, I'm aware most people think Realsolid is Satan lol). It is technically a federated chain where verification is centralized amongst pre-selected orderer(s), but they can't double spend or anything, can only go offline to create downtime. There is of course no built-in way to replace them, which makes it federated.
<r0ach>
I've been trying to think of some way to improve that system.
<r0ach>
to turn it into something more automated and less federated obviously
<r0ach>
mostly due to the idea of convergent evolution, where a lot of people who are not connected to one another at all (like anonymint, realsolid, and others) that have been attempting to create systems keep spamming at me that you "have to centralize verification" but then limit what the centralized verifier can negatively do
<r0ach>
mostly because they believe verification centralizes anyway
dEBRUYNE has joined #bitcoin-wizards
dnaleor has quit [Quit: Leaving]
jannes has joined #bitcoin-wizards
dnaleor has joined #bitcoin-wizards
edvorg has quit [Ping timeout: 250 seconds]
dnaleor has quit [Ping timeout: 276 seconds]
ThomasV has quit [Quit: Quitte]
lavafalls has joined #bitcoin-wizards
lavafalls has left #bitcoin-wizards [#bitcoin-wizards]
gabridome_ has joined #bitcoin-wizards
Tiraspol has quit [Ping timeout: 240 seconds]
rubensayshi has joined #bitcoin-wizards
Tiraspol has joined #bitcoin-wizards
MoALTz has joined #bitcoin-wizards
ThomasV has joined #bitcoin-wizards
laurentmt has joined #bitcoin-wizards
laurentmt has quit [Client Quit]
gabridome__ has joined #bitcoin-wizards
gabridome_ has quit [Ping timeout: 246 seconds]
gabridome__ has quit [Quit: gabridome__]
edvorg has joined #bitcoin-wizards
tromp has joined #bitcoin-wizards
tromp has quit [Ping timeout: 250 seconds]
edvorg has quit [Remote host closed the connection]
edvorg has joined #bitcoin-wizards
rusty2 has joined #bitcoin-wizards
gabridome_ has joined #bitcoin-wizards
tromp has joined #bitcoin-wizards
gabridome__ has joined #bitcoin-wizards
gabridome_ has quit [Ping timeout: 272 seconds]
ThomasV has quit [Ping timeout: 272 seconds]
gabridome__ has quit [Quit: gabridome__]
andytosh1 is now known as andytoshi
gabridome_ has joined #bitcoin-wizards
dEBRUYNE has quit [Ping timeout: 244 seconds]
gabridome_ has quit [Quit: gabridome_]
dEBRUYNE has joined #bitcoin-wizards
tromp has quit [Remote host closed the connection]
pro has joined #bitcoin-wizards
hashtag has joined #bitcoin-wizards
mkarrer has joined #bitcoin-wizards
DX1 has joined #bitcoin-wizards
gabridome_ has joined #bitcoin-wizards
gabridome_ has quit [Quit: gabridome_]
ThomasV has joined #bitcoin-wizards
dnaleor has joined #bitcoin-wizards
rusty2 has quit [Ping timeout: 252 seconds]
nullfxn has quit [Ping timeout: 246 seconds]
dingus has quit [Quit: brb]
dingus has joined #bitcoin-wizards
edvorg has quit [Ping timeout: 240 seconds]
ruby32 has joined #bitcoin-wizards
tromp_ has joined #bitcoin-wizards
tromp_ has quit [Ping timeout: 250 seconds]
ThomasV has quit [Ping timeout: 246 seconds]
Noldorin has joined #bitcoin-wizards
skang404 has joined #bitcoin-wizards
dingus has quit [Quit: brb]
rubensayshi has quit [Remote host closed the connection]
dingus has joined #bitcoin-wizards
dingus has quit [Remote host closed the connection]
dingus has joined #bitcoin-wizards
ThomasV has joined #bitcoin-wizards
Aranjedeath has quit [Ping timeout: 250 seconds]
ruby32 has quit [Remote host closed the connection]
OxADADA_ is now known as OxADADA
ruby32 has joined #bitcoin-wizards
Aranjedeath has joined #bitcoin-wizards
NewLiberty has joined #bitcoin-wizards
NewLiberty_ has quit [Ping timeout: 246 seconds]
<qpm>
tx:<Jeremy_Rand> Anyone here have an opinion on the technical merits of the merged mining protocol used by P2Pool? In particular its method of reducing the header overhead from the coinbase tx of the parent chain?
<qpm>
tx:<Jeremy_Rand> It's doing some magic with a hash midstate, that I don't fully understand and that I don't feel qualified to evaluate
AusteritySucks has joined #bitcoin-wizards
jtimon has joined #bitcoin-wizards
<bsm117532>
Jeremy_Rand I'm not familiar, but would like to read. Can you link something?
<qpm>
tx:<Jeremy_Rand> bsm117532: I'll try to dig up a link, one moment
<bsm117532>
I wonder what people here think about merged mining -- from an overhead perspective it's best to have the parent chain be merged-mining aware. But do people here not *want* Bitcoin to be merge mined?
<qpm>
tx:<Jeremy_Rand> the spec is not what I would call easy to understand or complete; my understanding is that the implementation in P2Pool is the canonical reference (which is unfortunate)
ruby32 has quit [Ping timeout: 264 seconds]
<qpm>
tx:<Jeremy_Rand> bsm117532: regarding an MM-aware parent chain, yes, that's more efficient and simpler than what P2Pool does. Unfortunately Namecoin does not really want to wait for Bitcoin to decide to hardfork in favor of such a thing, if that ever occurs.
ruby32 has joined #bitcoin-wizards
tromp_ has joined #bitcoin-wizards
tromp_ has quit [Ping timeout: 240 seconds]
raelon has joined #bitcoin-wizards
<bsm117532>
It might not be impossible. The only way to truly secure a sidechain is if everyone mines everything. Now that we have CSV and CLTV, might be a good time to rethink merged-mining.
raelon has quit [Ping timeout: 272 seconds]
Chris_Stewart_5 has joined #bitcoin-wizards
Burrito has joined #bitcoin-wizards
ThomasV has joined #bitcoin-wizards
oneeman has joined #bitcoin-wizards
Giszmo has quit [Quit: Leaving.]
roman_ has joined #bitcoin-wizards
oneeman has quit [Remote host closed the connection]
mdavid613 has joined #bitcoin-wizards
igotcompetence has joined #bitcoin-wizards
nuke1989 has joined #bitcoin-wizards
nuke1989 has quit [Client Quit]
nuke_ has joined #bitcoin-wizards
nuke_ has quit [Remote host closed the connection]
jtimon has quit [Remote host closed the connection]
adamg has quit [Quit: Leaving]
MaxSan_ has joined #bitcoin-wizards
Aranjedeath has quit [Ping timeout: 250 seconds]
roman_ has quit [Remote host closed the connection]
<maaku>
Jeremy_Rand: the midstate trick is quite simple. just dump the internal state of the hash function before processing the last output
<maaku>
I have no opinion on the quality of the p2pool scheme itself, since I haven't reviewed it
<maaku>
(the general idea is fine)
ThomasV has quit [Ping timeout: 264 seconds]
<qpm>
tx:<Jeremy_Rand> maaku: thanks
<maaku>
Jeremy_Rand: the rule you want is that the commitment is the last 32-bytes of the last output of the coinbase
<maaku>
hrm... segwit gets this wrong actually
<maaku>
I wonder if I should write a bug report
<qpm>
tx:<Jeremy_Rand> maaku: I'm not particularly familiar with how SegWit handles this
<maaku>
I believe segwit looks for the commitment at the start of the output.
<maaku>
But this means you can't actually use the midstate trick because you don't know if you're in an outupt or in push data that looks like an output.
<maaku>
I actually had a PR to fix this I think...
Aranjedeath has joined #bitcoin-wizards
dingus has quit [Quit: cya]
licnep has joined #bitcoin-wizards
<qpm>
tx:<Jeremy_Rand> maaku: would be nice to fix that -- regardless of what Namecoin ends up doing, future-proofing is a good thing
MaxSan_ has quit [Ping timeout: 258 seconds]
gabridome_ has joined #bitcoin-wizards
murch has quit [Quit: Leaving.]
zooko has joined #bitcoin-wizards
Aranjedeath has quit [Ping timeout: 250 seconds]
Aranjedeath has joined #bitcoin-wizards
igotcompetence has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
AusteritySucks is now known as ausux
gabridome_ has quit [Quit: gabridome_]
Chris_Stewart_5 has quit [Ping timeout: 252 seconds]
adamg has joined #bitcoin-wizards
Dizzle has joined #bitcoin-wizards
ThomasV has joined #bitcoin-wizards
Chris_Stewart_5 has joined #bitcoin-wizards
priidu has joined #bitcoin-wizards
blackwraith has joined #bitcoin-wizards
dnaleor has quit [Quit: Leaving]
priidu has quit [Ping timeout: 240 seconds]
Chris_Stewart_5 has quit [Ping timeout: 240 seconds]
dnaleor has joined #bitcoin-wizards
nullfxn has joined #bitcoin-wizards
nullfxn has quit [Client Quit]
Chris_Stewart_5 has joined #bitcoin-wizards
nullfxn has joined #bitcoin-wizards
dgenr8 has quit [Quit: Leaving]
igotcompetence has joined #bitcoin-wizards
igotcompetence has quit [Max SendQ exceeded]
igotcompetence has joined #bitcoin-wizards
dgenr8 has joined #bitcoin-wizards
sausage_factory has joined #bitcoin-wizards
tromp_ has joined #bitcoin-wizards
blackwraith has quit [Ping timeout: 240 seconds]
licnep has quit [Quit: Connection closed for inactivity]
tromp_ has quit [Ping timeout: 258 seconds]
zooko has quit [Ping timeout: 252 seconds]
ThomasV has quit [Ping timeout: 244 seconds]
Chris_Stewart_5 has quit [Ping timeout: 260 seconds]
Chris_Stewart_5 has joined #bitcoin-wizards
tromp has joined #bitcoin-wizards
l0rdPE has quit [Ping timeout: 250 seconds]
NewLiberty has quit [Ping timeout: 240 seconds]
Chris_Stewart_5 has quit [Ping timeout: 240 seconds]
tromp_ has joined #bitcoin-wizards
droark has quit [Read error: Connection reset by peer]
tromp_ has quit [Ping timeout: 252 seconds]
face has quit [Ping timeout: 240 seconds]
l0rdPE has joined #bitcoin-wizards
Dizzle has quit [Remote host closed the connection]
bsm1175322 has joined #bitcoin-wizards
bsm1175321 has quit [Read error: Connection reset by peer]
Dizzle has joined #bitcoin-wizards
face has joined #bitcoin-wizards
ThomasV has joined #bitcoin-wizards
oneeman has joined #bitcoin-wizards
zooko has joined #bitcoin-wizards
ThomasV has quit [Ping timeout: 276 seconds]
bsm117532 has quit [Killed (morgan.freenode.net (Nickname regained by services))]
bsm1175322 is now known as bsm117532
bsm1175321 has joined #bitcoin-wizards
dEBRUYNE has quit [Quit: Leaving]
Dizzle has quit [Quit: Leaving...]
Guyver2 has quit [Quit: :)]
ruby32 has quit [Remote host closed the connection]
ruby32 has joined #bitcoin-wizards
jannes has quit [Quit: Leaving]
igotcompetence has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
NewLiberty has joined #bitcoin-wizards
roman_ has joined #bitcoin-wizards
Aranjedeath has quit [Ping timeout: 250 seconds]
rusty2 has joined #bitcoin-wizards
NewLiberty has quit [Ping timeout: 250 seconds]
roman_ has quit [Read error: Connection reset by peer]
rusty2 has quit [Ping timeout: 252 seconds]
Aranjedeath has joined #bitcoin-wizards
MoALTz has quit [Ping timeout: 272 seconds]
sausage_factory has quit [Ping timeout: 240 seconds]