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
wallet42 has quit [Quit: Leaving.]
adam3us has joined #bitcoin-wizards
pandabearit has joined #bitcoin-wizards
c-cex-yuriy has joined #bitcoin-wizards
oldbrew has left #bitcoin-wizards [#bitcoin-wizards]
pandabearit has quit [Ping timeout: 272 seconds]
tromp has joined #bitcoin-wizards
GGuyZ has quit [Quit: GGuyZ]
midnightmagic has joined #bitcoin-wizards
tromp has quit [Remote host closed the connection]
Ylbam has quit [Remote host closed the connection]
tromp has joined #bitcoin-wizards
Casper- has joined #bitcoin-wizards
rusty has quit [Ping timeout: 240 seconds]
dEBRUYNE has quit [Ping timeout: 256 seconds]
a5m0 has quit [Remote host closed the connection]
a5m0 has joined #bitcoin-wizards
Jeremy_Rand has joined #bitcoin-wizards
tromp has quit [Remote host closed the connection]
brg444 has joined #bitcoin-wizards
gobiasindustries has quit [Quit: Page closed]
DougieBot5000 has joined #bitcoin-wizards
GAit has joined #bitcoin-wizards
Yoghur114 has quit [Remote host closed the connection]
Jeremy_Rand has quit [Ping timeout: 250 seconds]
Ylbam has joined #bitcoin-wizards
GAit has quit [Quit: Leaving.]
GGuyZ has joined #bitcoin-wizards
bitdevsnyc has joined #bitcoin-wizards
tromp has joined #bitcoin-wizards
GGuyZ has quit [Quit: GGuyZ]
adam3us has quit [Quit: Leaving.]
GAit has joined #bitcoin-wizards
zmachine has quit [Ping timeout: 260 seconds]
chjj has quit [Ping timeout: 245 seconds]
zmachine has joined #bitcoin-wizards
gnusha has quit [Ping timeout: 245 seconds]
gnusha has joined #bitcoin-wizards
CubicEar_ has quit [Remote host closed the connection]
memymo has joined #bitcoin-wizards
memymo has quit [Client Quit]
memymo has joined #bitcoin-wizards
chjj has joined #bitcoin-wizards
tromp has quit [Remote host closed the connection]
bitdevsnyc has quit [Remote host closed the connection]
bitdevsnyc has joined #bitcoin-wizards
CubicEarth has joined #bitcoin-wizards
memymo has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
GAit has quit [Quit: Leaving.]
frankenmint has quit []
memymo has joined #bitcoin-wizards
GAit has joined #bitcoin-wizards
<jl2012>
as I understand, by the definition of "witness", it could include nVersion, nSequence, scriptSig, and nLockTime. With a softfork, however, only the scriptSig may be segregated. That's not very optimal
memymo has quit [Client Quit]
<gmaxwell>
Locktime and sequence .. must be commited to by the signatures, which is kind of cyclic. nversion is actually a utxo property that could be used to change the interperation of txouts in the future.
<gmaxwell>
jl2012: even adopting that position, they're also only 4 bytes each. moving them across would make them much more expensive to access for people who want the transaction plus those but otherwise without the witnesses.
<phantomcircuit>
and would be a hardfork (unless they were simply null in which case why are you doing it)
<jl2012>
i believe a hardfork is better here, as we will eventually need a hardfork. Are ASIC desingers complaining the lack of nonce space in header?
<jl2012>
a carefully written hardfork could be compatiable with existing ASIC and even SPV nodes
<jl2012>
e.g., using space of nVersion as nonce and move the real nVersion as part of Merkle root. And also the timewarp problem has to be fixed by hardfork
<jl2012>
softfork is great for simple things like BIP65. Even for relative locktime it already looks too complicated
mrkent_ has joined #bitcoin-wizards
<phantomcircuit>
jl2012, moving nVersion into the merkle root is... no
<jl2012>
phantomcircuit: just a different way to serialize the field and calculate the hash. I'll describe it in more details
<phantomcircuit>
jl2012, there's no reason to increase the nonce space
mrkent has quit [Ping timeout: 250 seconds]
<phantomcircuit>
(if anything it would cause more problems than it would solve)
<jl2012>
phantomcircuit: as ASIC becomes faster, it may become a real problem. Too much overhead between the ASIC and the computer
Newyorkadam has joined #bitcoin-wizards
<phantomcircuit>
jl2012, no it really wont
<phantomcircuit>
if it becomes an issue the work generation will be moved to an fpga
tripleslash has joined #bitcoin-wizards
<phantomcircuit>
(which is trivial and is already done by avalon hardware)
<jl2012>
how about the communication overhead between the FPGA and ASIC?
<Lightsword>
I think most bitmain gear also uses an fpga
<jl2012>
ok forget more nonce for ASIC. The lack of header space is also an issue. If satoshi left some free bytes in the header, sigwit could be a nicer softfork
<phantomcircuit>
jl2012, the thing generating work can be upto 2^32-1/16 times slower than the asic and still keep up
<phantomcircuit>
im entirely unconcerned about it
<GAit>
FYI cfields created #bitcoin-hk-dev for those participating to the hackaton today and tomorrow
<kanzure>
oh why
<Lightsword>
yeah, I think workgeneration isn’t much of an issue, cpu usage from comms is higher AFAIK on the controllers
<kanzure>
taking over #bitcoin-dev would be appropriate
<phantomcircuit>
Lightsword, well yes the easiest way to implement the cpu<->asic comms is to simply infinite loop polling for updates
<Lightsword>
phantomcircuit, I think they stick the FPGA in between mainly for io multiplexing or something like that
<gmaxwell>
jl2012: I am pretty confident that moving things like version would be quite negative; also: an independant sampling on that: in elements alpha where it was a hardfork, we didn't move that.
<phantomcircuit>
Lightsword, yes you have the asic switch a line high to signal to the fpga "there's something to do" then the cpu just polls the fpga in a circle
<phantomcircuit>
this of course depends on whether you're chaining spi or not
<gmaxwell>
jl2012: the hardfork we'd propose for SW would be to add another level to the hashtree which would be compatible with lite clients. I don't believe people demanding blocksize hardforks are actually okay with a _real_ hardfork. A few months back I tried proposing that we reclaim all the header bits that are forced to be zero due to difficulty (always at least 32 bits), and got a pretty chilly r
<gmaxwell>
esponse.
<gmaxwell>
I'm totally game for doing that however. But ... I'd leave it to you to sell to people.
<gmaxwell>
It would be very good to get nonce space into the first compression run of the proof of work.
<Lightsword>
would the soft fork break any miners that do work generation in the ASIC??
<phantomcircuit>
Lightsword, which one?
<Lightsword>
avalon or 21 Inc would be the ones I’m familiar with
<gmaxwell>
Nothing discusssed above would. The hardfork to move the SW commitment just makes it look like the block has 2x the number of transactions.
<Lightsword>
although avalon may be somewhere else in the hardware
<phantomcircuit>
Lightsword, no i mean which soft fork
<gmaxwell>
Segwit soft fork, as currently implement basically just looks like namecoin merged mining, in terms of how it looks to a device like that.
<Lightsword>
the one for segregated witness
alpalp has joined #bitcoin-wizards
<maaku>
morcos: yes, I think the witness should be kept small for now, but grow slowly a la BIP 103's rate. the code pieter presented would have just introduced another hard cap at 4mb however
<morcos>
maaku: oh i thought above you said it was fine for the witness to be 32MB or something
bendavenport has quit [Quit: bendavenport]
<gmaxwell>
If the witness is computed in the same limit as the block, then it needs a factor of 4 in order to realize the full capacity gain at the existing blocksize limit size. Luke was suggested to me previously that we just have (ironically for him) non-configurable soft-caps if we're worried about immediate bandwidth impact ahead of the advancements in block propagation performance.
roconnor has joined #bitcoin-wizards
rusty has joined #bitcoin-wizards
GAit has quit [Quit: Leaving.]
<amiller>
i feel like i'm missing something about the explanation of rationale for SW and increasing to (effectively) 4mb, like the concern about increasing to 4mb is that it will be bad for some miners, but SW doesn't impact any miners
<amiller>
so is it just that this is a way to increase to 4MB without having to do a hardfork?
<maaku>
morcos: not all fraud proofs involve a transaction. utxo/stxo commitments are seeming less likely to be needed now but those would also go in the witness.
<maaku>
header tree commitments for compact spv proofs, which are very sensitive to size, also in the witness.
<maaku>
merged mining commitments aren't really witness, but would be there too. no need for a sidechain to have a path through the bitcoin transaction tree for its block headers
<maaku>
morcos: sorry if it's repeat, still reading the backlog
<sipa>
amiller: SW very certainly impacts miners
<sipa>
amiller: but it's only 4 MB in pathological cases; for normal transactions right now, and only if they switch to using SW, it corresponds to some 1.75 MB
<amiller>
sipa, ok, for somewhere in between 1.75MB to 4MB, sure..... still miners have to receive all the transactions + witnesses to validate them, right?
<kanzure>
oh right there was also some claim about multisig as related to the 4 MB claim
<sipa>
amiller: yes, as far as miners are concerned, it's just a block.size increase, period
GAit has joined #bitcoin-wizards
<aj>
kanzure: i get "2MB" for P2PKH with segwit and "3MB" for p2sh w/ 2-of-2 multisig with segwit fwiw
<morcos>
maaku: so the use of the term fraud proof has mostly been just a simple way to prove that some type of witness data was in a block. what that data is and what it proves fraud of are unspecified?
<aj>
sipa: i couldn't work out what your segwit branch does with sigop limits...
<sipa>
amiller: it is pretty much everything else in the ecosystem to whom segwit is better than just a block size increase
<sipa>
aj: probably nothing
<amiller>
sipa, okay, understood. congrats on the great work + talk btw :)
<aj>
sipa: it seemed like it didn't count sigops for segwit txns at all, which seems like a flaw?
<maaku>
morcos: I suppose fraud proof should be constrained to mean a proof that a transaction is invalid e.g. by referencing witness or witness + transaction data, but loosly the same format proof is also done for header backlinks, merged mining commitments, etc.
<sipa>
aj: fair point!
<maaku>
so "fraud proof size" in discussions sometimes is a stand-in for "aux block header size" or "compact spv backlink size" and other things we also care about
<maaku>
we need better terminology
<morcos>
sipa: is there a reason not to count actual signatures verified, instead of just the number before the check_multisig
PaulCapestany has quit [Quit: .]
<maaku>
morcos: what I was saying above is (1) with CT a block might have 1MB tx data and up to 40MB witness data; with other stuff in development the ratio of witness/non-witness may get even larger
<sipa>
morcos: i am absolutely in favor of sane resource costs accounting instead of a dumb and confused sigops and bytes limit now
<sipa>
morcos: but fixing that really needs a hard fork, not more tweaks
<maaku>
but obviously we can't support a 41MB block anytime soon ... but it would be nice to scale up to that slowly over time
TBI has joined #bitcoin-wizards
<aj>
sipa: if there are only sigops in segwit data, it's a soft-fork to change how you account for them though :)
<sipa>
aj: we should obviously count them
PaulCapestany has joined #bitcoin-wizards
<maaku>
also, a note that wasn't in the talk I think, the pathological block validation cases depend on non-witness size. so those are still constrained to 1MB...
<CubicEarth>
maaku: I think you might be addressing a question I have.... what is the bound on the witness data? Why couldn't it be 40MB now?
<aj>
sipa: ie old nodes count sigops in the original block as 0, so _any_ constraint on segwit sigops is an additional restriction, even if it's bazillions of sigops per block
<sipa>
CubicEarth: miners right now are already worried about the centralization pressure of an increase to 4 MB
<morcos>
sipa: hmm.. i should look at your code, but the pubkeyscripts are now a new kind of p2sh right?
<maaku>
CubicEarth: it must be small now because as far as mining centralization concerns go, a 40 + 1 MB segwitness block is exactly the same as a hard-forked 41MB block
<morcos>
so by default would count as no sig ops, and there is no input
<sipa>
CubicEarth: 40 MB witness still means effectively relaying 40 MB of data for miners
<morcos>
so can't we redefine teh counting however we want
TBI_ has quit [Ping timeout: 240 seconds]
<morcos>
of course we have to stay under the old limits, but for anything appearing in the old way, but that doesn't seem restrictive
<sipa>
morcos: that's perhaps a reason to also put the version number in the witness
<sipa>
so we know a particular witness's last stack item is in fact an executed script, and can be counted as such
<CubicEarth>
sipa: I understand that aspect. Is there a cap at 4MB total? What about an attack where a miner does 1 MB + 40 MB of witness data?
<maaku>
morcos: right we can redefine the accounting however we want, and my argument is simply that we should be smarter about it :) (see jonas' talk + something like BIP 103 scaling curve)
<maaku>
(I do think that given the time available for the talk sipa did the right thing by not addressing this)
<sipa>
CubicEarth: yes there is a hard limit
<CubicEarth>
got it
<sipa>
maaku: i think this doesn't make sense
<sipa>
maaku: the cost of witness data vs non-witness data will not go down over time
<sipa>
there is no reason why the accounting should go down
<sipa>
except for the fact that we'd like a bigger limit at some point
<maaku>
sipa: I'm not arguing that the cost of witness vs non-witness data will go down
<aj>
maaku: scaling segwit data beyond 4MB without scaling the 'real' block data above 1MB doesn't make much sense though?
<maaku>
sipa: right I'm just arguing for a bigger limit at some point
<sipa>
aj: exactly
<sipa>
maaku: i know that, but i can't justify that
<maaku>
aj: it does with future enhancements e.g. CT
<sipa>
right, if the purpose changes, sure
<maaku>
sipa: you are okay with BIP 103, right?
<aj>
maaku: CT doesn't require a hardfork to mess with txout values anyway?
<maaku>
aj: no, it could be done as a soft-fork (we considered this for elements, might still do it that way as it has advantages regarding testing infrastructure)
<sipa>
maaku: you're confusing things
<sipa>
maaku: we can always add a second commitment for a level 2 witness for CT
<aj>
maaku: <impressed swearing>
<sipa>
in exactly the same softfork way
<maaku>
sipa: hrm. this is true.
<sipa>
maaku: if we expect that the amount of witness data changes dramatically compared to the effective transaction data
<maaku>
sipa: I don't like getting stuck with many limits however...
<sipa>
maaku: they're not extra limits
<sipa>
it's just a cost function!
<sipa>
the limit, technically, remains 1 MB; the witness part just gets a 75% discount towards that limit
<maaku>
aj: it's not unlike an extension block / sidechains. you send coins into CT outputs by putting them in a separate anyone-can-spend-with-revelation-of-CT-amount output, kinda like a sidechain peg pool
p15 has joined #bitcoin-wizards
<maaku>
then the CT outputs themselves are 0-valued
<aj>
maaku: huh. and i guess CT makes it impossible to check for dust anyway
<gmaxwell>
aj: dust is not a concern if things are setup such that consuming utxo is profitable.
<maaku>
sipa: all I'm saying is grow that by 17% per year ...
<maaku>
then we won't have to consider another separate witness to grow when we want to add CT
<maaku>
(if there is consensus for CT, etc. etc.)
<maaku>
just using it as an example because of the giant witnesses it generates
<sipa>
maaku: it makes no sense to grow a cost factor over time if we don't expect its cost to decrease over time
<CubicEarth>
so what are typical transaction sizes when the witness has been removed?
<maaku>
sipa: I do expect the cost of validation and relay to decrease over time. i believe you do as well? within sane amounts, e.g. BIP 103's numbers
<sipa>
maaku: if those numbers decrease over time we should just allow the limit to grow, in a hard fork
<sipa>
maaku: applying that growth via a fudge factor to apply to just one part just because we can seems insane to me
<morcos>
sipa: so sorry if i missed this, but why is 75% the right discount factor now then?
<maaku>
sipa: I am hopefull that we can get much more mileage out of this than a year or two delay. And to jgarzik's point, growing via a fixed schedule, even if super conservative, gives I actual experience with modifying infrastructure before the hardfork
<morcos>
it seemed to me it was motivated by thats all the benefit we would get out of it
<morcos>
but now you're saying more than that also happens to be risky if it turns out we could get even more benefit
<sipa>
maaku: say we end up in a situation where the factor was 20. i fully expect a counterparty like system to emerge that just encodes everything in the super cheap witness space... and has higher transaction rate than bitcoin itself
atgreen_ has joined #bitcoin-wizards
<sipa>
the factor is a hack to avoid double limits for various resources, and chosen so that the worst case on either side is acceptable
<maaku>
sipa: I don't see how that counterparty concern is any different between the scenarios
<aj>
sipa: does the segwit have the same 1MB limit or a separate one? like, if you have 2MB of segwit data, discounted by 75% to 500kB, does that mean you can only fill up 500kB of the main block for a total of 2.5MB?
<sipa>
aj: yes
<sipa>
basesize + witnesssize/4 = 1 MB
GAit has quit [Quit: Leaving.]
<sipa>
maaku: netween what scenarios?
<sipa>
if this factor grows unboundedly, you are making one part of the system effectively free to use compared to the rest
<maaku>
sipa: so you want the space of scriptSig data to be counted high specifically because it could be used to encode arbitrary data, correct?
tromp has joined #bitcoin-wizards
<aj>
sipa: ah, so 800kB of block plus 800kB/4 of segwit = 1MB for a 1.6x improvement in P2SH effective blocksize, and 667kB+1.333kB/4=1MB for a 2MB effective blocksize for 2-of-2 P2SH then
GAit has joined #bitcoin-wizards
<maaku>
so if we had CT extensions, you would want that in a separate witness, which could be allowed to be much larger, but care must be taken that one is not able to encode parasitic systems?
Ylbam has quit [Quit: Connection closed for inactivity]
<aj>
bah, P2PKH was the first one, not P2SH
<sipa>
maaku: i see your point, but at this point i think CT in bitcoin is completely unreasonable anyway...
Newyorkadam has quit [Quit: Newyorkadam]
AaronvanW has joined #bitcoin-wizards
<gmaxwell>
the range proofs would be a seperate witness in any case.
<sipa>
and i don't think we should let block space grow in a way that's not useful to bitcoin itself, just to accomodate a future case
Newyorkadam has joined #bitcoin-wizards
Newyorkadam has quit [Client Quit]
<maaku>
gmaxwell: that's what we're discussing -- I was considering a combined witness because that makes some aspects easier
bobke has quit [Ping timeout: 246 seconds]
tromp has quit [Ping timeout: 256 seconds]
<gmaxwell>
well in terms of commitment structure; you'd want the different data at different times; also it is potentially useful to have the signatures commit to the range proofs.
<gmaxwell>
(the reason for this is so that if someone attempts an invalid range proof the result could be to destroy their coins, which would presumably get rid of rangeproof verification based DOS attacks.)
Casper- has quit [Quit: Casper-]
adam3us has joined #bitcoin-wizards
<maaku>
but if I understand sipa correctly, it sounds like there is a desire to keep scriptSig witness 'small' (max <=3MB) for concerns over data-stuffing, but potentially something like CT with explicit data structure could be allowed larger (assuming future improvements that make combined data sizes safe)
AaronvanW has quit [Ping timeout: 250 seconds]
<gmaxwell>
maaku: without a constraint there strategic behavior by miners can be unboundly bad.
<gmaxwell>
E.g. "my blocks have 1tx and 400MB of CSPRNG noise in their witnesses, good luck with that."
Casper- has joined #bitcoin-wizards
GAit has quit [Quit: Leaving.]
bobke has joined #bitcoin-wizards
GAit has joined #bitcoin-wizards
p15 has quit [Ping timeout: 272 seconds]
pandabearit has joined #bitcoin-wizards
p15 has joined #bitcoin-wizards
p15 has quit [Ping timeout: 250 seconds]
brg444 has quit [Ping timeout: 252 seconds]
mrkent_ has quit []
pandabearit has quit [Ping timeout: 250 seconds]
execute has joined #bitcoin-wizards
GAit has quit [Quit: Leaving.]
GAit has joined #bitcoin-wizards
adam3us has quit [Quit: Leaving.]
rusty has quit [Ping timeout: 272 seconds]
CubicEarth has quit [Remote host closed the connection]
CubicEarth has joined #bitcoin-wizards
wallet42 has joined #bitcoin-wizards
arowser has quit [Quit: No Ping reply in 180 seconds.]
arowser has joined #bitcoin-wizards
<jl2012>
May I say that the rough consensus is to implement sigwit, while the size limit is still subject to debate (or testing etc)?
<gmaxwell>
Thats what I'd like to be true and what I expect will become true, and the feedback I've gotten from one on one polling people. I think you can say its so 'until a chain with more work shows up'. :)
bitdevsnyc has quit [Remote host closed the connection]
bitdevsnyc has joined #bitcoin-wizards
<jl2012>
my impression yesterday was many people liked this. I was not aware of any strong objection
<gmaxwell>
I've recieved some concern that the backdoor size increase is risky and likely harmful to the network; but I think the benefits are too attractive to ignore... basically it has something for everyone.
CubicEarth has quit [Remote host closed the connection]
CubicEarth has joined #bitcoin-wizards
rusty has joined #bitcoin-wizards
wallet42 has quit [Quit: Leaving.]
Burrito has quit [Quit: Leaving]
cluckj has quit [Ping timeout: 260 seconds]
mrkent has joined #bitcoin-wizards
GAit has quit [Quit: Leaving.]
Giszmo has quit [Quit: Leaving.]
GAit has joined #bitcoin-wizards
frankenmint has joined #bitcoin-wizards
mrkent has quit []
pozitrono has joined #bitcoin-wizards
<jl2012>
we must have a limit for the backdoor size anyway but that's a seperate topic
<jl2012>
in the most conservative case, just keep the overall limit as 1MB (which I don't agree)
<jl2012>
my point is the backdoor size is not a problem of sigwit per se
<gmaxwell>
Agreed. okay thats true.
<jl2012>
for the backdoor size, it could be 100, 101, 103, 248, flexcap. still open to debate
frankenmint has quit []
<gmaxwell>
jl2012: those things don't make sense for the backdoor size; consider say there is a 100MB backdoor size. It can only be used for about 3MB of transactions due to the size ratio between body and witness... but it could be used for 100MB of abuse.
<gmaxwell>
so the ratio between the blocksize and witness size limits is a segwit specific question.
<jl2012>
We could still use an overall limit. Say BIP102, then total block size including witness is 2MB
<jl2012>
instead, we may specify the backdoor limit is 2MB
<Luke-Jr>
I rather like Sacco's 2-4-8 proposal combined with segwit, personally.
<jl2012>
Luke-Jr: In a softfork way or hardfork way?
<gmaxwell>
Sacco?
<Luke-Jr>
jl2012: softfork of coure
<Luke-Jr>
gmaxwell: he posted to the dev ML a while back
gocrazy has quit [Remote host closed the connection]
<jl2012>
In a softfork way, the non-witness parts must be <= 1MB forever
<Luke-Jr>
gmaxwell: obviously I don't like or think the miner vote here is necessary
<Luke-Jr>
jl2012: s/forever/until some future hardfork/
<jl2012>
Luke-Jr: maybe to have one BIP, which is softfork at the begining , and become a hardfork in a few years. So people will have enough time to migrate
<Luke-Jr>
jl2012: sure, that would make sense
AaronvanW has joined #bitcoin-wizards
AaronvanW has quit [Changing host]
AaronvanW has joined #bitcoin-wizards
<CubicEarth>
gmaxwell: bitcoin currently has an theoretical max of 7 tps. With SegWit that increases to 10.5 tps. This is a 50% increase under 'ideal conditions'. SegWit can offer more than a 50% bump under typical conditions, but under those 'less than ideal' conditions, the 10.5 tps would take a hit as well. If that is correct, I think its a helpful way to help people understand what SegWit does and doesn't do.
<tulip>
CubicEarth: I struggle to see "transactions per second" as a meaningful metric.
<Luke-Jr>
^ +1
<Luke-Jr>
Bitcoin has no tps limit, since you can always do things off-chain
<tulip>
well, and people seem to conflate one transaction with one entity making it, which isn't true.
nivah has joined #bitcoin-wizards
sparetire_ has quit [Quit: sparetire_]
wallet42 has joined #bitcoin-wizards
<CubicEarth>
tulip: It absolutely is. I understand you may be making a point, and Luke is too. Yes you can do lots off chain, but on chain capacity matters.
<gmaxwell>
CubicEarth: yes, though less than many assume.
<tulip>
CubicEarth: 10.5 transactions though, what's a "typical" transaction?
<Luke-Jr>
CubicEarth: it matters, but calling it "tps" is unnecessarily confusing
<gmaxwell>
The "per-second" scale is also suspect, considering that the mean blocktime is 10 minutes, bitcoin does nothing "per second"; might as well also say that it does a half million transactions per day, but that doesn't sound so obviously small.
<Luke-Jr>
and since blockchain-transactions vary significantly in side, measuring it in this way is probably not even useful
<Luke-Jr>
what gmaxwell said too
<CubicEarth>
gmaxwell: agreed. I would be happy to switch to per-day amounts. But it helps to have a common language for understanding the chains transaction clearing capacity.
<tulip>
transactions per day is still meaningless until you can define what a transaction looks like.
<jl2012>
in any sigwit scheme, do we allow reuse of witness in the same tx or even same block to save more space? e.g. one witness for the same scriptPubKey?
<jl2012>
something like: "same as the witness x of tx y in this block"
<gmaxwell>
jl2012: doing so would deeply break the layering used in bitcoin, and incentivize key reuse. I don't think it would be a fein.
<aj>
jl2012: that would require a signature that didn't sign the transaction id to be useful too
<gmaxwell>
Also if they're really the same, then that can be handed just with non-consensus storage and line encoding.
<jl2012>
key reuse does have legitimate use like a charity accepting donation which is supposed to be open anyway
<CubicEarth>
tulip: it's not like I am the first person to talk about a "typical tx". Typical... is not an exact thing. I think "mean tx size" for the last 10,000 blocks would suffice for what I am trying to say
<Luke-Jr>
CubicEarth: the only thing it helps, IMO, is making invalid comparisons to VISA/etc tps
<gmaxwell>
CubicEarth: an important thing to keep in mind is that kind of fancy smart contracts used to move load off the chain result in larger transactions when they do hit the chain.
<Luke-Jr>
jl2012: no, it doesn't.
<tulip>
CubicEarth: I realise, the point I'm making is that the "transactions per second" metric is predicated on knowing what the size of a normal transaction is, and the commonly quoted figure is completely out of touch with reality.
<Luke-Jr>
jl2012: a charity can publish their watch-only HD seed if they want (but I don't know if I would advise it)
<CubicEarth>
gmaxwell: absolutely. And I get that SegWit shines in this respect, that is where it offers the most 'throughput increase' vs what would otherwise be the case
<gmaxwell>
jl2012: yes; it does, but thats fairly narrow and there are lot of really serious negative side effects.
<tulip>
CubicEarth: at the time the quoted number was posted on the wiki for example, most transactions used uncompressed point EC keys which wastes 32 bytes per signature for absolutely no reason.
<gmaxwell>
tulip: in theory they're very slightly faster to verify!
<jl2012>
Luke-Jr: allowing witness reuse will save a lot of costs for recepients of micropayment. Also save all the CPU validation costs
<gmaxwell>
(which is probably lost in hashing more data...)
<gmaxwell>
jl2012: when checksig is updated verification costs for many signatures at a time will be halved again from when they are now.
<CubicEarth>
tulip: Is the 7 tps figure what you are referring to?
<jl2012>
gmaxwell: it's the difference of O(1) and O(n)
<Luke-Jr>
jl2012: sounds like more reasons not to do it
<tulip>
CubicEarth: yes.
<gmaxwell>
jl2012: in any case, assuming that sighash flags are setup such that the same hashes can be used; then those savings can all be had in non-normative ways; without breaking the layering.
<tulip>
gmaxwell: sorry, I'd forgotten Satoshi had optimisations like that and OP_RETURN for even faster EC validation.
<gmaxwell>
jl2012: only when you think the amount of reuse is unbounded, in practice a transaction would consume 2-to a dozen inputs.
<gmaxwell>
tulip: haha
<jl2012>
ttyl
Quanttek has joined #bitcoin-wizards
GAit has quit [Quit: Leaving.]
<CubicEarth>
tulip: Luke-Jr: It sounds like the problem you have with the "TPS" metric is that people use it improperly, and/or that they use it to push silly arguments or arrive at incorrect conclusions. As your point about VISA. But I think it would be a shame to toss out a perfectly good metric just because it may be used inappropriately. Rest assured there are many Bitcoiners who will understand how to use the metric, and let it help
<CubicEarth>
them.
<Luke-Jr>
… I don't understand how to use it.
<tulip>
CubicEarth: that's not the problem, I'm just asking you to describe what the size of a "normal" transaction is. I'm saying that there's a complete disconnect with "7" TPS, it's nothing like that with transactions today and has never been.
<CubicEarth>
500 bytes
Quanttek has quit [Ping timeout: 250 seconds]
<CubicEarth>
And 802.11 G is not actually 54 Mbps....
<tulip>
500 bytes only works with an assumption of 2 in 2 out.
Jeremy_Rand_ has joined #bitcoin-wizards
Erik_dc has joined #bitcoin-wizards
<CubicEarth>
so, what would say is typical ;)
<aj>
CubicEarth: (500B is about 3.3 tx/s @ 1MB)
GAit has joined #bitcoin-wizards
<tulip>
lets work from the other way.
<CubicEarth>
let
<tulip>
6MB/hour is 1.6KB/s. so there's no way we can make this work.
<CubicEarth>
No way to make what work?
<gmaxwell>
CubicEarth: he just proved bitcoin doesn't exist
<tulip>
you could do "7 TPS" if each transaction was 238 bytes.
<aj>
tulip: 1 in 2 out p2pkh takes about 224B/tx, so not totally impossible
<tulip>
aj: yes, but those transactions have a change output which needs to be merged. if you never merge you grind the UTXO into dust.
<CubicEarth>
gmaxwell: That what I though too, so I figured I ask again :)
<gmaxwell>
One thing I haven't seen people notice/comment on in segwitness; is that we're also setting up to increase the p2sh hash to 256 bits. We made an error in continuing to use the 160 bit hash for p2sh.
<aj>
gmaxwell: i did see that! didn't seem worth commenting on though...
<tulip>
if you're promoting a metric which makes real world use impossible it's a pretty meaningless
<gmaxwell>
aj: I'm surprised we don't get more complaints about p2sh.
<aj>
gmaxwell: what's the error?
<gmaxwell>
aj: you generate a 2 of 2 for you and I (or whatnot, some policy I care about for escrow/smart contract with you)
<gmaxwell>
but you do 2^80 work with your fpga farm, and also construct a 1 of 1 with the same hash...
Jeremy_Rand_ is now known as Jeremy_Rand
Jeremy_Rand has quit [Quit: Konversation terminated!]
GAit has quit [Quit: Leaving.]
<tulip>
aj: well we can do like 50+ transactions a second or something if we just make every output everyone can spend, and just use trust.
<gmaxwell>
aj: not critically weak, but not awesome either.
Jeremy_Rand has joined #bitcoin-wizards
<aj>
gmaxwell: ah, true, especially given p2sh can be arbitrarily long term...
<aj>
tulip: "make every output anyone can spend" is the segwit rollout plan :)
<gmaxwell>
p2pkh didn't have this problem; since it's always 1 of 1, there is seldom room to make any use of a collision.
<gmaxwell>
aj: tecnically but not so efficient since they still must have a pubkey. :P
<CubicEarth>
tulip: TPS as a metric != 7, or any other number. You're some good points about 7 TPS being an unreasonable figure for comparisons, saying in essence "it doesn't really exist". But that's the '7' not the TPS-as-a-metric part.
<gmaxwell>
quote from reddit: "Let's segwit it already!"
<tulip>
CubicEarth: it's still completely meaningless, especially as transactions in Bitcoin can have multiple users and uses.
taek42- has joined #bitcoin-wizards
<gmaxwell>
how many transactions per second is a coinjoin or a cut-through?
<CubicEarth>
tulip: there mere fact that you acknowledge that "transactions" exist is enough to show that TPS is meaningful, unless you don't consider time exist or matter. Ug!
<gmaxwell>
hahah
<gmaxwell>
concept of 'self' is overrated.
<gmaxwell>
Where do you end and does the transaction begin?
<CubicEarth>
AI singularity -- the merge is near
nivah has quit [Ping timeout: 240 seconds]
<gmaxwell>
As long as it isn't the AI singularity of "friendship is optimal"
<tulip>
CubicEarth: you can cooperate to make transactions, I can happily make a wallet which cooperates to make all transactions coinjoins between random people- which ruins the metric entirely.
nivah has joined #bitcoin-wizards
N0S4A2 has quit [Quit: WeeChat 1.3]
<CubicEarth>
tulip: Happily, huh?
<gmaxwell>
I do suspect this conversation has drifited into a boring domain of semantics. :)
ThomasV has joined #bitcoin-wizards
bitdevsnyc has quit []
c-cex-yuriy has quit [Quit: Connection closed for inactivity]
Ylbam has joined #bitcoin-wizards
Jeremy_Rand has quit [Ping timeout: 272 seconds]
<CubicEarth>
It almost seems so. Sux. I came here to understand something better, and am about to leave with my metric seemingly in tatters.
rusty has quit [Ping timeout: 256 seconds]
CubicEarth has quit [Remote host closed the connection]
CubicEarth has joined #bitcoin-wizards
<CubicEarth>
tulip: what do you suggest as a metric that would be more helpful than TPS?
Erik_dc has quit [Remote host closed the connection]
<maaku>
'<sipa> maaku: i see your point, but at this point i think CT in bitcoin is completely unreasonable anyway...' <-- what do you mean? unreasonable in what way?
paveljanik has joined #bitcoin-wizards
paveljanik has quit [Changing host]
paveljanik has joined #bitcoin-wizards
<gmaxwell>
maaku: well I could answer that; it's very resource expensive, ... maybe it's low enough but we haven't even qualified how low would be low enough.
<gmaxwell>
it also has only computational soundness; which is a pretty big step from what bitcoin provides, at least theoretically. Same security assumption as the signatures, but invisible signature breaks aren't really possible.
<maaku>
gmaxwell: if it's opt-in though... and has a cheap conversion out (reveal blinding key to spend an output explicitly)
<gmaxwell>
yea, I don't think it's completely unreasonable; but nor is it completely reasonable!
<tulip>
CubicEarth: I don't know. suggesting something is a bad idea often doesn't mean I'm aware of something better. I'd just be cautious making metrics like that and trying to satisfy them.
<gmaxwell>
or at least I don't know if it or isn't! :)
<gmaxwell>
maaku: I'd like to figure out what it would take though.
<maaku>
gmaxwell: right I get that CT carries complicated cost tradeoffs which, if everyone used CT, would decrease bitcoin's capacity by a over an order of magnitude
<maaku>
but keeping it opt-in nullifies that concern from my perspective. if you want it you pay for it.
<gmaxwell>
there also may be better alternative models for 'occasional use'. E.g. a ZKP accumulator.
<maaku>
gmaxwell: what would make me hesitate is if there was something on the horizon better than CT, or the same features with less cost
supahot has joined #bitcoin-wizards
<maaku>
but is there anything like that on the horizon?
<maaku>
with math that actually exists I mean, not hypothicated efficient snarks that may never exist
<gmaxwell>
Zerocash; whos weaknesses are also fit nicer with opt-in. In particular; the trusted setup could be obviated allowing user initated accumulators that had their own verifying keys.
<gmaxwell>
As in you could burn bitcoins to pay to initate an accumulator with its own trusted setup key, dump coins in over time, pull coins out.
supahot has quit [Quit: Leaving]
N0S4A2 has joined #bitcoin-wizards
<maaku>
gmaxwell: I'm not sure CT and ZC significantly overlap in applications
<maaku>
in particular ZKP of zerocash require significant computaitonal power to create. you couldn't practically have lightning network with zerocash payment channels
<maaku>
whereas I'd be very interested in CT setup/settlement transactions
<gmaxwell>
Thats true; (well the proving is almost embarassingly parallel and delegatable to anyone you don't mind not being private wrt to; but your point remains)
<gmaxwell>
maaku: I'd given little/no thought to CT channels; it's an interesting thought.
GAit has joined #bitcoin-wizards
<maaku>
actually I'd very interested if someone were to study CT channels. I'm not certain what properties they would have, but it'd certainly limit leakage balance information into the historical record
<maaku>
but maybe with combination of onion routing and zero-knowledge path finding it could do even better
<amiller>
im trying to figure out snark + channels
CubicEarth has quit [Remote host closed the connection]
<amiller>
the snark there is mostly just so i can use saner notation, you could probably take whatever i come up with and approximate it with CT
<gmaxwell>
maaku: well they'd 'just work' but I'm not sure what they'd provide; needs ZK pathfinding or the channel amounts are all public.
<maaku>
right
<maaku>
i was annoyed when I actually looked at the onion routing work and realized onion routing != ZK pathfinding
<maaku>
is there anyone working on ZK pathfinding?
p15 has joined #bitcoin-wizards
<amiller>
maaku, yeah the way to do it would be to pass along something that isn't a snark
<amiller>
you wouldn't make a snark proof each time you make an incremental payment
markus-k has joined #bitcoin-wizards
DougieBot5000 has quit [Quit: Leaving]
rusty has joined #bitcoin-wizards
p15 has quit [Ping timeout: 256 seconds]
rusty has quit [Ping timeout: 256 seconds]
JackH has joined #bitcoin-wizards
CubicEarth has joined #bitcoin-wizards
rusty has joined #bitcoin-wizards
taek42- has quit [Quit: Leaving]
GAit has quit [Quit: Leaving.]
melvster has quit [Ping timeout: 240 seconds]
JackH has quit [Ping timeout: 256 seconds]
ThomasV has quit [Ping timeout: 272 seconds]
damethos has joined #bitcoin-wizards
pozitrono has quit [Ping timeout: 256 seconds]
melvster has joined #bitcoin-wizards
p15 has joined #bitcoin-wizards
matsjj has joined #bitcoin-wizards
rusty has quit [Ping timeout: 272 seconds]
GAit has joined #bitcoin-wizards
pandabearit has joined #bitcoin-wizards
berndj has quit [Ping timeout: 260 seconds]
jtimon has joined #bitcoin-wizards
GAit has quit [Ping timeout: 256 seconds]
CubicEarth has quit [Remote host closed the connection]
ThomasV has joined #bitcoin-wizards
trippysalmon has joined #bitcoin-wizards
Casper- has quit [Ping timeout: 272 seconds]
AaronvanW has quit [Ping timeout: 250 seconds]
CoinMuncher has joined #bitcoin-wizards
paveljanik has quit [Quit: Leaving]
pandabearit has quit [Ping timeout: 272 seconds]
Casper- has joined #bitcoin-wizards
stonecoldpat1 has joined #bitcoin-wizards
stonecoldpat has quit [Ping timeout: 245 seconds]
adam3us has joined #bitcoin-wizards
matsjj has quit [Remote host closed the connection]
CoinMuncher has quit [Quit: Leaving.]
AaronvanW has joined #bitcoin-wizards
AaronvanW has quit [Changing host]
AaronvanW has joined #bitcoin-wizards
moa has quit [Quit: Leaving.]
GGuyZ has joined #bitcoin-wizards
maaku has quit [Quit: No Ping reply in 180 seconds.]
kisspunch has quit [Ping timeout: 260 seconds]
kisspunch has joined #bitcoin-wizards
gielbier has joined #bitcoin-wizards
maaku has joined #bitcoin-wizards
gielbier has quit [Changing host]
gielbier has joined #bitcoin-wizards
maaku is now known as Guest53789
jtimon has quit [Ping timeout: 256 seconds]
adam3us has quit [Quit: Leaving.]
rustyn has quit [Quit: derp]
CubicEarth has joined #bitcoin-wizards
kisspunch has quit [Ping timeout: 240 seconds]
kisspunch has joined #bitcoin-wizards
droark has joined #bitcoin-wizards
matsjj has joined #bitcoin-wizards
AaronvanW has quit [Ping timeout: 250 seconds]
stonecoldpat1 is now known as stonecoldpat
bramc has quit [Quit: This computer has gone to sleep]
AaronvanW has joined #bitcoin-wizards
p15_ has joined #bitcoin-wizards
gwillen has joined #bitcoin-wizards
gwillen is now known as Guest78125
p15 has quit [Ping timeout: 250 seconds]
nivah has quit [Ping timeout: 256 seconds]
Guyver2 has joined #bitcoin-wizards
nivah has joined #bitcoin-wizards
AaronvanW has quit [Ping timeout: 250 seconds]
roconnor has quit [Ping timeout: 256 seconds]
dEBRUYNE has joined #bitcoin-wizards
ThomasV has quit [Ping timeout: 250 seconds]
GGuyZ has quit [Quit: GGuyZ]
seg has quit [Ping timeout: 260 seconds]
jessepollak has joined #bitcoin-wizards
ggreer has joined #bitcoin-wizards
AaronvanW has joined #bitcoin-wizards
seg has joined #bitcoin-wizards
pozitron has joined #bitcoin-wizards
CubicEarth has quit []
justanot1eruser has joined #bitcoin-wizards
justanot1eruser is now known as justanotheruser
tromp has joined #bitcoin-wizards
ThomasV has joined #bitcoin-wizards
tromp has quit [Ping timeout: 256 seconds]
gielbier has quit [Quit: Leaving]
nuke1989 has joined #bitcoin-wizards
adam3us has joined #bitcoin-wizards
adam3us has quit [Ping timeout: 272 seconds]
yoleaux has joined #bitcoin-wizards
ThomasV has quit [Ping timeout: 272 seconds]
justanotheruser has quit [Ping timeout: 240 seconds]
AaronvanW has quit [Ping timeout: 250 seconds]
dEBRUYNE has quit [Quit: Leaving]
adam3us has joined #bitcoin-wizards
adam3us has quit [Client Quit]
AaronvanW has joined #bitcoin-wizards
AaronvanW has quit [Changing host]
AaronvanW has joined #bitcoin-wizards
justanotheruser has joined #bitcoin-wizards
wallet42 has quit [Quit: Leaving.]
seg has quit [Ping timeout: 240 seconds]
warren has joined #bitcoin-wizards
seg has joined #bitcoin-wizards
MoALTz has quit [Ping timeout: 256 seconds]
seg has quit [Ping timeout: 240 seconds]
Emcy has joined #bitcoin-wizards
Emcy has quit [Changing host]
Emcy has joined #bitcoin-wizards
p15_ has quit [Ping timeout: 256 seconds]
seg has joined #bitcoin-wizards
ThomasV has joined #bitcoin-wizards
dEBRUYNE has joined #bitcoin-wizards
dEBRUYNE has quit [Client Quit]
c-cex-yuriy has joined #bitcoin-wizards
jonasschnelli has joined #bitcoin-wizards
damethos has quit [Remote host closed the connection]
damethos has joined #bitcoin-wizards
jonasschnelli has quit [Excess Flood]
jonasschnelli_ has joined #bitcoin-wizards
atgreen_ has quit [Ping timeout: 250 seconds]
AaronvanW has quit [Ping timeout: 260 seconds]
tromp has joined #bitcoin-wizards
atgreen_ has joined #bitcoin-wizards
droark has quit [Ping timeout: 240 seconds]
riclas has joined #bitcoin-wizards
tromp has quit [Ping timeout: 272 seconds]
ThomasV has quit [Ping timeout: 240 seconds]
SwedFTP has quit [Ping timeout: 245 seconds]
Quanttek has joined #bitcoin-wizards
dEBRUYNE has joined #bitcoin-wizards
adam3us has joined #bitcoin-wizards
adam3us has quit [Client Quit]
hashtag_ has quit [Ping timeout: 260 seconds]
Giszmo has joined #bitcoin-wizards
atgreen_ has quit [Ping timeout: 250 seconds]
nivah has quit [Ping timeout: 240 seconds]
hashtag_ has joined #bitcoin-wizards
kristofferR has joined #bitcoin-wizards
damethos has quit [Quit: Bye]
arowser has quit [Quit: No Ping reply in 180 seconds.]
arowser has joined #bitcoin-wizards
<instagibbs>
Does ZK pathfinding refer to the intermediate points not finding anything out, or the sender/receiver not finding out route path, or?
shesek has quit [Ping timeout: 260 seconds]
Quanttek has quit [Ping timeout: 256 seconds]
adam3us has joined #bitcoin-wizards
shesek has joined #bitcoin-wizards
<jl2012>
just to clarify, the "version byte" in sipa's talk is part of scriptPubKey, not the witness?
justanotheruser has quit [Ping timeout: 256 seconds]
brg444 has joined #bitcoin-wizards
frankenmint has joined #bitcoin-wizards
Giszmo has quit [Ping timeout: 272 seconds]
Giszmo has joined #bitcoin-wizards
Jeremy_Rand has joined #bitcoin-wizards
Guest78125 has quit [Changing host]
Guest78125 has joined #bitcoin-wizards
Guest78125 is now known as gwillen
Burrito has joined #bitcoin-wizards
justanotheruser has joined #bitcoin-wizards
<kanzure>
does anyone have a good explanation link for "encrypted transactions" and "committed transactions" from adam3us?
<kanzure>
there was an okay summary in a recent presentation by adam3us but uh i get the impression that he thinks there is a more elaborate explanation floating around out there
Casper- has quit [Read error: Connection reset by peer]
c-cex-yuriy has quit [Quit: Connection closed for inactivity]
<Guest53789>
instagibbs: onion routing is when the intermediate points know nothing about the payment
Guest53789 is now known as maaku
<maaku>
instagibbs: ZK pathfinding is when the sender doesn't know the network and so cannot construct the path ... it sends a query to its peers, and gets back an onion route + fee
<maaku>
*fee description
<maaku>
kanzure: linearized coin history is exactly the same as coin coloring, so there are probably many colored coin articles that explain the concept
<maaku>
kanzure: committed transactions was explained on the bitcointalk forum many years ago but my internet is too slow to find it (one of the first posts by adam3us, so that might be the best way to find it)
<kanzure>
how is linearized coin history exactly the same as colored coins? i thought linearized coin history requires miner validation of rules.
<kanzure>
i think at this point "coin coloring" and "colored coins" has been corrupted by a bunch of competing proposals, i am thinking mostly of the "put some extra data in OP_RETURN" proposals heh
<kanzure>
if you mean something else, then i'm not sure what
<maaku>
kanzure: nope it actually requires less miner validation -- a transaction needs to be valid even if one or more of its inputs is invalid
<maaku>
kanzure: a colored coin traces its asset type by following coins back to their genesis transaction, lining up input satoshis with output satoshis
<kanzure>
okay, so in this context, you definitely don't mean "OP_RETURN colored coins". heh.
<maaku>
most definately not
<maaku>
i mean the original colored coin proposals, where you draw a line from each input satoshi to each output satoshi
<maaku>
and by tracing history backwards like this, each satoshi gets assigned an asset 'color' based on what generating transactino it can trace itself back to
<maaku>
likewise for linearized coin histories, you trace each satoshi back and _only_ validate the inputs associated with it
<maaku>
this happens to require that miners reject any transaction containing a double spend, but allow transactions which have an invalid signature for an input (that input just doesn't contribute to the transaction)
<kanzure>
still confused. linearized coin history was about clients providing some history proofs that the transaction is valid. most colored coin proposals were merely about coloring of satoshis, not about increasing the validation load more towards payment senders...
<maaku>
i have no idea if this is written up anywhere ... i sortof fixated on linearized coin histories during his talk and figured this all out, then confirmed it during the q&a ... i sortof missed the rest of the talk because I was too busy working this out
paveljanik has joined #bitcoin-wizards
paveljanik has quit [Changing host]
paveljanik has joined #bitcoin-wizards
<maaku>
kanzure: correct. to my knowledge colored coins were never meant as a scaling solution. i'm just saying that the "linearized coin history" algorithm is exactly the same as the category of colored coin proposals explored by Alex Mizrahi
<maaku>
Alex Mizrahi / killerstorm
<maaku>
the proof that a coin is colored a certain way *is* a linearized coin history
<maaku>
petertodd's contribution is to point out that if you relax the validation rules a little bit, you can use this algorithm to get perfecdt sharding
mrkent has joined #bitcoin-wizards
bramc has joined #bitcoin-wizards
dEBRUYNE has joined #bitcoin-wizards
Burrito has quit [Quit: Leaving]
adam3us has quit [Ping timeout: 240 seconds]
Burrito has joined #bitcoin-wizards
atgreen_ has joined #bitcoin-wizards
Starduster_ is now known as Starduster
adam3us has joined #bitcoin-wizards
eudoxia has joined #bitcoin-wizards
MoALTz has joined #bitcoin-wizards
pandabearit has quit [Ping timeout: 272 seconds]
melvster has quit [Quit: Leaving]
JackH has joined #bitcoin-wizards
Jeremy_Rand has quit [Read error: Connection reset by peer]
eudoxia has quit [Quit: Leaving]
melvster has joined #bitcoin-wizards
matsjj has quit [Remote host closed the connection]
nubbins` has joined #bitcoin-wizards
Jeremy_Rand has joined #bitcoin-wizards
ThomasV has quit [Ping timeout: 272 seconds]
JackH has quit [Ping timeout: 240 seconds]
CubicEarth has joined #bitcoin-wizards
Jeremy_Rand has quit [Ping timeout: 256 seconds]
dEBRUYNE has quit [Ping timeout: 256 seconds]
oldbrew has joined #bitcoin-wizards
mrkent has quit []
ggreer has quit [Changing host]
ggreer has joined #bitcoin-wizards
JackH has joined #bitcoin-wizards
mrkent has joined #bitcoin-wizards
mrkent has quit [Read error: Connection reset by peer]
dEBRUYNE has joined #bitcoin-wizards
CubicEarth has quit [Remote host closed the connection]
LeMiner2 has joined #bitcoin-wizards
LeMiner has quit [Ping timeout: 246 seconds]
mrkent_ has joined #bitcoin-wizards
SgtStroopwafel has quit [Read error: Connection reset by peer]
CubicEarth has joined #bitcoin-wizards
c0rw|zZz is now known as c0rw1n
SgtStroopwafel has joined #bitcoin-wizards
e0 has joined #bitcoin-wizards
<e0>
any buddy up for answering a dumb question?
<e0>
body
matsjj has joined #bitcoin-wizards
<coinoperated_rob>
I can offer to read a dumb question uncritically, no guarantees on a quality answer tho.
superman_ has joined #bitcoin-wizards
bendavenport has quit [Quit: bendavenport]
bendavenport has joined #bitcoin-wizards
brg444 has quit [Quit: Page closed]
<amiller>
e0, just ask!
<e0>
sorry, got districted
<e0>
why does OP_CHECKSIG include the subscript of scriptpubkey in the input of the scriptsig?
fkhan has quit [Ping timeout: 250 seconds]
<e0>
is there some security benefit I am missing?
superman_ has quit [Ping timeout: 252 seconds]
fkhan has joined #bitcoin-wizards
fkhan has joined #bitcoin-wizards
fkhan has quit [Changing host]
fkhan has joined #bitcoin-wizards
bramc has quit [Quit: This computer has gone to sleep]
Quanttek has quit [Ping timeout: 246 seconds]
<e0>
anyone?
<arubi>
e0, I'll only try and answer because I think this wasn't a dumb question at all, though really I don't believe I'm in a place to answer questions in this channel, so be advised. No, I don't think you're missing anything. I do think though that it's nice to be able to tell a signer that doesn't keep track of past transactions what it is that she needs to input, and have her commit by a signature to it. Only issue is, she is still in the dark
<arubi>
wrt actual amounts.. so she might be signing away coins as fees, even though she things she's just sending coins to addresses that she agreed to
<arubi>
again, reiterating, I'm in no place to answer these type of questions here..
<e0>
It seems to me the most important things to sign are txid, output_index and some subset of the spending outputs
<e0>
thanks
<arubi>
e0, again, not all signers keep track of inputs. this is a problem for them. they can't blindly sign whatever transaction is presented to them, even though they know they're signing for outputs that they agreed to
eudoxia has joined #bitcoin-wizards
<e0>
when you say signers, you mena someone that holds some Bitcoins and wishes to spend them?
<arubi>
yes.
bendavenport has quit [Quit: bendavenport]
bendavenport has joined #bitcoin-wizards
belcher has joined #bitcoin-wizards
ThomasV has joined #bitcoin-wizards
Yoghur114 has quit [Remote host closed the connection]
hashtag_ has quit [Ping timeout: 240 seconds]
ThomasV has quit [Ping timeout: 272 seconds]
Guyver2 has quit [Quit: :)]
ghtdak has quit [Quit: WeeChat 1.4-dev]
ghtdak has joined #bitcoin-wizards
brg444 has joined #bitcoin-wizards
dEBRUYNE has quit [Ping timeout: 256 seconds]
TBI_ has joined #bitcoin-wizards
TBI has quit [Ping timeout: 240 seconds]
GGuyZ has joined #bitcoin-wizards
CubicEarth has quit [Remote host closed the connection]
CubicEarth has joined #bitcoin-wizards
CubicEarth has quit [Remote host closed the connection]
CubicEarth has joined #bitcoin-wizards
a5m0 has quit [Remote host closed the connection]
GGuyZ has quit [Quit: GGuyZ]
Erik_dc has quit [Remote host closed the connection]
CubicEarth has quit [Remote host closed the connection]