< jtimon>
petertodd: regarding your last comment on the removign ISM thread...do you mean restoring ISM and then adding your new rule as a SF?
< jtimon>
is the point to remove ISM later with a coordinated HF?
< BlueMatt>
-rw------- 1 matt matt 1.7T Nov 16 16:44 /home/matt/.bitcoin/debug.log
< BlueMatt>
lol
< shangzhou>
gmaxwell: i did some search this morning at baidu. Searched "c1726ccc50635795c942c7d7e51d979c4f83a3d17f8982e9d02a114a15fef419" only one result (a thread http://8btc.com/thread-41510-1-5.html) someone use Avast complain that bitcoin 0.13.1 win exe downloaded from bitcoin.org was blocked by the avast. Search something like "bitcoin 0.13.1 win exe" top one is
< sipa>
veleiro: my guess is that you have too little memory
< veleiro>
sipa: youre probably right. i'm so sure to doing make -j4? it uses too many resources is my guess
< veleiro>
i just did a normal 'make' and it was a success..
< veleiro>
s/i'm so sure/i'm so use
< veleiro>
thanks~
< luke-jr>
#bitcoin is the support channel btw
< veleiro>
sorry luke-jr, its a big community now days. i didnt mean to bloat this chan
< luke-jr>
np, just clarifying for next time
< bitcoin-git>
[bitcoin] mruddy opened pull request #9175: remove script checking dependency on checkpoints (master...script_check) https://github.com/bitcoin/bitcoin/pull/9175
< bitcoin-git>
[bitcoin] jtimon opened pull request #9176: Globals: Pass Consensus::Params through CBlockTreeDB::LoadBlockIndexGuts() (master...0.13-chainparams-loadblockindexguts) https://github.com/bitcoin/bitcoin/pull/9176
< bitcoin-git>
[bitcoin] jtimon opened pull request #9177: NOMERGE: WIP: Support block signed custom testchains (master...0.13-blocksign) https://github.com/bitcoin/bitcoin/pull/9177
< petertodd>
jtimon: no, I mean, making chains other than the existing one invalid unless they follow the new rules
< petertodd>
jtimon: that still allows reorgs - it's not a checkpoint - but allows you to remove all the ISM logic.
< petertodd>
jtimon: of course, by "allows reorgs" - it mainly only allows truly massive reorgs, but I think that's sufficient to keep this from being a checkpoint
< morcos>
petertodd: yes that is what i was saying as well, i just don't know how to do that efficiently
<@wumpus>
what is the proper way to pass arguments to the secp256k1 configure script that is invoked by bitcoin's?
<@wumpus>
oh nm I can just pass "--with-asm=arm --enable-experimental" to the outer configure and it works. doh
<@wumpus>
... I'd been manually patching configure.ac all that time :-)
< luke-jr>
hehe
<@wumpus>
never tried as I expected it to croak on unknown arguments
< luke-jr>
there's an argument to make it not even warn :D
< instagibbs>
Chris_Stewart_5, so malleability in this context is not txid malleability
< instagibbs>
rather witness malleability. Some joker relayer could stuff transactions with junk data and the transaction is still valid
< Chris_Stewart_5>
instagibbs: I still don't understand the 'empty byte array' thing, and I also can't seem to find where this empty byte array is pushed onto the stack in the codebase
< Chris_Stewart_5>
The way I read BIP146, it's almost saying that you cannot place a OP_FALSE onto the stack unless OP_CHECKSIG had as input an empty byte array as a signature, but of course that doesn't make sense
< bitcoin-git>
bitcoin/master d8274bc Jonas Schnelli: Add compile and link options echo to configure
< bitcoin-git>
bitcoin/master a8b2a82 Wladimir J. van der Laan: Merge #9156: Add compile and link options echo to configure...
< bitcoin-git>
[bitcoin] laanwj closed pull request #9156: Add compile and link options echo to configure (master...2016/11/configure) https://github.com/bitcoin/bitcoin/pull/9156
< instagibbs>
Chris_Stewart_5, not sure how you are confused here: "If an OP_CHECKSIG is trying to return a FALSE value to the stack, we require that the relevant signature must be an empty byte array."
< instagibbs>
if a checksig is to fail, signatures must be false as well
< instagibbs>
false aka ""
< sipa>
Chris_Stewart_5: it is not talking about OP_FALSE, but about a FALSE returned by checksig
< morcos>
cfields: yeah i ran a longer test and your new branch doesn't really provide any benefit but the old one still provides a significant improvement
< Chris_Stewart_5>
sipa: "any BIP66-compliant non-empty byte array but not a valid signature" - this means that it is not a valid signature wrt to the public key in the script, right?
< Chris_Stewart_5>
Is the only difference between CheckSignatureEncoding & IsValidSignatureEncoding the LOW_S check & trivially passes the empty byte array as a sig
< jonasschnelli>
Do I understand it right that one of the key benefits of the shared_ptr transition are the concurrency benefits with less locking?
< sipa>
that is a potential future advantage
< BlueMatt>
sipa: concept ack+1000
< wumpus>
also less copying
< gmaxwell>
No.
< jonasschnelli>
and less copis
< BlueMatt>
to all of them
< sipa>
but less copying is the immediate reason
< gmaxwell>
Thats an abstract advantage of shared pointers.
< jonasschnelli>
Okay.
< gmaxwell>
But right avoiding copies is that it accomplishes here.
< jonasschnelli>
So performance and memory? Right?
< sipa>
the second one may be more controversial, as it affects the wallet code significantly, making CWalletTx not inherit from CTransaction anymore, and move it to a field
< cfields>
sipa: is there any specific part of the first that you think needs extra scrutiny/testing?
< wumpus>
sipa: YES
< sipa>
wumpus: YES as in "do it" or YES as in "it's more controversial"
< wumpus>
CWalleTx is pretty much the example of an abuse of inheritance
< wumpus>
in OOP
< gmaxwell>
wumpus: that was exactly my response.
< sipa>
ok, glad you agree on that
< jonasschnelli>
Yes. Also, is there a reason for the extra CMerkleTx inheritance?
< sipa>
jonasschnelli: abuse of C++
< wumpus>
wallettx should *contain* a line-level tx, plus metadata
< jonasschnelli>
heh
< sipa>
jonasschnelli: meaning you don't need to copy the interface
< sipa>
and then inlining CTxInWitness is to just simplify the code
< sipa>
(which is likely a small performance regression for non-witness txn, but an improvement for witness txn)
< sipa>
if no further comments on that, i'm done with the topic
< jonasschnelli>
While were at it, we should also remove "main.h" and "txmempool.h" from wallet.c (slightly OT) to avoid the circular dependency.
< wumpus>
no comments, i think it's the way forward
< sipa>
jonasschnelli: why is that a circular dependency?
< jonasschnelli>
sipa: ack
< gmaxwell>
why isn't it all done and merged yet? :P
< sipa>
jonasschnelli: main and txmempool should not depend on wallet
< sipa>
but wallet depending on main seems perfectly expected for me
< wumpus>
wallet is allowed to depend on stuff in libbitcoin_server
< wumpus>
I think we can discuss this outside the meeting? other more urgent topics?
< sipa>
ah, i understnad
< jonasschnelli>
Yes. Outside the meeting.
< sipa>
yes, let's discuss design at another time
< jonasschnelli>
morcos had the topic proposal "priority"
< morcos>
Lets talk about potential for account or priority removal (2 separate topics)
< sipa>
agree on topic
< jonasschnelli>
#action account or priority removal
< jonasschnelli>
#topic account or priority removal
< gmaxwell>
lol
< jonasschnelli>
:/
< morcos>
I think luke-jr was the main proponent of keeping priority around, so if he's not here, maybe we need to postpone further discussion
< morcos>
but it was my hope that we could all be in agreeement that it serves not much of a function any more
< morcos>
Perhaps we can set a target for 0.15 if 0.14 is too close, but it would be nice to remove ALL of the priority code
< morcos>
it would clean a lot of things up
< wumpus>
I think that ship has already sailed?
< BlueMatt>
morcos: ACK, but maybe 0.15
< BlueMatt>
deprecate more formally in 0.14
< wumpus>
I mean, we merged some stuff on the way for priority removal already
< morcos>
BlueMatt: that makes sense to me
< BlueMatt>
wumpus: not even eligius is doing any priority selection now...at the time maybe luke could have argued for it, but now.....
< sipa>
we removed priority estimation
< jcorgan>
is there any empirical data on miner behavior?
< morcos>
wumpus: i mostly agree, but the removal of priority estimation was because it wasn't functional any more, so it was an easier decision
< sipa>
all that is left is priority based mining, i think
< sipa>
if it serves no function (and maybe we need a bit more data on that), it should be equally easy imho
< gmaxwell>
I agree, I think any desire to keep it around could be answered by intelligent automatic use of fee delta. But this is going to get rehashed with luke later anyways. I think it's likely that everyone who regularly attends the meetings except luke agrees.
< morcos>
there is also the free transactoin and rate limiting code
< wumpus>
users can still set prioritizetransaction
< achow101>
does priority estimation even work? estimatepriority just gives me -1 regardless
< sipa>
achow101: priority estimation is removed
< morcos>
achow101: thats why it is removed for 0.14
< sipa>
achow101: the RPC remains for backward compatibility, but is a stub
< gmaxwell>
jcorgan: some had been collected in the past when it was defaulted to off. general result is that its not used ~anywhere anymore.
< wumpus>
so if prioritization on some criterion that is not fee it can still be implemented outside of bitcoind
< morcos>
it works, its just correctly telling you that no priority is high enough to get you mined quickluy
< achow101>
ah, i see
< wumpus>
heh
< morcos>
back in a couple min
< jtimon>
so I thought we were waiting on 0.14 for removing the priority, now we wait for 0.15?
< wumpus>
is there any reason to hurry?
< sipa>
jtimon: there seem to be at least 4 components to "removing the priority", i'm not sure they all need to happen simultaneously
< sipa>
(rpc, estimation, mining, relay)
< jtimon>
wumpus: no, any reason to wait ?
< wumpus>
I'm sure no one is really waiting for it to be removed, it can be removed part by part and 0.15 is a fine target
< gmaxwell>
relay is the only one I really care much about, because it currently causes bandwidth wasting relaying around junk that won't get mined.
< jtimon>
if people want to work on that, I don't see why they should wait
< wumpus>
jtimon: there are always other "priorities"
< MarcoFalke_web>
Can we disable relay by default for .14?
< jonasschnelli>
ack on DEFAULT_RELAYPRIORITY = false; for 0.14
< gmaxwell>
I'd support that, if we don't go further.
< sipa>
agree
< MarcoFalke_web>
What do you mean with "go further"?
< wumpus>
disabling by default always makes sense as a first step
< gmaxwell>
MarcoFalke_web: remove the code entirely.
< MarcoFalke_web>
#action DEFAULT_RELAYPRIORITY = false; for 0.14
< wumpus>
even if you rip out the code two days later...
< jtimon>
ok, I see, disable for 0.14 first what you want to remove for 0.15, that makes sense
< sipa>
ok, account removal?
< MarcoFalke_web>
next topic
< morcos>
wait i'm confused
< gmaxwell>
uh oh.
< morcos>
what are the proposed changes to relay
< morcos>
that priority doesn't let you skip the rate limiting
< morcos>
ok nm, ignore me. we are proposing that you always have to have minrelaytxfee
< gmaxwell>
Yes.
< jonasschnelli>
#topic "account removal"
< morcos>
i don't think thats going to help too much with junk, but agree it would be good change
< gmaxwell>
also, the help text for relaypriority is wrong/confusing. :P
< MarcoFalke_web>
I think we already have a pull open for this #7729
< morcos>
so the idea would be we have to have labels first
< morcos>
maybe for a release or two
< jonasschnelli>
morcos: what would be your approach for the removal-transition?
< morcos>
and then we coudl remove accounts?
< wumpus>
if people are ok with that proposal I'll go forward with it, but there's always so little attention on wallet related changes, let alone deprecating features
< wumpus>
morcos: yes
< instagibbs>
yes labels would have to come first
< morcos>
i mean i wish we could just rip them out, they're terrible. but it seems like people still depend on them
< gmaxwell>
I think I had just managed to miss 7729.
< gmaxwell>
Doing both lavels and accounts means more breaking API changes, no?
< MarcoFalke_web>
wumpus: You mentioned that this may cause problems when people use the account AND label api?
< wumpus>
MarcoFalke_web: there may need to be protection against that, yes
< gmaxwell>
morcos: most of the time I see them mentioned, they are being used as labels.
< wumpus>
MarcoFalke_web: though the same already happens if you use accounts and the GUI
< wumpus>
MarcoFalke_web: and there is no protection against that either
< jtimon>
can't we replace accounts with labels all at once?
< gmaxwell>
morcos: and people are confused when the accounts centric behavior shows up... or, alternatively, they're confused when they don't control "from" addresses (that they're not seperate wallets).
< jtimon>
it's not like we haven't been warning against the use of accounts for ages
< wumpus>
can we first *agree* on the label api?
< instagibbs>
jtimon, at some point I don't think people believe the deprecated warning
< sipa>
jtimon: go review 7729 (and i should do the same)
< instagibbs>
we should put scary ascii art :)
< gmaxwell>
so proposed action: everyone go comment on 7729.
< instagibbs>
action yes
< morcos>
ok, lets all read 7729 again and discuss on there
< instagibbs>
ack
< morcos>
damn i type too slow
< jtimon>
sipa: right
< gmaxwell>
yea, it sounds great.
< instagibbs>
also who uses labels that we talk to? dooglus?
< jonasschnelli>
Removing the accounting system entirely will be difficult (especially old wallet migration)
< wumpus>
whether to rip accounts at the same time as introducing labels is for later discussion, none of this is hard to implement, but deciding what API we want is more difficult
< wumpus>
jonasschnelli: no, it's not difficult at all
< wumpus>
jonasschnelli: you could even keep the accounting records around and just ignore them and treat previous accounts as labels instead
< gmaxwell>
^ is what I expected.
< sipa>
just the concept of 'balance of a label/account' disappears, not the ability to selectively list transactions affecting labels/accounts
< jonasschnelli>
I once did it in a test branch and it took me a long time to get it right... but maybe I was overcomplicating stuff there
< MarcoFalke_web>
I think dooglus use case would be covered by the new label api, but better someone ping him on the pr
< wumpus>
jonasschnelli: it's mainly a matter of deleting code
< jonasschnelli>
Right. I removed it with no labels migration
< gmaxwell>
I expected the account->label change would mostly be a matter of getting rid of balance related functionality. And otherwise not much perhaps beyond some new label centric features.
< sipa>
jonasschnelli: i think you're overcomplicating
< wumpus>
gmaxwell: yes
< wumpus>
gmaxwell: and just to be claear *account* RPCs are renamed to *label*, basically
< sipa>
jonasschnelli: it's literally just removing the balance RPCs, and then dropping the 'from account' field in send RPC, and renaming the rest account->label
< wumpus>
yes
< gmaxwell>
(e.g. of 'obvious' additional features: multiple labels on items, being able to label a single transaction without labling any involved addresses)
< wumpus>
well at first it just implements the GUI label API, which doesn't allow labeling transactions either
< wumpus>
I think that's a whole different thing
< gmaxwell>
yep. makes sense.
< jonasschnelli>
you can label addresses but not transactions, right?
< wumpus>
right
< jonasschnelli>
We have a comment feature for transaction
< jtimon>
isn't the move call also affected (if we still have that)?
< morcos>
perhaps as an immediate step, we could more forcefully declare accounts unsupported and deprecated for 0.14
< jonasschnelli>
(which is sadly not really used and exposed)
< morcos>
so that in the course of adding labels, we don't have to worry about any edge case mixing of the 2
< gmaxwell>
morcos: that would be negative for the many people who use accounts as labels today, however.
< wumpus>
first introduce labels
< morcos>
gmaxwell: yeah but i don't mean we're actually going to change it, i just worry that in the course of adding labels around accounts we'll give ourselves extra work, but maybe not.
< wumpus>
only then I'll agree on doing anything more to deprecate accounts
< wumpus>
if we don't move forward for labels, we'll stay in this state forever
< gmaxwell>
I need to read the PR to comment more!
< instagibbs>
2 spooky
< instagibbs>
any other topics?
< wumpus>
making more noise about removing accounts before we have a labels API will just make people (such as dooglus) panicked
< * gmaxwell>
looks at btcdrak pining #joinmarket and contemplates ^ :P
< gmaxwell>
okay, I think we should take the proposed action of everyone reading and commenting on 7729 and move to another subject.
< jonasschnelli>
I guess he's afk
< wumpus>
yes
< gmaxwell>
Or otherwise, we could instead engage in the age old art of completely uninformed combat.
< morcos>
you want to talk about block size?
< jtimon>
morcos: are you saying remove accounts before labels or just do both at the same time (to not worry about incompatibilities between the 2)?
< gmaxwell>
"I haven't read 7729 but I oppose any change that causes blindness in small children!"
< petertodd>
gmaxwell: I didn't read your last comment, but ACK
< jtimon>
other topics?
< jonasschnelli>
If there are no other topic, we could talk about "auxiliary block requests" if some are interested in it?
< gmaxwell>
jonasschnelli: will that cause blindness in small children?
< * BlueMatt>
petitions for one more review on #9075
< gribble>
https://github.com/bitcoin/bitcoin/issues/9075 | Decouple peer-processing-logic from block-connection-logic (#3) by TheBlueMatt · Pull Request #9075 · bitcoin/bitcoin · GitHub
< gmaxwell>
jtimon: it provides hot and cold running blocks.
< sipa>
gmaxwell: yes, through xkcd 378
< jonasschnelli>
jtimon "auxiliary block requests" is a requirement for SPV
< instagibbs>
BlueMatt, thanks, added to queue
< jonasschnelli>
It allows you to request blocks during IBD... which not getting validated
< morcos>
jonasschnelli: is there some more general description of how all that would work. i started to look at it, but i wasn't sure what the high level design was
< instagibbs>
ACK morcos I couldn't grasp immediately
< jonasschnelli>
Hmm... I can write a paper?
< morcos>
it doesn't have to be formal
< jonasschnelli>
It's simple: you ask your node, "giveme blocks D, F, G", node downloads blocks "D, F, G" and pass it though the signals with validate=fale"
< BlueMatt>
jonasschnelli: note that I'm working to remove fForceProcessing/etc from ProcessNewBlock...please do not pass the blockRequest object all the way in...
< gmaxwell>
I have to admit I expirenced some groan related to "oh no, yet another block fetching modality" -- but the application of being able to on demand randomly request blocks is perfectly reasonsable. More description would be helpful.
< jonasschnelli>
It uses all the available mechanisms.
< BlueMatt>
jonasschnelli: I'd kinda prefer this not call AcceptBlock at all...do we need to store the block or can we just pass to wallet?
< jonasschnelli>
It just "prioritize the requested blocks"
< sipa>
overall concept ack, but i think the implementation will need to change with the ongoing network processing refactors
< gmaxwell>
BlueMatt: seems foolish to download blocks twice... which would happen if we didn't store them.
< BlueMatt>
hum, true
< jonasschnelli>
BlueMatt: Right. We could factor out the on-disk-storing part
< BlueMatt>
still, would be nice to not store unless we need to
< wumpus>
it needs to get the chance to store it, atl east
< gmaxwell>
^ yep.
< BlueMatt>
gmaxwell: we could also use the needs-download logic in the p2p logic to dedup download
< sipa>
BlueMatt: it would integrate into some callback for downloaded blocks, i would guess
< gmaxwell>
Interaction with pruning seems somewhat complicated.
< BlueMatt>
that way the p2p logic could decide to hand to ProcessNewBlock...or not
< wumpus>
there may be further policy not to store it, e.g. based on pruning and such
< BlueMatt>
gmaxwell: thats part of my concern
< wumpus>
but for a full IBD you'd really want to pre-fill blocks
< BlueMatt>
just seems kinda broken to have the block-processing logic process a block which it explicitly doesnt want
< gmaxwell>
BlueMatt: but the main application now is a node that starts off with a spv mode wallet while it syncs up in the background. Such nodes will likely also be pruned.
< wumpus>
it will likely want it later
< sipa>
i guess there should be a separation of "which blocks to download" and "which blocks to process" logic
< sipa>
where the second can ask the first
< jonasschnelli>
I think to make it work with pruning is not very hard... just step after step
< BlueMatt>
wumpus: yes, I'm saying if we have a full-spv mode then the p2p logic should be able to not pass it to ProcessNewBlock....alternatively it can choose to do so if it thinks block-logic needs it
< wumpus>
could e.g. store it for later processing
< wumpus>
discarding by default would be stupid, at least
< BlueMatt>
wumpus: sure, but we have logic to figure out if we want a block or not, already
< BlueMatt>
jonasschnelli: note that I have a pr to change the stuff there to deserialize blocks into shared_ptrs, so passing it over to wallet should use that
< BlueMatt>
#9014, though its blocked on #9075
< gmaxwell>
blocks as sharedptr, hurrah
< jonasschnelli>
BlueMatt: okay. Though #9171 aims to be a wallet free PR
< sipa>
BlueMatt: note that after 9125, deserializing into a share_ptr is literally just "std::shared_ptr<const CBlock> ptr; ss >> ptr; "
< BlueMatt>
sipa: cool
< jonasschnelli>
more topics? 8m to go.
< wumpus>
*crickets*
< Chris_Stewart_5>
jonasschnelli: What is the use case for that? Why request the full block if we aren't validating?
< sipa>
Chris_Stewart_5: light wallet support
< gmaxwell>
Chris_Stewart_5: so we can scan it for wallet transactions.
< instagibbs>
Chris_Stewart_5, you download blocks based on age of your wallet
< jonasschnelli>
Chris_Stewart_5: allow receiving and sending transactions in "client" mode
< sipa>
Chris_Stewart_5: the ability to use the wallet before you're fully synced
< instagibbs>
"Where did my money go" <---
< wumpus>
let's take basic questions to outside the meeting
< Chris_Stewart_5>
This is alt solution to BIP37 then, or complementary?
< gmaxwell>
Chris_Stewart_5: bip37 _utterly_ destroys privacy, and would waste bandwidth if you're later going to need the block for verification anyways.
< jonasschnelli>
Chris_Stewart_5: its a safer solution then BIP37...
< gmaxwell>
(BIP37 is also vulnerable to txn being hidden from you)
< wumpus>
yes, BIP37 is a bad idea, we're not going to use it in core
< Chris_Stewart_5>
Yes I understand that part, I'm trying to piece together how new spv mode will function i guess.
< wumpus>
(bad idea with untrusted peers at least, and that's the use case here)
< jonasschnelli>
I think it could have it's reason when connected to a BIP150 authed trusted peer. But only then.
< wumpus>
any other topics?
< wumpus>
the meeting is derailed
< wumpus>
otherwise better to close it
< instagibbs>
3 minutes, no topics, bound to
< MarcoFalke_web>
#endsmeeting
< jonasschnelli>
#endmeeting
< lightningbot>
Meeting ended Thu Nov 17 19:57:22 2016 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
< sipa>
jonasschnelli: yes, thanks to jameson lopp
< jonasschnelli>
achow101: US? is that the place where they just abandoned politics?
< instagibbs>
Chris_Stewart_5, I'm a new full node, wallet is a week or two old. Then you can grab the last two weeks of blocks and find payments
< achow101>
jonasschnelli: yeah, that one
< instagibbs>
meanwhile background you're still validating
< gmaxwell>
jonasschnelli: political discussion to ##bitcoin.
< Chris_Stewart_5>
What about bandwidth usage? Doesn't this require much more bandwidth? Not a concern?
< gmaxwell>
achow101: the meetings stop for nothing except almost everyone being gone at once. :P
< wumpus>
gmaxwell: well I think this meeting will stay derailed no matter waht, there's no way to un-log what is logged :)
< jonasschnelli>
Chris_Stewart_5: if you want to do a full validation, you need to block anyways.
< jonasschnelli>
So you have some already downloaded blocks around the tip
< Chris_Stewart_5>
and if you don't?
< jonasschnelli>
You waste bandwidth
< jonasschnelli>
which can be okay.
< wumpus>
Chris_Stewart_5: it's just a different compromise
< gmaxwell>
Chris_Stewart_5: besides, fetching blocks is 14kb/s ongoing (28kb/s perhaps soon)-- most people running bitcoin core can handle that without batting an eye.
< jonasschnelli>
either you waste pricavy or bandwidth... you can choose.
< wumpus>
right
< instagibbs>
even if you don't want to catch up, it's still better than bloom filters or centralized nodes
< Chris_Stewart_5>
jonasschnelli: If we are removing BIP37 there isn't a choice.
< gmaxwell>
STOP
< gmaxwell>
die
< gmaxwell>
okay, now that you are all dead...
< wumpus>
no one is *removing* BIP37
< gmaxwell>
^ that.
< jonasschnelli>
heh
< jonasschnelli>
(rofl)
< wumpus>
can people stop FUDing and panicking about everything we do?
< wumpus>
thank you
< achow101>
panic panic
< gmaxwell>
When in danger or in doubt run in terror, scream and shout.
< wumpus>
we're just nopt using BIP37 for the light wallet mode in bitcoin core. If you want to use it in your wallet go ahead.
< wumpus>
it's a big internet and you don't need to do what we do
< jonasschnelli>
Chris_Stewart_5: </panic mode> you can use BIP37 with plenty of other wallets, but when using Core, we don't want scarifies privacy over because of some GB bandwidth
< bsm1175321>
I'm interested in making an update to BIP37 to improve light wallet security...
< gmaxwell>
Maybe someday BIP37 goes away, but only if it were replaced with something better for the things that use it now. There are proposals but at the moment no one is actively working on them.
< jonasschnelli>
That's IMO impossible..
< wumpus>
many people only use their bitcoin wallet with wifi so could care less about bandwidth usage
< jonasschnelli>
Maybe Bloom Filter Commitments
< wumpus>
they care about privacy, though
< jonasschnelli>
People are downloading a 10GB movie just to rent it for 24h... why would they not be willing to download 10GB to get financial privacy?
< sipa>
bsm1175321: the only proposal i know that improves it is pretty radically different (bloom filter commitments)
< wumpus>
yeah, it's simply a choice/compromise, I don't understand what is so difficult about understanding that
< jcorgan>
why interpret ambiguity in a way that gives the speaker the benefit of the doubt when you can construe anything they say in the worst possible way to reinforce your pre-existing conclusions?
< gmaxwell>
jonasschnelli: the filter commitment scheme can also be done without the commitments. (just loses the censorship resistance).
< bsm1175321>
sipa: I'll read up. Any links? I'm also interested in UTXO set commitments.
< bsm1175321>
Also perfectly happy with something pretty radically different.
< jonasschnelli>
gmaxwell: do you have a post or paper about this?
< gmaxwell>
jonasschnelli: the post describing the commited filters mentions that it can be done without the commitment. The only thing the commitment adds is the inability for nodes to lie about the filter content. Which is good, but it doesn't have to be delivered right away.
< bsm1175321>
sipa: thanks!
< jonasschnelli>
Okay. Thanks for the link sipa
< gmaxwell>
My view is that it would best be accomplished by implementing it without the commitment but in a way that would be sutiable for commitment later.
< gmaxwell>
also, as an aside, cuckoo filters are likely a better data structure for this than bloom filters... but there is a big area for research here.
< bsm1175321>
+1 on cuckoo filters. Waaaay faster and the performance characteristics are more understandable (one fewer parameter)
< gmaxwell>
segwit also opens up a new option, which is just fetching full blocks without witnesses.
< gmaxwell>
If segwit were used exclusively the size of a full block without the witness would be about 500k... not exactly as small as a filter, but still perfectly private.
< sipa>
jcorgan: what was that a response to?
< bsm1175321>
I wonder if some kind of oblivious transfer protocol would be practical for light wallet privacy?
< jcorgan>
?
< jcorgan>
oh, earlier, that was about Chris_Stewart_5 comment
< jcorgan>
a snark that lost its context when too many other comments flew by while i was typing
< Chris_Stewart_5>
jcorgan: I misinterpreted wumpus comment about 'not using' BIP37 in core as 'removing' it and apparently that triggered everyone ;). Thanks for the support though, some one has to ask the dumb questions :-)
< sipa>
meownow: it was later proposed as a BIP, and implemented in #707
< gribble>
https://github.com/bitcoin/bitcoin/issues/707 | Implement BIP 14 : separate protocol version from client version by gavinandresen · Pull Request #707 · bitcoin/bitcoin · GitHub
< jtimon>
BlueMatt: I guess if we can maintain the printing of the error without much disruption that would be nice, but I don't really know how important this is for bip22, maybe luke-jr has an opinion on this?