deadalnix, csw, quadratic hashing + more

i have a clearer idea of how the new nodes will be especially valuable now
deadalnix
12:33 PM
This is not the case anymore, thanks to core's RBF policy.
csw
As the TX is taken first come first added, most TX(DoubleSpends) will be dropped as they are rare in  a block
Posted in #privateYesterday at 12:31 PM
csw
12:34 PM
Time 099.8% of hash power has TX(1)
90%~ of "nodes" have TX(DS)Time 1 (Block discovered)
99.9% of the time, TX(1) is accepted and mined
0.01% Double spend works
12:34
I did not say that RBF was good either
12:34
RBF is just double spend by fee.
joeldalais
12:34 PM
rbf is retarded
12:35
i never understood why anyone thought it was a good idea
csw
12:35 PM
Central planning at its best!
joeldalais
12:36 PM
so, basically, as nodes disperse, the chance of a double spend getting in before a real transaction increases
csw
12:36 PM
The senario is counter intuitive, most nodes see the doublespend, but as most of the miners see the iniital TX, the double spend loses (and this ignores RBF)
deadalnix
12:36 PM
Doesn't matter if it is retarded or anything, it IS.
12:36
You guys need to start dealing with reality.
csw
12:36 PM
IS is not perminent and what has been subverted can be fixed
tomothy
12:37 PM
It's also not active in btc
joeldalais
12:37 PM
like i was saying earlier
deadalnix
12:37 PM
This sentence is self contradictory.
tomothy
12:37 PM
More of a concern for LTC
joeldalais
12:37 PM
its not like people are not being warned...
12:39
the question someone should be asking is "what are the time intervals/dispersion rate?" (edited)
deadalnix
12:39 PM
If it is not pertinent then there is no point fixing it. If it needs fixing then it is and needs to be taken into account.
12:39
Or you are just modeling some fantaisyland.
joeldalais
12:40 PM
just because you don't understand something doesn't equate to fantasy
csw
12:40 PM
You assume that I am not planning to fix it
deadalnix
12:40 PM
I assume nothing.
12:40
You haven't fixed it yet.
mwilcox
12:44 PM
this is not that productive. there's a simple situation here right. if you were going to increase the number of tx to be effectively a 2.7MB block, what benefit is gained from not broadcasting the witness data as widely as the rest of the block? you are just actively weakening the network by making tx harder to validate no?
deadalnix
12:44 PM
@mwilcox the same as not broadcasting any part of a block today, withotu segwit.
joeldalais
12:44 PM
ransom, data becomes a commodity, sell it
Pinned by satoshi
csw
12:47 PM
What is centralisation?This is debated all over the place when Bitcoin is concerned. The thing is, it is a solved and simple question.  It is calculated as a function of Zeta in equations around the degree of distribution. The calculation is d, the diameter of large connected Poisson networks. It is the average distance for the network.The trouble is that Core wants this to be larger. The seem to think that the average distance in the scale free network is a measure. That a large average d means decentalisation. This is a flaws, it simply means more hops and less resilience.
12:47
But @mwilcox , if you send both the Witness data and the block, you have a 4MB transaction. You gain 1.6 x the TX throughput at a 400% cost.
12:48
For 4MB, you get 400% increases.
joeldalais
12:48 PM
http://d10k7sivr61qqr.cloudfront.net/content/royinterface/10/83/20130206/F1.medium.gif (47kB)

macsga
12:48 PM
http://slideplayer.com/4741541/15/images/28/Poisson+vs.+Scale-free+network.jpg (122kB)
joeldalais
12:49 PM
yours is better :smile:
macsga
12:49 PM
this continues to be a dick measurement
Pinned by satoshi
csw
12:49 PM
In the currecnt model, SPV miners are parasitical. They can be modeled. These models exist. They are able to be profitable right now at under 0.3% of the hash rate. More and they start orphaning and hence losing profit
deadalnix
12:50 PM
You gain 1.6 x the TX throughput at a 400% cost.
This right there is the SW showstopper.
csw
12:51 PM
@deadalnix this is why they weight the cost and make it so miners will SPV
deadalnix
12:51 PM
Cost for miner isn't validation.
12:51
hashrate is way more expensive.
csw
12:52 PM
Yes, and has hashrate is the expensive part, why are we making network traffic the thing to prune off?
macsga
12:52 PM
it is expensive to hack it that is; sw just makes it easier
csw
12:53 PM
The road to perfection leads to ruin
12:53
There are always economic tradeoffs
deadalnix
12:54 PM
@csw SW is not about reducing network traffic. Never was.
csw
12:54 PM
Scale is f more critical then seeking a mathematically proven (none actually exist) cryptographically sound system
12:55
It is not about network traffic
not about storage
Not about UTXOs
Seems it has nothing to do with scaling at all
thatwildcard
1:09 PM
@deadalnix so what IS segwit, for?
deadalnix
1:10 PM
@thatwildcard malleability fix, quadratic hashing fix, (version, hash) outputs, ...
1:11
SegWit degrades bitcoin's scaling abilities.
1:11
SegWit do not change anything when it come to block retention.
macsga
1:11 PM
Wait. I have an explanation what SegWit is, how to set it up and how to test it.
1:11
https://www.youtube.com/watch?v=ewGAmiLuYCw
YouTube The Slow Mo Guys
Diving into 1000 Mousetraps in 4K Slow Motion - The Slow Mo Guys
1:12
(Poisson network mousetrap setup demonstrated) (edited)
csw
2:16 PM
malleability fix,
- partial at best
- Only using SW
- Not benign Mallebilityquadratic hashing fix,
- Only if miners are discounting and ignoring validation
- Simply to fix in Bitcoin using TX threading (Similar to CuDA based programming)(version, hash) output
- no benefit unless you want to make BTC an account and not cash system
deadalnix
2:27 PM
You now convinced me you don't understand the quadratic hashing problem.
2:29
as version hash, this is far supperior to the clusterfux that txout are right now. Provide a sane upgrade path Where nodes can both know they are missing something (better than soft forks) and can still verify the overall financial integrity of the system (better than hard forks).
csw
2:56 PM
I understand it perfectly well.TXs can be split and Sigs can be validated in more efficient a manner than they are now.
3:01
Quadratic scaling of hashing time. Not actually "Quadratic hashing".
Lets start with the right terms?
deadalnix
3:08 PM
You still to hash an amount of data proportional to the size of the sig for each input.
3:08
Making the processing parallel make it faster note more effiscient.
3:10
quadratic hashing is just a handy shortcut.
csw
3:12 PM
It is more efficient, when you consider the complete use of newer hardware.
The linear processing is slow and inefficient.Taken in parallel, you speed up validation. Using systems more efficently and allowing this is efficency. Unless you choose to play WoW at the same time, but then, nodes should not be half time systems.
3:13
And yes, I understand that Raspberry Pis will not keep up...
3:13
The point is, seeing as they do nothing on the network now (ignoring the slight slowdown of propagation they cause), who cares. (edited)
3:18
Next, TXs only need to be validated once. Right now, this occurs from blocks and TXs. Only when a TXs is propagated doies it need this and then use Quadratic Probing and Double Hashing, Bloom filters etc to order and store and search TXs and map these to a Block.
Then, only new unchecked TXs need to be pulled and validated and when many of the outter shell systems go this is faster in any event. As stated, 99.8% of the hash power recieves a TXs in the initial 2 seconds, it is the non hashing systems that are receiving slowly.
Pinned by satoshi
3:22
And @deadalnix - you already know that the argued solution to Quadratic scaling of hashing time is ONLY solved by SegWit if you stop the existing TX forms and move people to only use SegWit and price them away from the existing onchain system.
3:23
That is, if SegWit allows an existing Bitcoin Transaction, it does not solve anything.... So, is that the answer... We ban or price old addresses out?
deadalnix
3:27 PM
You are serving back to me argument I made way before you appeared.
3:27
You don't understand the difference between performance and effisciency.
3:28
And you don't seem to understand that parallelising a workload do not change the amount of computation you need to do.
csw
3:28 PM
No, I am not trying top make a system run on a single CPUAnd that argument was correct and has not changed.
3:28
I just see that the amount of compute power has increased.
deadalnix
3:29 PM
You guys are shifting goalpost constantly. You asked what segwit is for I answered.
3:29
Now you are acting like I'm somehow supporting segwit regurgitating me argument I made years ago.
3:29
Seriously, I'm not impressed.
csw
3:32 PM
A system with something akin to 2x Nvida Volt could run 10k threads simultaneously, it is available today. It would allow 20,000 sig checks a thread a second.No, a fix that does not fix is not a fix.
deadalnix
3:32 PM
And it cannot execute divergent path.
3:33
That means you have one large tx, now all tx are large.
csw
3:33 PM
If the attack remains, it is not solved and you yourself stated this
deadalnix
3:33 PM
Yes you need a HF version of segwit to fix the attack vector.
csw
3:34 PM
Define what you are stating as a "divergent path" so we discuss the same thing.
3:34
No, a HF that replaces Bitcoin with an Alt.
deadalnix
3:34 PM
GPU are SIMT
3:34
one decode unit for mutliple threads.
3:35
If you have a loop, like when you hash data, all thread have to loop around untill all thread finish the loop.
csw
3:35 PM
CuDa yes
deadalnix
3:35 PM
it's cnot cuda, it is the hardware.
3:35
There is no tech can can do it any oteher way.
3:35
This is how it is in the silicon.
csw
3:35 PM
Not in all cases. No.And if you do not like that and the coding overhead, XeonPhis
deadalnix
3:36 PM
When several thread need to take different path, for instance one exit the loop but not another, this is a divergent path.
3:36
GPU cannot execute divergent path.
3:36
They execute all the path.
csw
3:36 PM
Xeon Phi is not a GPU
3:36
Each core can be independent, it is just a bugger to code
deadalnix
3:37 PM
You w ree talking about nVidia Volt before
3:37
No you are shifting again to something else.
csw
3:37 PM
You moved to divergent paths
deadalnix
3:37 PM
It's not a question of bugger, it's a question that if you have one decode unit in silicon instead of one per thread, you can cram more thread in the sislicon.
3:38
a decode unit need to process ~50GBps of data, that's not a small unit.
tomothy
3:38 PM
At this point, I question whether deadalnix's continued line of investigation  is in good faith or designed to waste time. Imo, it seems like the latter.
csw
3:38 PM
Xeon Phi, 4x 72 Cores.
35,000 Sig Checks
deadalnix
3:38 PM
I oved to divergent path because you mentionned that you can solve the problem with a nVidia Volt. Which you can't because divergent path.
csw
3:38 PM
50GBps is a long way from 1Mb
deadalnix
3:39 PM
Decode unit to not process data, they process instructions.
3:39
that's why GPU don't handle divergent path.
csw
3:39 PM
I have 100 G Infiniband here... It is a small chip :slightly_smiling_face:
Small Cards.Just large cost
3:40
Fine, I much prefer Xeon Phi and I play with them already :slightly_smiling_face:
deadalnix
3:41 PM
It's fine, just say, "indeed it doesn't work with a GPU" and we can move on.
csw
3:42 PM
You could be right. I have not tried on Nvida, so, unless I am shown otherwise, I will believe you.
It could well not work on a GPU.
3:42
That is the best I can say as I have not tested.
csw
3:42 PM
Acceptable?
5 replies
Last reply about 15 hours ago View thread
deadalnix
3:42 PM
Yes. i'm telling you GPU don't do divergent path, so if you have a very large tx, you'll be looping to hash it and all other thread will be stalled.
csw
3:43 PM
But... I do know that it works on Phi
deadalnix
3:43 PM
Yes up to a point.
csw
3:43 PM
Yes, a truly large TX could exceed the core and memory allocation.
deadalnix
3:43 PM
what tx size have you tried ?
3:43
yes
csw
3:43 PM
100M
deadalnix
3:43 PM
nice.
csw
3:44 PM
Then it just collapses
3:44
But, I figure 100 M is fine today
deadalnix
3:44 PM
100M block or 100M tx ?
csw
3:44 PM
TX
deadalnix
3:45 PM
yes, i'm not sure there is such a use for 1MB tx already, but you never know.
csw
3:46 PM
The 20MB TX cap that was there would stop it in any case.
Pinned by satoshi
3:47
The cost right now is the issue. We go up to 20,000 USD and that is for a Visa sized system
But we do not need to do that today.
3:47
As for a 1 MB TX.... There is a way to run a small OS in a TX and load it into a system...
deadalnix
3:49 PM
Yes, would you agree that solving quadratic hashing is a worthy goal ? (I think we both agree that SegWit does it badly - that's besside the point here).
csw
3:49 PM
It is a goal, but it is not the biggest one
deadalnix
3:50 PM
Agreed.
csw
3:50 PM
Personally, we fix the big issues first and then fill in the gaps
deadalnix
3:50 PM
Well it's not like one or the other.
3:51
One I find really important (probably more so than people realize) is sighash cover value. What do you make of that one ?
joeldalais
3:51 PM
whats that saying again..
csw
3:51 PM
Well, getting more use (more people) is the thing we need to address
3:51
More detail please
joeldalais
3:51 PM
"better to be good enough than absolutely perfect" ?
csw
3:52 PM
A product in market wins over the one being built
3:53
I would like to know what you mean by sighash cover value @deadalnix
deadalnix
3:56 PM
@csw sighash cover value is one of the feature of SW (but could be implemented on its own). The basic idea is that the output being spend is included in the sighash of the corresponding input.
3:56
If the content of the output is wrong, then the signature is invalid.
3:56
That allow for offline device to sign transactions.
3:57
while being confident that, if lied to by the untrusted device, the generated signature will be invalid.
csw
3:59 PM
I see, but there are other ways to do this without SegWit.
deadalnix
3:59 PM
Yes
csw
3:59 PM
And as you state, on its own
4:01
And, offline systems can sign now. Messy for the most part, but possible. Or are you focused on chained offline signing?
deadalnix
4:02 PM
They can sign but they can't trust the output they are spending
4:02
I can say to the device that it is spending 1BTC when in fact it is spending 10BTC.
csw
4:04 PM
Yes, but the ability to monitor that externally and link information makes that less important. I still see this more of a specific use issue than one that covers all of Bitcoin
4:04
That is, there are market based solutions for this that do not need the central protocol to change.
deadalnix
4:04 PM
user need to trust that it just works
4:04
too many coin lost or stolen
4:05
user don't understand how to secure their coins
4:05
it is simpler to just tell them "use that device"
csw
4:05 PM
Yes, but this is a problem selected hardware vendors have and it is one the we seem to think needs to be universally solved for them, rather than having competing market based offerings
4:06
Move the user to threshold keys
4:06
Have a dealerless setup
Pinned by satoshi
4:07
Have a 256bit value associated with a quadratic that is determined and stored on a Java card.
Link it to a phone (we all have these now)
And do a multipart computation of the Sig operation.
deadalnix
4:08 PM
yes but the phone is not trusted in that setup
csw
4:08 PM
No, the card and the phone operate as a unit
deadalnix
4:09 PM
so that card, whatever the tech, need to be suer that if the phone is feeding it incorrect data, then what it does would be invalid
4:09
or you own the phone you own the whole system and there is no need for a card.
csw
4:09 PM
Neither are trusted and neither need to be
4:10
The card acts with the phone
It allows the phone to complete a part of the operation and to have a signed process of the phone using a smartcard
deadalnix
4:11 PM
what if the phone tell the card you are spending one coin when it is spending 10 ?
csw
4:12 PM
I am publishing this year
4:13
If you make a card with a pin entry, then the card can tell the phone
4:14
There used to be a few ugly cards that could do that
4:15
Oh, in peer review, please do not publish that image about...
deadalnix
4:15 PM
yes this solve the problem that the phone and the card have to cooperate to sign.
4:15
I won't
csw
4:15 PM
Ta.
4:16
So, if you want to get a card that provides the input, I will help you create a solution that does just that.
4:16
:slightly_smiling_face:
deadalnix
4:17 PM
the problem is that the input doesn't contain the amount
csw
4:18 PM
No, I mean that if you have a card that you can send the value you want to spend to...
4:18
Not the input TX, the value that you want to sign
4:20
I need to run... Family :slightly_smiling_face:
If that is a solution that you believe the market would like, then I would like to help you in designing itSo talk more soon
deadalnix
4:23 PM
++ take care.
csw
4:27 PM
:slightly_smiling_face:
4:27
You also. I enjoyed the chat
satoshi
4:28 PM
Great ideas.  Paste this @travin!
travin
4:28 PM
Hello. I'm here. Any desired starting point for pasting?
deadalnix
4:29 PM
not the picture
4:29
csw don't wanted that to be published
csw
4:29 PM
I have node vertices data for the network. If people wish to analyse it, happy to send
Large.. Very largeBut I can also do point in time.
4:30
I deleted the image
4:30
All ok now :slightly_smiling_face:
4:30
I just do not want to have a leak delay publication.... journals can be bastards.
travin
4:31 PM
Pictures won't be published
4:31
Pastebin readers will only see image.jpg (edited)
4:31
Only links are visible.
csw
4:32 PM
Reading :slightly_smiling_face:P. Feldman. A practical scheme for non-interactive verifiable secret sharing. In Proceedings of the 28th IEEE Annual Symposium on Foundations of Computer Science, pages 427–437, 1987.Gennaro, R., Jarecki, S., Krawczyk, H., Rabin, T.: “Robust threshold DSS signatures”. In: Proceedings of the 15th Annual International Conference on Theory and Application of Cryptographic Techniques. pp. 354–371. EUROCRYPT’96, SpringerVerlag, Berlin, Heidelberg (1996)Ibrahim, M., Ali, I., Ibrahim, I., El-sawi, A.: “A robust threshold elliptic curve digital signature providing a new verifiable secret sharing scheme”. In: Circuits and Systems, 2003 IEEE 46th Midwest Symposium on. vol. 1, pp. 276–280 (2003)
4:32
These authors cover some of the topics
travin
4:32 PM
https://pastebin.com/GB2CcfMr
 Pastebin
Segwit Discussion May 13 2017 - Pastebin.com (19kB)

4:33
Looking forward to reading this later. :slightly_smiling_face:
cryptorebel
4:34 PM
that was an interesting discussion
travin
4:35 PM
We should get some SegWit/Core people on here. I'd like to see a technical discussion about it. Maybe not here though but on #debate
4:36
Yeah, most discussions here are interesting. Most of them are above my level of understanding, which is great because it means I learn more. One of these days I'll chime in and contribute more than just posting pastebins
vlad2vlad
4:36 PM
I believe @luke-jr is in here.  He's one of their best.  Cobra was also in general last night but not sure if he's in here.  I invited Peter Todd but he never showed up.
4:36
So we do have some with opposing views.  Quite talented I might add.  More are welcome.
travin
4:37 PM
I think I saw @luke-jr say a few things, but just a few comments. I could've just missed them though. But yeah, more would be good.
joeldalais
4:38 PM
we do need to be a little careful on who we invite here, avoiding a troll fest and keeping discussions civil and technical is good
travin
4:40 PM
I tried to invite some others I know who are Core supporters, but they didn't want to enter as they felt they were technically unable to discuss at the same level of some people here, which I find both unreasonable and concerning. These are people adamantly supporting something and fighting against something else that they don't really understand, and are afraid to be proven wrong. (edited)
2 replies
Last reply today at 3:03 AM View thread
travin
4:41 PM
Not saying all core supporters are like this. It's a normal human trait as well, but I was hoping to get more from people who criticize the discussions when they see the pastebins shared on other channels. (edited)
4:44
Has anyone tried inviting Erik on here? Not sure if he was Core or BU though.
vlad2vlad
4:47 PM
I'll invite him.  Not sure if I have his email.
4:47
He's neutral
vlad2vlad
4:56 PM
Sent.
travin
4:56 PM
Sweet. Will be nice to add another to the neutral list :slightly_smiling_face: (edited)
macsga
5:50 PM
I'm biased; is it bad?
5:50
:stuck_out_tongue:
vlad2vlad
5:51 PM
Sometimes bias is good.  :)
peter_r
6:01 PM
I heard a rumor that there's a 15 BTC bounty to convincingly show that transactions from segwit addresses are less secure than regular bitcoin transactions.  Is this true?
travin
6:02 PM
I think this is it - https://pastebin.com/TZY4aQU0
cryptorebel
6:03 PM
research challenge
vlad2vlad
6:04 PM
@peter_r    15 Bitcoins .  The Segwit Challenge:  Research FundThe reward is for anyone who can prove segwit increases miner incentive to forego witness data (increases risk of protocol changes without miner consent) and that it allows for unvalidated transactions.
peter_r
6:06 PM
I still don't see where the bounty offer was made, who made it, or the conditions required to claim the bounty.
tomothy
6:07 PM
Bounty is to disprove
6:07
Other just costs for tests and to get published
6:07
Afaict
peter_r
6:07 PM
Right, but where exactly is this written up?
6:08
And who put up the bounty?
tomothy
6:08 PM
Craig did
6:08
Vlad is wallet
6:08
And it's the hypothesis above Vlad stated
cryptorebel
6:08 PM
here is a fuller pastebin from beginning until a couple days ago, you might be able to search through it easier: https://pastebin.com/QWgGtwgr (edited)
peter_r
6:10 PM
@csw: do you agree to pay a 15 BTC reward to "anyone who can prove segwit increases miner incentive to forego witness data (increases risk of protocol changes without miner consent) and that it allows for unvalidated transactions"?
cryptorebel
6:10 PM
I think discussion about it jumped around and didnt happen all at one time
peter_r
6:11 PM
So Vlad has signing authority on a wallet big enough to pay out this bounty?
tomothy
Vlad is wallet
Posted in #privateYesterday at 6:08 PM
cryptorebel
6:11 PM
there may be a multi-sig wallet or something is what I heard
peter_r
6:11 PM
OK thanks for the info guys.
cryptorebel
6:14 PM
is BUIP055 getting any traction, or did Jihan pretty much veto it?
peter_r
6:14 PM
I was wondering that myself.
6:15
I just want max_block_size increased.  It doesn't matter to me how we do this.
macsga
6:15 PM
@peter_r there's more in the basket apart that 15BTC bounty. If you read the pastebin it might get more interesting