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
aaaaaa_ has joined #bitcoin-wizards
aaaaaa has quit [Ping timeout: 256 seconds]
jhogan42_ has joined #bitcoin-wizards
Guyver2 has quit [Quit: :)]
kenshi84 has joined #bitcoin-wizards
TheSeven has quit [Remote host closed the connection]
TheSeven has joined #bitcoin-wizards
instagibbs has quit [Ping timeout: 264 seconds]
instagibbs has joined #bitcoin-wizards
abpa has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
cluckj has quit [Ping timeout: 256 seconds]
cluckj has joined #bitcoin-wizards
rusty2 is now known as rusty
Sleepnbum has quit [Ping timeout: 246 seconds]
rex has joined #bitcoin-wizards
abpa has joined #bitcoin-wizards
aaaaaa has joined #bitcoin-wizards
abpa has quit [Client Quit]
aaaaaa_ has quit [Ping timeout: 256 seconds]
rex has quit [Quit: Leaving]
Ylbam has quit [Quit: Connection closed for inactivity]
mdavid613 has quit [Quit: Leaving.]
TheSeven has quit [Ping timeout: 245 seconds]
aaaaaa has quit [Ping timeout: 246 seconds]
TheSeven has joined #bitcoin-wizards
Chris_Stewart_5 has quit [Ping timeout: 246 seconds]
Emcy has quit [Read error: Connection reset by peer]
Emcy has joined #bitcoin-wizards
Emcy has joined #bitcoin-wizards
Emcy has quit [Changing host]
cyphase has joined #bitcoin-wizards
Emcy has quit [Quit: Leaving]
Emcy has joined #bitcoin-wizards
Emcy has joined #bitcoin-wizards
Emcy has quit [Changing host]
Chris_Stewart_5 has joined #bitcoin-wizards
CubicEarth has joined #bitcoin-wizards
Chris_Stewart_5 has quit [Ping timeout: 258 seconds]
Noldorin has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
trippysalmon has quit [*.net *.split]
DougieBot5000 has quit [*.net *.split]
cdecker has quit [*.net *.split]
Alanius has quit [*.net *.split]
epscy has quit [*.net *.split]
andrew4 has quit [*.net *.split]
null_radix has quit [*.net *.split]
Monthrect has quit [*.net *.split]
qawap has quit [*.net *.split]
Alanius_ has joined #bitcoin-wizards
trippysalmon has joined #bitcoin-wizards
andrew4 has joined #bitcoin-wizards
Monthrec- has joined #bitcoin-wizards
cdecker has joined #bitcoin-wizards
epscy has joined #bitcoin-wizards
DougieBot5000 has joined #bitcoin-wizards
qawap has joined #bitcoin-wizards
qawap has joined #bitcoin-wizards
qawap has quit [Changing host]
qpm has quit [Ping timeout: 248 seconds]
null_radix has joined #bitcoin-wizards
qpm has joined #bitcoin-wizards
windsok has quit [Ping timeout: 258 seconds]
cluckj has quit [Ping timeout: 248 seconds]
Sleepnbum has joined #bitcoin-wizards
Sleepnbum is now known as Guest2056
pro has quit [Quit: Leaving]
windsok has joined #bitcoin-wizards
CubicEarth has quit []
legogris has quit [Remote host closed the connection]
legogris has joined #bitcoin-wizards
mdavid613 has joined #bitcoin-wizards
mdavid613 has quit [Quit: Leaving.]
roidster has quit [Ping timeout: 258 seconds]
TheSeven has quit [Ping timeout: 240 seconds]
TheSeven has joined #bitcoin-wizards
Guest2056 has quit [Ping timeout: 255 seconds]
cluckj has joined #bitcoin-wizards
Guest2056 has joined #bitcoin-wizards
rusty has quit [Quit: Leaving.]
Guest2056 has quit [Ping timeout: 255 seconds]
n8wachT has quit [Quit: ☆ ¸ ★ . • ○ ° ★ http://n8cht.space ★° :. . • ☾ ☆ ¸ ´Impressive Star Fox. Now watch out for enemies in the asteroid field!´]
arubi has joined #bitcoin-wizards
Uglux has joined #bitcoin-wizards
Uglux has joined #bitcoin-wizards
Uglux has quit [Changing host]
dabura667 has joined #bitcoin-wizards
LeMiner has joined #bitcoin-wizards
nonaTure has joined #bitcoin-wizards
cluckj has quit [Ping timeout: 248 seconds]
PRab_ has joined #bitcoin-wizards
PRab has quit [Ping timeout: 268 seconds]
PRab_ is now known as PRab
BashCo has quit [Remote host closed the connection]
BashCo has joined #bitcoin-wizards
<adam3us>
i have been wondering that it's a pity there is no way (currently) to cut through chains of transactions that complete in the same block. ie c1 -> a,c2; c2-> b,c3 could be re-encoded as single tx c1->a,b,c3 with asymptotic saving of 50% of transaction space. it might be nice if there were a way to allow miners to transform the former into the latter.
BashCo has quit [Ping timeout: 248 seconds]
<adam3us>
gmaxwell was suggesting opt-in RBF could do that... broadcast both tx variants. it's a bit mimblewimble like in intent - collapse a useless tracing of temporary to same block ownership immediately flushed (the c2 change output)
<Taek>
adam3us: I think the hard part comes from the fact that the signature usually covers the whole transaction, therefore isn't valid unless you can reconstruct the original (assuming you can't simply request the original owner tore-sign)
<Taek>
Maybe there's some potential if you are more careful about exactly which data is signed
<Taek>
Do you have numbers about how much savings you could get?
<Taek>
er, what percentage of blockspace is typically consumed by cuttable txns
chjj has joined #bitcoin-wizards
<adlai>
how does oiRBF accomplish this
<Taek>
you have the original sender just create a new txn with a higher fee
<adlai>
so they have to stay online?
<Taek>
pretty sure
waxwing has quit [Ping timeout: 248 seconds]
<adlai>
dunno, they could ask the recipient if they want to send the coins elsewhere, maybe add this to the payment protocol
<adlai>
being online all the time is terrible, unless it's incentivised somehow
<Taek>
not super unreasonable, most of the time if you are connected enough to make a transaction you will have connectivity until the next block
<Taek>
much saner than all the time
<adlai>
and if the original senders are still online, and our miners are altruistic, why not go one further and reorg blocks for really ultimate cut-through?
<adlai>
(;
<adlai>
i mean, "chains of transactions that compete in the same block" are by definition impossible to cut through without cutting some gordian block
sdfgsdfg has joined #bitcoin-wizards
waxwing has joined #bitcoin-wizards
<Taek>
I don't understand what you are getting at, are you sayinf that oirbf wouldn't work for the arbitrary subset of txns where the original sender is still online? You could incentivize it too - less fees means some of what would have been fees can be given to the original sender
<Taek>
(by adjusting the change outputs in the replacement txn)
<adlai>
doesn't the intermediate recipient have to pay the original sender here? sure, the 'payment' can be elided into the cut, just verifying my understanding of what you said
<Taek>
unless the original sender is altruistic, yes
<adlai>
altruistic people turn off their computers to save the planet, mannn
<Taek>
but everyone wins overall b/c total fees paid goes down. (miners lose maybe? But assuming full blocks fee/byte is higher, congestion lower though. overall win I think still)
<adlai>
so evil^H^Hsensible miners will just ignore cut-throughs
<adlai>
btw Taek have you had a chance to read the spectre paper yet?
paveljanik has quit [Quit: Leaving]
* adlai
has been procrastinating this, looking for one of those gold-plated round tuitts
<Taek>
potentially. one could argue that supporting cutthrough makes bitcoin as a whole more useful for a fixed blocksize, increasing overall value
<Taek>
I did get to understanding spectre, today actually
<adlai>
one could argue a lot of things, such as "miners should voluntarily reduce the block size, to drive up fees, and then increase the block size gradually enough that users don't realize they can pay lower fees again"
<Taek>
well, the ordering parts at least
<Taek>
that's true I guess we're in vague territory now
<adlai>
you mean the partial ordering of blocks based on 'votes'?
<stevenroose>
A change in Bitcoin’s digital signature scheme used for signing transactions (currently ECDSA) could allow for up to two times as many transactions to fit in a block. This gain in efficiency is made possible by switching to Schnorr signatures. Adam Back explained, “We can make the transactions smaller. From the same block size, we can get more transactions if we use this different type of signature.”
<stevenroose>
Can anyone explain that?
<Taek>
spectre I think has two weaknesses: 1. runtime for adding a block, 2. tranasction fee structre seems highly abusable
<adlai>
stevenroose: in a nutshell, ecdsa signatures are larger than schnorr, and can't be aggregated.
<stevenroose>
With segwit, the only limiting factor for txs are the outputs, right? Which don't contain the signatures..
<adlai>
no, inputs are still counted, just separately (assuming you mean the proposed softfork in bitcoin)
<adlai>
they have an accounting which considers them as cheaper than the rest of the block data
<stevenroose>
oh yeah, that's right
<stevenroose>
Strange rule though, especially the arbitrary 1/4th factor
<stevenroose>
its like this, no? block size + witness size / 4 <= max block size
<adlai>
'''frankly my dear, i don't give a damn'''
<Taek>
naively, adding a block to the spectre dag is O(n^2) in the size of the dag. with some engineering-foo O(n) seems attainable but its not clear to me how much complexity is needed to do better than that. O(n) isn't good enough as there are 10 blocks per second
<adlai>
that's the beauty of proposing it as a softfork, luddites such as i can pretend it doesn't exist
<adlai>
"there are 10 blocks per second" << says what line of published, running code? :P
* adlai
thinks spectre would work wonderfully with a block every 42 seconds
<Taek>
well, the paper proposes that block rate
<adlai>
or maybe 23, that's a speshler numbler
<adlai>
sure, it's just a paper. back in the 21st c, people used paper for all sorts of strange
edvorg has joined #bitcoin-wizards
<Taek>
if you are doing blocks slower than network propagation speed, a huge number of problems evaporate. But confirmation times also go up a lot
<adlai>
ideally, you do blocks small enough that the entire thing can be softforked into bitcoin
<adlai>
otherwise it's all masturbation
<adlai>
(not that there's anything sinful about that)
<Taek>
can you soft-fork in a reduced b;pck time?
<Taek>
*block
<adam3us>
adlai Taek it's more of a payment processor / exchange use case. they have a hot wallet and are having withdrawals or payments in a stream to users. they could use a nagle algo (flush transaction at say 10 outputs or 30seconds. it should asymptotically halve their on-chain use. it might theoretically reduce fungibility a little bit as what goes on chain looks like c1->A,B,C,D,E-c5 instead of c1->A,c2; c2->B,c3; c3->C,c4; c4->D,c5
<adlai>
adam3us: don't payment processors and exchanges already /practically/ reduce fungibility, a lottle bit?
<adlai>
i don't think they'd care about some theoretical further reduction. the fee savings would speak to their hearts.
<Taek>
adam3us: oirbf seems like the simplest, most complete way to accomplish that then
<adam3us>
adlia well there's on chain fungibility visible to everyone and that'd go down a bit because there is some ambiguity between c1->A,c2; c2->B,c3 whether B was made by user controlling c2 or c2 was the exchange paying another user.
<adlai>
Taek: sf-aware miners exchange beads at the beadrate, blocks contain as many beads as possible. txs are sf-valid if they're in a bead-in-a-block, and bitcoin-valid once a block has enough empty space to quote the beaded txs so that old clients can see them
<adam3us>
Taek it's maybe not super simple because they'd be sending a stream: end c1->A,c2; then send c1->A,B,c3 then c1->A,B,C,c4 then c1->A,B,C,D,c5 etc and let the bitcoind opt-in RBF logic sort it out. That avoids introducing delay. The logic does have to monitor for which one makes it into a block and pickup where that leaves off. Eg when c1->A,B,C,c4 makes it into a block discard state c1->A,B,C,D,c5 and pickup from c4->D,c5; c5->E,c6 etc.
Alina-malina has quit [Ping timeout: 272 seconds]
<adam3us>
so bitcoind might be well placed to implement a sendnagle because it's anyway monitoring blocks. but a higher level library might struggle with that a bit
<kanzure>
i guess some bitcoind infrastructure to do opt-in RBF planning might be a friendly thing to implemet
<kanzure>
.. implement.
<adlai>
processors should be running bitcoind, and their in-house libraries should just use whatever's the most efficient interface
<adam3us>
re tear-off sigs, I would think maybe with MAST-like model you could sign different things, and you or miners decide after the fact which to reveal. however the problem here is you by definition dont know you're about to send B, or you'd send c1->A,B,c3 directly in the first place.
<kanzure>
adlai: unfortunately you might have to lower your expectations about what other people are likely to implement ;)
* adlai
is not about short-term Bitcoin development
<adlai>
*talking about
* kanzure
vanishes
<adlai>
expecto piscopum!
<adlai>
hm, maybe that one isn't valid yet
<adlai>
in case it's not clear, SFing a blockdag doesn't increase throughput, it aligns miner incentive
Alina-malina has joined #bitcoin-wizards
<Taek>
hmm. maybe a soft fork is possible. Inclusive protocols make that super annoying.
<adlai>
people who want higher throughput can use other layers or chains
<Taek>
or you just add boosters via other data pieces a la segit
* adlai
would bet a coin that it'll be an alt before a softfork... not sure about segwit, that's probably a riskier bet
<adlai>
(do any alts seg wits yet!?)
<adlai>
(that's right, i'll pay you an entire bitcoin to write and deploy the softfork. someday you'll regret not making me eat this hat!)
<Taek>
I am planning on launching a jute alt before migrating it to btc/sia regardless
<Taek>
at least tentatively
<adlai>
what's the latest draft/paper on jute?
Alanius_ is now known as Alanius
<adlai>
oh lawl, i asked for fiat when there's code already
Guyver2 has joined #bitcoin-wizards
<Taek>
jute has made a lot of progress, hoping to have a paper published soon
ManfredMacx has joined #bitcoin-wizards
<adam3us>
ltc is apparently working on segwit
jannes has joined #bitcoin-wizards
Alina-malina has quit [Ping timeout: 272 seconds]
Alina-malina has joined #bitcoin-wizards
<adlai>
adam3us: good to know, any idea what kind of fork they plan?
<adam3us>
soft but not using bip9 because they thought it interacted with merge mining.
kenshi84 has quit [Remote host closed the connection]
kenshi84 has joined #bitcoin-wizards
kenshi84_ has joined #bitcoin-wizards
kenshi84 has quit [Ping timeout: 258 seconds]
kenshi84_ has quit [Read error: Connection reset by peer]
kenshi84 has joined #bitcoin-wizards
Alina-malina has quit [Changing host]
Alina-malina has joined #bitcoin-wizards
kenshi84 has quit [Ping timeout: 246 seconds]
<adlai>
too bad
Starduster_ has joined #bitcoin-wizards
Starduster has quit [Ping timeout: 258 seconds]
CrazyLoaf has quit [Quit: Connection closed for inactivity]