< morcos> sipa: what did you think about my last comment on 8610. i think that alleviates both issues and doesn't cause the concern suhas was worried about
< gmaxwell> oh god, does zapwallet not backup the wallet before zapping like salvage does?
< jonasschnelli> gmaxwell: heh. Yes. It copies all relevant wtxs into a vector vWtx (memory), EraseTx everything, does plenty of stuff (upgrade/rescan) and then try to write those vWtx txes back.
< jonasschnelli> There is a reasonable high risk that you will end up with a wallet without any wtxs.
< jonasschnelli> (risk of loosing comments)
< luke-jr> gmaxwell: 9188: how to get results from testing, before I stop it to test other stuff?
< luke-jr> something to grep for?
< luke-jr> jonasschnelli: got a patch for you .. :x
< luke-jr> anyone can flood testnet? :x
< * luke-jr> grumbles at whoever found blocks and cleared his flood
< bitcoin-git> [bitcoin] s-matthew-english opened pull request #9223: unification of Bloom filter representation (master...patch-10) https://github.com/bitcoin/bitcoin/pull/9223
< jonasschnelli> luke-jr: Thanks. Will have a look ai
< jonasschnelli> at it
< jonasschnelli> From what I saw when i cross read the code, you moved it to a Layout?
< bitcoin-git> [bitcoin] ivdsangen opened pull request #9224: Define FD_SETSIZE for all architectures (master...unix-compilation) https://github.com/bitcoin/bitcoin/pull/9224
< * jtimon> notes that the supposedly distuptive https://github.com/bitcoin/bitcoin/pull/8493 hasn't needed rebase for a long time...
< luke-jr> jonasschnelli: yes, I reconstructed the widgets using standard interfaces so it should adapt to any environment reasonably
< luke-jr> jonasschnelli: I wonder if the feerate line should figure out its scale independently from the rest
< luke-jr> it doesn't really have a metric to compare with the other two
< layman01> ok simple question [txid][in][out][sig][locktime] if i put extra data [txid][in][out][sig][locktime][something] does it auto invalidate a tx or just ignores 'something' and pushes it through
< layman01> what i mean is. older clients that never understood nlocktime. do they store nlocktime as arbitrary data even though they dont know what the extra bytes after the tx actually do
< sipa> every client understands nlocktime
< sipa> and no, you can't just append more data to transactions
< sipa> that would be a dos attack if that data is unverifiable
< sipa> segwit adds extra data to transactions
< sipa> but it uses a new format with optional fields, and it gets stripped out when relaying to old clients
< layman01> "that would be a dos attack if that data is unverifiable" - so no possible way to just add random data. or just morally avoided but possible
< luke-jr> wouldn't current nodes just ignore it (and relay the tx without it)?
< layman01> EG [txid][in][out][sig][locktime][receipt number:123]&[thank you for shopping at walmart]
< layman01> not physically possible in any way to have it locked in the blockchain
< layman01> WITHOUT using the "output as message" trick (within the tx)
< gmaxwell> layman01: the blockchain is NOT free file storage, it's carefully designed to avoid allowing people to dump their porn collections in it, if it were possible to do what you describe (it isn't as far as we know)-- we'd consider it a serious bug and would work diligently to fix it.
< layman01> gmaxwell, so where will you store your confidential payment commitments
< layman01> where is the bip/document information that stops extra data after signatures/locktime. eg what mechanism prevents extra data being added
< gmaxwell> the structure of the protocol. There is just no 'extra' place to put it.
< gmaxwell> layman01: if something is _confidential_ it should not be in the public blockchain. If something is a commitment it can be commited to using the existing signatures or existing outputs without adding any data at all to the blockchain.
< layman01> gmaxwell sound familiar: "CT is possible due to the cryptographic technique of additively homomorphic commitments. As a side-effect of its design, CT also enables the additional exchange of private "memo" data""
< BlueMatt> layman01: do note that CT only exists in implemented form in non-public blockchains
< gmaxwell> layman01: the private memo data is maigical and takes no size at all.
< BlueMatt> also, that ^
< layman01> but im asking how can extra data be added. how can gmaxwell also make output values private onchain.. if data cant be added..
< gmaxwell> Otherwise it wouldn't have been interesting.
< gmaxwell> layman01: CT's memo data doesn't add any other data at all. (also, even if it did: CT isn't part of Bitcoin-- though the memo data wouldn't have made sense if it added data, so I wouldn't have done it if it did)
< BlueMatt> layman01: think of it kinda like pay-to-contract-hash: there is data there, but it takes no extra room compared to not having it (well, pay-to-contract-hash is just a commitment, whereas CT is more, but whatever)
< * luke-jr> wonders if sipa is still working on sign-to-contract :x
< luke-jr> layman01: the payment protocol has an out-of-band mechanism for memos btw
< layman01> out-of-band.. i need to research that :D
< BlueMatt> * gribble :No such server
< BlueMatt> nanotube: :'(
< BlueMatt> lol, helgrind is so slow that it makes my node think its nTimeOffset needs to be adjusted by 3 minutes
< layman01> any link to 'out-of-band' documentation, instead of asking google and spending ages trying to find info
< gmaxwell> I think some of the recent changes to smartptr may have slowed down valgrind.
< luke-jr> layman01: BIP 70
< layman01> ok so bip70 is still using the [output] part of a tx as the messaging tool (from my quick brief read of it) not adding data after [sig][nlocktime]
< layman01> anyone with a current testnet open and about to do a tx, able to just add some random bytes after the raw tx to see what happens?
< gmaxwell> layman01: you've misunderstood BIP70.
< gmaxwell> It doesn't put message data in the transaction at all.
< layman01> well my question is about putting messages into a transaction. that gets locked into a block. that gets distributed over a network. so i dont know why anyone is guiding me to stuff thats not about messages added to a transaction
< layman01> plus i only took a few seconds to see the word output mentioned a few times. i know that outputs can be used to write messages but again my question was about messages not using the output area
< gmaxwell> 14:11 < gmaxwell> layman01: the blockchain is NOT free file storage, it's carefully designed to avoid allowing people to dump their porn collections in it, if it were possible to do what you describe (it isn't as far as we know)-- we'd consider it a serious bug and would work diligently to fix it.
< layman01> i know the morals. i know bitcoins ethos i know what its meant for. im asking about the possibility of adding data.
< gmaxwell> As far as we know it's not possible to do what you're asking. If, due to some phenominial bug, it were possible it would be a _serious_ bug and patches to block it would be issued as fast as possible.
< BlueMatt> layman01: have you seen pay-to-contract-hash?
< layman01> so is the only way to use another unused opcode (like segwit did).. but safeguarded against happening due to mining pools not having consensus to allow funky tx's into block
< layman01> bluematt, im looking while on here. but got interupted due to bip70 that didnt answer my question
< BlueMatt> layman01: there are lots of answers depending on what your actual use-case is....problem is youre asking for a solution to a specific question to which there is no answer.....maybe go to #bitcoin and try again except start by stating waht, exactly youre trying to do
< layman01> trying to see if there a way someone can fill the 'weight' area with bloat but not using 'outputs' to do it. theres a debate elsewhere, some say it can be done some say it cant. im just trying to figure who is right
< gmaxwell> You seem to be unable to take no for an answer, so I'm going to bet that you're going to remain unenlightened.
< layman01> its not a 'accept' no... its a why 'no' i need answering
< sipa> transactions consist of inputs and outputs. if you want to increase their size, you'd need to put it in either of those
< layman01> 'because bitcoin not designed that way' is an empty answer too
< gmaxwell> Because extra data just isn't permitted, it's ignored. Nodes understand the data that they're parsing and they'll ignore any extra data that isn't actually part of the transaction, stripping it out.
< gmaxwell> (or treating the whole transaction as corrupted, depending on what you did.)
< BlueMatt> layman01: ahh! see now, thats a question: the answer is "no, treating the witness space as 'free' isnt true - witnesses are counted just like the rest of the transaction and, really, should be seen as a part of the inputs, not extra data"
< gmaxwell> ^ by segwit nodes, by non-segwit nodes, segwit transactions aren't handled at all unless stripped of witness data-- they would be seen as corrupted if not witness stripped.
< luke-jr> if it's part of a block, it's actually impossible to add the extra data at all because after the locktime, it will begin parsing the subsequent transaction implicitly
< BlueMatt> that, too
< layman01> so the mechanism that prevents it is the parsing data into classes with known lengths of bytes for each element/namespace/variable and then ignoring/dropping the remainder it does not recognise
< sipa> right, nodes decode all messages they receive, and send them on in a form that the receiver understands
< gmaxwell> Yes, or, in some contexts treating it as corrupted and dropping the whole thing. Segwit blocks are handed to non-segwit nodes by first stripping out the witness data so they'll accept it.
< sipa> they're not just relaying the transactions or blocks as just bytes
< luke-jr> layman01: you can put anything inside the scripts within the transaction, but that doesn't change with segwit
< luke-jr> or rather, miners can*
< gmaxwell> The whole idea of a transaction as "bytes" is a too limited mental model. It would be like understanding numbers as a series of strokes on paper. :) Bytes are one way of representing a transaction, but when a transaction comes in the bytes are decoded and turned into a different in memory form. Then when they go out again they're converted back into bytes in a form sutiable for the reciever.
< nanotube> BlueMatt: ? >_>
< BlueMatt> nanotube: better now :)
< layman01> so baseblock/base class (not using official terms) only has [txid][incount][in][val][outcount][out][value] and witness class has [wtxid][witcount][witness][nlocktime] and nothing can appear after nlocktime on the blockchain because of it.. right?
< layman01> just double checking
< sipa> layman01: transactions don't contain a txid
< sipa> the txid is just the hash of the (non-witness) serialization of the transaction
< BlueMatt> also witnesses dont have witcount
< BlueMatt> its implicit
< BlueMatt> or wtxid...
< layman01> ok i know in the [output] different op codes can be set at different lengths. is there any opcode or any other class variable that has adjustable/non restricted lengths
< sipa> layman01: you should just study the documentation on this
< nanotube> BlueMatt: ah ok :)
< BlueMatt> nanotube: literally 2 seconds after that gribble re-connected
< nanotube> heh good timing :)
< layman01> sipa i would but the documentation is very loose and all over the place,
< sipa> layman01: you're free to help improve things, but this is not the place to ask for a basic explanation
< sipa> this channel is for discussing development
< luke-jr> layman01: there aren't different classes
< layman01> i heard it wasnt. i was told this place is where the close minded devs live who only think about themselves, just like the mailing list. just like every other place that the devs hang out in. like its a cabin fever experience where devs only want to speak to other devs and only agree with other devs and never talk to the community...
< sipa> layman01: please
< layman01> but goodnight anyway
< luke-jr> layman01: many of us are also in #bitcoin
< sipa> i answer questions there on a daily basis
< bitcoin-git> [bitcoin] TheBlueMatt opened pull request #9225: Fix some benign races (master...2016-11-lockfixes) https://github.com/bitcoin/bitcoin/pull/9225