< morcos>
jonasschnelli: yes, thats what i meant, just wanted to let wumpus know if he preferred to have those for 0.12, that was fine by me
< morcos>
jonasschnelli: did you see my question about it seemed like you were only allowing that for "send" txs, but any tx can be abandoned
< jonasschnelli>
What I don't like in the GUI is, that abandoned transactions are still in the tx-list, but don't count for the balance (obviously).
< morcos>
jonasschnelli: that is the same as it as always been. in 0.11 any tx not in the mempool counts as conflicted and in 0.11 and 0.12 all conflicted txs don't count towards balance
< morcos>
so while i agree that maybe this could be improved, i think its a much bigger change
< jonasschnelli>
Yes... somehow i think a transaction-list sum should be the balance.
< morcos>
if anything abandoning a tx causes the behavior to be exactly the same as the 0.11 behavior
< jonasschnelli>
okay... yes. Let's keep the listtransaction and GUI stuff for 0.13.
< jonasschnelli>
And your right,... listtransaction abandoned category only gets detected for "sending" tx.
< jonasschnelli>
(need to be fixed)
< wangchun>
where is the "bitcoin" classic 2MB patch? I've checked their master branch but MAX_BLOCK_SIZE remains at 1000000 bytes
< morcos>
wangchun: i'm not sure this is the right channel for that question, as this is for the Core implementation. But I think there are a couple of pull requests open on their github repo which have the changes.
< wangchun>
morcos: I only see BIP101 style doubling every 2 years from pull reqs but only start from 2MB
< wangchun>
From their intros on the website, it should be fixed 2MB right?
< morcos>
wangchun: sorry i didn't look at their actual code. i don't know what they are doing. I've been helping the Core team with segregated witness as I think it gives us the effective increase of 2MB with a much safer rollout
< morcos>
while at the same time fixing long standing issues and adding needed security toools
< morcos>
happy to help with any questions you have about that! :)
< btcdrak>
wangchun: they dont seem to have any code for it. However there is a 2MB patch in Core
< wangchun>
btcdrak: #6451 looks good to me. It would be nice if we mix this with segwit. May I have an update why many devs want to deploy segwit as a softfork?
< sipa>
wangchun: because a softfork does not require the entire world to agree
< btcdrak>
wangchun: a hard fork will take longer to deploy. Even if we do 2MB hard fork, segwit would deploy first
< sipa>
because it allows us to make progress right now, without needing to force one choice or another
< wangchun>
sipa: But Antpool/BW/BTCC already voted for 2MB, it shouldn't be hard to push that out right?
< sipa>
wangchun: that's 3 people, not the whole world
< sipa>
wangchun: for a hardfork not only miners have to agree
< btcdrak>
wangchun: all 5000 fullnodes must also upgrade
< wangchun>
Should we ACK Bitcoin Classic? I think it might be a good thing...
< sipa>
wangchun: segwit SF gives 2 MB blocks, but without forcing anyone to change
< sipa>
wangchun: what benefit does it have?
< wangchun>
If the Classic get succeed, we have 2MB, and then we merge it back into core, we have segwit
< wangchun>
win-win
< sipa>
that makes no sense
< sipa>
then you'll have 4 MB blocks, with all latency problems that causes, and still need to force the world to adopt a change
< wangchun>
With 2MB, we'll have 8MB blocks, that is better
< wangchun>
And it is not 8MB in fact. not every tx is p2sh
< wangchun>
much like 5MB or so
< sipa>
what block sizes are you confortable with?
< wangchun>
2MB+segwit would be nice
< sipa>
what effective block size are you comfortable wit
< sipa>
the size of blocks going over the wire
< wangchun>
5MB is good
< sipa>
well then you'll need a hard fork, and need to convince everyone to accept that
< wangchun>
I think hardfork is much more desirable as it makes many things cleaner
< wangchun>
I heard you guys want every coinbase tx to have an additional OP_RETURN vout, that is so ugly
< sipa>
there are alternatives to that, i am very open to discuss
< btcdrak>
wangchun: BTCC is selling advertising in the coinbase =__=
< wangchun>
i also know many people who want to see a hardfork version of segwit
< wangchun>
btcdrak: i know, if we enlarge coinbase string from 100 bytes to 256, they will be very happy
< wangchun>
btcdrak: actually in the past we also sold a few coinbases, for 1 BTC each
< btcdrak>
wow
< wangchun>
in 2013
< sipa>
wangchun: the problem is that for a hard fork, everyone has to agree precisely on what the new rule will be
< sipa>
wangchun: and that takes time
< JackH>
it could get ugly, and in worst case scenario put us back months if not everyone upgrades
< sipa>
a softfork is safe and possible with just miners accepting it
< sipa>
which is why we strongly favor softforks where possible
< morcos>
wangchun: Everyone in core would prefer to see segwit as a hard fork rather than a soft fork. but we take very seriously the notion that we should not be forcing the rules of bitcoin to change for people who might not agree
< sipa>
it does not rule out doing a hardfork later
< morcos>
wangchun: so hopefully one day, there will be widespread consensus about a hardfork, whether its cleaning up segwit or whether its a block size increase, or both or other things.
< morcos>
but given that we can get all the benefits of segwit without that, it seems clearly the right next step. it doesn't preclude everyone coming to agreement on some hard fork, but it allows progress to happen without waiting for that
< wangchun>
then we may consider support the classic hope it get 2MB to be deployed sooner than segwit
< wangchun>
but i think it is unlikely
< sipa>
we already have a test version of segwit up and running
< wangchun>
a race is better to everyone
< sipa>
wangchun: you can support a 2 MB HF, but you can only run it when you know everyone agrees
< sipa>
wangchun: you can run segwit immediately
< wangchun>
there will be a 95% threshold i suppose
< morcos>
wangchun: i think its great to announce you support 2MB HF blocks if thats what you want. but its risky to run code that will switch to that if only 75% of miners agree. it runs the risk of forkinig the network and creating two coins.
< morcos>
wangchun: they are proposing i believe a 75% or lower threshold. and of course that only measures miner support, not support from the rest of the community
< wangchun>
I agree 75% is not enough
< wangchun>
if 95% miner support it, i believe others will follow
< sipa>
wangchun: a hard fork requires everyone to agree, not just miners
< sipa>
wangchun: even 100% of miners cannot decide a hard fork
< wangchun>
if 95% miners support it, others have no choice :)
< helo>
there should be no "hopefully others will follow"
< helo>
others may not want to follow, and they may be right in not doing so
< wangchun>
5% hashrate cannot secure their own branch
< helo>
that doesn't mean they are incorrect
< petertodd>
wangchun: it's not a question about them securing that branch, it's a question of whether or not more blocks are added to it
< wangchun>
anyway practically, if we got 95% hashrate in one branch, the other branch is over
< sipa>
wangchun: not necessarily true for a hard fork
< sipa>
for a softfork, yes
< petertodd>
wangchun: 95% is probably high enough that's it's unlikely to end up with people being forked off, but that's not really certain in a hardfork case
< morcos>
wangchun: regardless of whether you support the 2MB HF, I'd like to encourage you to help us with the segregated witness soft fork.
< wangchun>
morcos: sure
< sipa>
wangchun: and input on where you want the witness commitment is very welcome
< wangchun>
witness commitment?
< petertodd>
wangchun: now, if we had a 100% threshold that might put us in a better place. It also might be good to get a small % of hashing power willing to mine empty blocks on top of the old chain in the event that some miners still mine it. (aka, 51% attack it to ensure it stays dead)
< sipa>
wangchun: segregated witness needs a 32-byte value somewhere in coinbase
< morcos>
i'd like to avoid the outcome where neither happens because people are too entrenched in having their solution. it seems to me that the only objection to segregated witness as a soft fork is what you said about it being ugly compared to doing it as a hard fork.
< sipa>
wangchun: this can go in an OP_RETURN output, or in the scriptSig
< wangchun>
scriptSig of course
< sipa>
wangchun: but others may not want to loose so much scriptSig space
< morcos>
but i think t hats a very small price to pay for being able to get it implemented. if we tried to do it as a hard fork it would be hard to get it rolled out in any reasonable time period.
< wangchun>
but the coinbase string max size limit should be lifted in the very next hard fork
< sipa>
wangchun: ok, but we can't do that now
< wangchun>
sipa: how many bytes? 32? 36?
< sipa>
32
< sipa>
plus a header
< wangchun>
header?
< sipa>
36 is ok
< sipa>
magic bytes to say "here follows the witness commitment"
< jl2012>
the "header" could be put in nLockTime
< wangchun>
hmm
< jl2012>
some 32 is the minimum
< wangchun>
it's only 100 bytes... we cannot have a header
< jl2012>
s/some/so/
< wangchun>
put it immeidately follow the height bytes
< petertodd>
wangchun: alternative to a header is to have it in a fixed position
< petertodd>
wangchun: I think that makes sense
< sipa>
wangchun: that is why i believe an OP_RETURN is easier to get accepted, even if it is uglier
< sipa>
immediately after the height is also possible
< wangchun>
i've talked to jl2012 earlier
< sipa>
ok
< wangchun>
if people want more bytes, put extranonce to op_return
< jl2012>
would it break some mining hardware?
< wangchun>
or do like what we do, put extranonce to nsequence
< wangchun>
jl2012: extranonce in nsequence is not breaking any hardware
< wangchun>
i suppose extranonce in op_return should be fine too
< morcos>
wangchun: i don't know how much all the miners talk to each other, but this seems a concern that affects them the most
< morcos>
perhaps it would be useful for them to discuss among each other
< wangchun>
so we have 4 bytes height + 32 bytes segwit + 44 bytes merged mining
< wangchun>
80 bytes
< wangchun>
20 bytes left for signature, no advertisement space for sell
< sipa>
wangchun: indeed, i thought the lack of ad space would be a problem
< wangchun>
4 bytes merkle branch length is a waste, 1 byte is enough, 4 bytes nonce is completely useless
< sipa>
wangchun: we're working on a replacement for the MM header
< sipa>
that can be used for more things
< jl2012>
it's the mm of namecoin?
< sipa>
yes
< wangchun>
sipa: namecoin is planning the same thing, you may want to talk to them
< sipa>
wangchun: i'm aware
< petertodd>
wangchun: potentially, the witness commitment could be arranged to also work for MM, as well as any other future commitment
< wangchun>
sipa: not just namecoin, we also have ixcoin, i0coin, groupcoin, 611, uno, huc, and some other dead ones
< jl2012>
they should only commit 32 bytes in bitcoin, and leave the rest of meta data in their own header
< wangchun>
anyway, it the size limit should be lifted in the next hard fork
< wangchun>
256 bytes is preferred
< wangchun>
satoshi likes decimals..
< sipa>
wangchun: that seems like a reasonable thing
< sipa>
but for now, we need a solution
< wangchun>
put everything in coinbase is acceptable
< wangchun>
BTCC and Antpool are not merged mining
< wangchun>
so i think they will be fine
< wangchun>
for those who do merge, 20 bytes for signature is just enough
< sipa>
i thought BTCC was the one who suggested not using scriptSig :)
< jl2012>
Samson told me that would kill their service
< wangchun>
You can told them a hard fork to make their service shining is not very far
< sipa>
we don't know that
< wangchun>
s/told/tell/
< sipa>
a hard fork will only happen if everyone agrees
< JackH>
it would be interesting to see how many nodes we loose in a hardfork
< wangchun>
BTCC still has 64 bytes for sale
< wangchun>
63 bytes
< wangchun>
extranonce1 cannot be empty, otherwise it may break some stupid stratum proxies
< Quent>
if you excuse my comment - - - interesting isn't it, the hierarchy, one can say developers are employed by miners as shown by this little chat, with miners employed by users, while at the same time, like a quantum particle, everyone holding and not holding power at the same time.
< Luke-Jr>
morcos: what? segwit softfork is so much cleaner than a hardfork
< midnightmagic>
:-(
< midnightmagic>
Quent: Highly offtopic for in here.
< morcos>
Luke-Jr: I wasn't referring to the act of forking but to what the protocol specification is at the end. By definition you can make anything you want as a hardfork, so clearly whatever optimal format is you could do that with a hard fork.
< Luke-Jr>
morcos: if we had 100% of Bitcoin users convinced to do either a hardfork or softfork for segwit, the softfork would still be better
< morcos>
Luke-Jr: b/c of rollout risk?
< Luke-Jr>
morcos: because of backward compatibility with present wallets
< Luke-Jr>
the ideal segwit structure would break current signatures
< morcos>
Luke-Jr: ok, perhaps you are correct that the case for doing a HF isn't as straight forward as i implied. Regardless, its academic. SF is clearly the only reasonable choice for segwit now.
< wangchun>
not just backward compatiblility, in the case of segwit
< wangchun>
segwit tx is anyone spendable to older clients
< wangchun>
imagine some 0-conf tx service that still running old software after the activation
< wangchun>
a hard fork is safer for them
< zookolaptop>
wangchun: could you explain how such an older, 0-conf-accepting client would be in danger in the soft-fork deployment?
< instagibbs>
wangchun, they will simply get trivially double-spent being left behind on the old chain
< instagibbs>
(in hard fork scenario)
< brg444>
right, they have to upgrade in both scenarios else they can get cheated. not sure I see the difference?
< wangchun>
i can send coins i can't move under the new rule
< zookolaptop>
wangchun: hm.
< instagibbs>
wangchun, in both hardfork/softfork, if user upgrades, great. In the non-upgraded scenario, they both have some drawbacks
< wangchun>
and if someone mine a block on the old fork, it can even get a confirm
< wangchun>
to old clients
< instagibbs>
then can certainly get confirmations on the dead chain
< instagibbs>
in hardfork
< wangchun>
as segwit-enabled tx flies on the new fork, the old fork would become a mess
< Luke-Jr>
wangchun: no, a hardfork does not make ANYTHING safer, EVER
< Luke-Jr>
and that's ignoring the fact that unconfirmed transactions are never safe
< wangchun>
Luke-Jr: softfork version of segwit != hardfork version of segwit, we don't have to use anyone can spend tx if it is a hardfork
< Luke-Jr>
wangchun: that doesn't matter though
< instagibbs>
wangchun, why do you care?
< instagibbs>
it's not your money
< Luke-Jr>
if it's a hardfork, those old nodes lose ALL security
< zookolaptop>
One fact that matters to me is that Ethereum has done a series of hard fork upgrades over the last year or so.
< zookolaptop>
I like to try to learn from empirical evidence.
< zookolaptop>
Although of course, you could still be right, and one or another lucky break or special condition allowed Ethereum to succeed at that where Bitcoin wouldn't be able to do the same. Who knows.
< wangchun>
many altcoins do hardfork upgrades regularly
< moli>
wangchun: yes, but they're altcoins with not as large markets as bitcoin
< zookolaptop>
I think it is easy for people, especially smart people, to convince themselves strongly of some belief, and paying attention to empirical evidence like that can help shake one's confidence.
< instagibbs>
a closer example would be Bitcoin in the first or second year and Ethereum
< Luke-Jr>
again, softfork segwit is superior to hardfork segwit even if both were equally possible
< moli>
i went through many hardforks with an altcoin, where devs can never get consensus with miners, have to use a closed source dirty trick
< zookolaptop>
moli: interesting. :-)
< zookolaptop>
moli: thanks for giving me yet more empirical evidence for my hoard.
< zookolaptop>
moli: was it just that the miners were unaware, disinterested, etc., or did the miners actively object to the change?
< zookolaptop>
I would assume it was the former.
< instagibbs>
Are you really surprised that Vitalik could get unanimous consensus for hardforks?
< instagibbs>
we know it could theoretically be done, but it's not the same
< zookolaptop>
Right, that's the limitation of trying to learn from empirical evidence: there are always reasons why the prior experience may not apply to your case.
< moli>
zookolaptop: i can tell you in pm if you want
< instagibbs>
in 6 years it'll def be interesting
< instagibbs>
Esp if Vitalik doesn't vanish :P
< brg444>
Bitcoin as a considerably stronger inertia than any other altcoins for very good reasons. It's important to take this in consideration when pondering the eventuality of a hard fork.
< Quent>
on the other hand bitcoin has stronger incentive based self interest than any other altcoin
< morcos>
any chance we could move this discussion back to bitcoin-dev? unless anyone wants to review #7296 or #7312 so we can move forward with getting 0.12 released?
< jl2012>
just for record, segwit tx are non standard to existing nodes
< instagibbs>
morcos, agreed, sorry
< Luke-Jr>
morcos: simply changing getrawmempool does not appear to fix the problems btw
< JackH>
if we hard fork, it would spiral the price down and all we have been working for could be reduced back to 100
< JackH>
as a Bitcoin business representative, this is THE most scary thing we can do with Bitcoin
< JackH>
especially since it all works so fine right now
< JackH>
and the perception of it at the end of 2015 started to really get more positive
< brg444>
JackH agreed, but unfortunately I'm worried this is being done on purpose
< brg444>
I'm very concerned with the prospects of a hard fork severely undermining the investors trust
< paveljanik>
Everyone can fork. Please remember this is dev list... You can fork on github easily...
< brg444>
That is why claiming that hard forks are cleaner from a technical standpoint is misleading and ignores the socio-economic nightmare they entail
< brg444>
paveljanik Right, I won't continue this discussion here
< Quent>
it has to be done, it was always intended, the only mistake is that this wasn't included in versions long ago
< Quent>
but then no one could foresee the atmosphere that developed in 2013
< JackH>
yeah the whole cleaner debate is just WRONG brg444
< JackH>
personally I would wait for payment channels and skip any blocksize
< JackH>
but, someone outside is influencing people to do a hardfork
< JackH>
very sad to see people following the sheep mentality
< brg444>
it should be done on sound technical grounds. a mere 100% increase in throughput is not valid reason to force every node on the network to upgrade, IMO
< Quent>
yes, satoshi is influencing them and they say you are the outsider jackh, those sort of comments do not assist
< JackH>
I am just saying it is not safe, period
< JackH>
therefore it should not be done
< JackH>
the system works perfect
< Quent>
you said outsiders influence them!
< JackH>
and payment channels solve all and any scale
< Quent>
that's nazi tactics
< Quent>
dehumanising etc
< paveljanik>
do you speak C++?
< brg444>
Quent Satoshi has left years ago, he should not influence anyone anymore and if he wish to do so then may he come back and provide input
< Quent>
satoshi laid out how bitcoin is to scale, what he stated then remains relevant
< instagibbs>
how do we call for mods again
< Quent>
omg, people have different opinions, we out to only groupthink here
< Quent>
ought*
< instagibbs>
it's completely off-topic
< instagibbs>
stop it
< Quent>
it was for quite some time, yet you said nothing!
< JackH>
Quent, stop telling people what Satoshi thought
< Quent>
what you afraid of? words?
< JackH>
you are not Satoshi
< JackH>
you dont know what he thought
< instagibbs>
!admin
< gribble>
Error: "admin" is not a valid command.
< JackH>
you were not even there back then
< instagibbs>
!mods
< gribble>
Error: "mods" is not a valid command.
< JackH>
your arguments should come from a technical perspective where you tell us WHY we need a hard fork
< Quent>
jackH, it's not even about satoshi
< JackH>
not that: Satoshi may have thought
< Quent>
2mb is nothing
< JackH>
then what is it about
< JackH>
exactly I agree
< Quent>
whats this obsession with no fork ever then?
< JackH>
2mb is a waste of time and excessively dangerous for absolutely nothing in return
< JackH>
why do you want a fork?
< Quent>
capacity?
< JackH>
how much
< Quent>
is this to be an irrelevant project or a world changing project?
< gribble>
Error: You don't have the #bitcoin-core-dev,op capability. If you think that you should have this capability, be sure that you are identified before trying again. The 'whoami' command can tell you if you're identified.
< JackH>
how many nodes can handle the load you think?
< instagibbs>
JackH, please stop feeding him
< JackH>
I am not, and he will understand why he is wrong
< Quent>
what sort of nodes?
< JackH>
this will end with a sound debate where he understands
< JackH>
full nodes, stop playing stupid, if you want this conversation
< JackH>
propagating nodes
< instagibbs>
#bitcoin or stop
< Quent>
are you talking basement nodes?
< JackH>
ok, on to bitcoin then
< Quent>
some basement kid?
< Quent>
or are you talking nodes which actually matter?
< JackH>
#bitcoin
< Quent>
checkmated were you?
< helo>
Quent: go toss a pebble if you want to change the world. this channel is for bitcoin core dev discussion.
< Quent>
helo, brg44, instagibbs and all the other trolls
< Quent>
you have no power in this chan!
< Quent>
so keep your authoritarian tounge
< Quent>
telling people to shut up
< brg444>
...
< Quent>
if the mod here wants to warn he is welcome to
< Quent>
if you who have been scaremongering for 3 years now want to debate you are welcome to
< Quent>
but dont try to silence me when I call your bullshit
< Quent>
as I called jackh out on his insinuation there is some outside influence
< Quent>
you have been deceiving for 3 years
< Quent>
and look where your deception has gotten us!
< Quent>
stand to light or shut your tongue
< instagibbs>
wumpus, please zap
< JackH>
and here I was, naive to think this guy was serious
< Quent>
you should have been more naive JackH to think man would do anything else but what is self evidently obvious and good
< Anduck>
please quit with the offtopic Quent
< Quent>
I said it all the way back, I said it when theymost started his games
< Quent>
because it applies to bitcoin first and foremost, what is self evidently good and in the interest of man shall prevail
< Quent>
you have the whole people up in arms
< Quent>
they hate rbf
< Quent>
they hate the breach of 0confs non 100% securtiy
< Quent>
they hate the rigidness in regards to the blocksize debate
< Quent>
what on earth you lot are thinking they understand not because it has no basis in reason or bitcoins design
< Quent>
but on what peter todd and peter todd alone has been feeding you for some 3 years now
< Quent>
with his character assasination attempts of gavin
< Quent>
at every opprotunity
< Quent>
with his hate for spv wallets, for oconf transactions, for all that makes bitcoin convenient
< Quent>
the way was lost in 2013 when the developers segregated themselves, isolated themselves to the mailing list and dividied themselves from the users, creating an extreme group think, to the point where the developers started thinking they are gods, they are in charge, they can order around, leading to the great wall which Jeff says is greatest he has seen in 20 years of open source development
< Quent>
we ought to learn from what has and is happening and forge a path forward where we can cooperate and do things better rather than enage in venemous accusations of socpupets or "outsiders" influencing etc
< paveljanik>
this looks like C# 8)
<@Luke-Jr>
Quent: please take this to #bitcoin or not at all
< morcos>
Luke-Jr: I think you'll have to be a bit more explicit as to what the problem is. but i think entry.GetPriority(chainActive.Height + 1) should always return the correct answer
< Luke-Jr>
zookolaptop: I do not see a reason to disclose that, and it seems possibly harmful to do so.
< Luke-Jr>
morcos: I haven't figured out what the problem is. At this time I am trying to extend the test to cover reorganisations
< morcos>
Luke-Jr: well modulo the change so that inputs included in blocks after the transaction originally entered the mempool won't age unless you are using 7149
< morcos>
Luke-Jr: ah! let me take a look at that again. 7149 should handle that properly
< morcos>
Luke-Jr: but you might be right that the code in master will not handle that correctly
< Luke-Jr>
I am testing on top of 7149
< morcos>
Luke-Jr: I flagged that originally with the code that got merged, but perhaps not clearly enough
< morcos>
Well 7149 is meant to work properly with that situation, but I can't guarantee it does. The difficulty of getting that right is why I keep saying 7149 is too complicated
< kanzure>
zookolaptop: and you just ignored my comment or something? what
< MarcoFalke>
morcos, if you still plan to squash 7296, you should do it now, I guess.
< kanzure>
zookolaptop: why should i even bother replying to you if you are going to ignore me? :-(
< morcos>
MarcoFalke: I have no preference as to whether it is squashed or not.
< zookolaptop>
kanzure: I'm sorry, which comment?
< morcos>
MarcoFalke: I've been trying to take the approach that changing the PR's less will make them more likely to get merged
< MarcoFalke>
But I don't like the SQUASHME in git blame either
< morcos>
MarcoFalke: :) eh... priorities
< MarcoFalke>
Let's just leave the SQUASHME out of the commits in the future. ;)
< zookolaptop>
kanzure: thanks for that!
< MarcoFalke>
wumpus, is there anything particular holding back 7296?
< kanzure>
zookolaptop: it is morally dubious for you to claim that the names of 2000000 authors would for some reason change the merits of the content. it's just wrong. stop wasting our time.
< morcos>
kanzure: (i'll keep this in core-dev for the time being since it is specifically about core development even if not technical) i disagree. and i sympathize with zooko's request.
< morcos>
however i dont think there is any easy way to satisfy his request
< morcos>
Bitcoin Core is not well defined
< kanzure>
what exactly do you think is not well defined?
< morcos>
I think it is reasonable in the interim to sign such messages Bitcoin Core but to be able to explain to people what the process for making a decision on them is
< morcos>
or who are the people that stand behind thme
< morcos>
these are things not that we want to hide, but that we don't have clear answers for
< morcos>
actually, on second though, this really shouldn't be in this channel
< kanzure>
i have no idea what you are talking about.
< kanzure>
yes.
< morcos>
not sure where to move it, but happy to continue elsewhere
< MarcoFalke>
#bitcoin ?
< kanzure>
i'll take a pm.
< morcos>
ha ha ha
< zookolaptop>
morcos: if you find an appropriate channel let me know. ☺
< kanzure>
morcos: convincing me in pm is useful because then i can resolve problems for you.
< morcos>
i don't know how irc works. can i just say /join #zookosquestion and then we can discuss there?
< kanzure>
yes, but i don't care about his question.
< zookolaptop>
kanzure: then you know what to do!
< zookolaptop>
Yes, I'll discuss this with morcos and whoever else would like to in #zookosquestion.
< kanzure>
your question has nothing to do with morcos' statement that he was trying to explain to me.