00:38:08rodarmor:Is there a way to get a transaction into the memory pool and relayed throughout the network, but keep it out of a block, at least for some amount of time?
02:13:21Emcy:rodarmor why would you do that
02:14:42rodarmor:I was trying to think about a use case which would have data which is time-limited, so you want it to be generally available, but you don’t actually care if it ever makes it into a block, so why not do something to keep it out of the block to limit spam.
02:15:14rodarmor:But I kind of realized that block inclusion might be a useful anti-spam mechanism anyways, and generate additional revenue for miners, so I don’t think it’s a good idea anymore.
02:16:02rodarmor:I’m writing up a discription for the idea and post it on github, in case anyone is interested. It’s an idea for providing timely information about goods and services for sale for bitcoin.
03:17:31rodarmor:Maybe not appropriate for #bitcoin-wizards, but I would appreciate all feedback so I’ll post here: https://github.com/casey/beacontx
03:35:43fanquake_:fanquake_ is now known as fanquake
07:26:14Guyver2:Guyver2 has left #bitcoin-wizards
08:05:17wilhelm.freenode.net:topic is: This channel is not about short-term Bitcoin development | http://bitcoin.ninja/ | This channel is logged. | For logs and more information, visit http://bitcoin.ninja
08:05:17wilhelm.freenode.net:Users on #bitcoin-wizards: andy-logbot p15 wiretapped MoALTz_ profreid AaronvanW jtimon waxwing aburan28 woah koshii_ irc88 fanquake TheSeven adam3us1 Sangheili rdponticelli wumpus mortale zooko lacksfish Luke-Jr zenojis espes__ BrainOverfl0w RoboTeddy myeagleflies Adlai ebfull tacotime emsid Aquent rfreeman_w Burrito Dr-G2 Starduster kaene SDCDev Grishnakh Max_H3adr00m c0rw1n wizardofozzie dgenr8 DougieBot5000 digitalmagus spinza CodeShark artilectinc epscy OneFixt
08:05:17wilhelm.freenode.net:Users on #bitcoin-wizards: zwischenzug smooth BlueMatt jchp altoz Graet warren HaltingState LarsLarsen [Derek] @gmaxwell go1111111 devrandom heath samson_ @gwillen sl01 napedia grandmaster2 Graftec tromp_ andytoshi phantomcircuit lysobit Krellan TrollsRoyce jgarzik copumpkin dansmith_btc Fistful_of_coins artifexd _2539 michagogo lnovy tromp bbrittain weex gribble nanotube a5m0 EasyAt Transisto Kretchfoop Emcy jaekwon CryptOprah Muis Hunger-- wizkid057 nuke1989
08:05:17wilhelm.freenode.net:Users on #bitcoin-wizards: Guest42039 jrayhawk_ jasx shesek firepacket arowser BigBitz drawingthesun berndj [d__d] jcorgan yoleaux Iriez hollandais hguux livegnik Dyaheon MRL-Relay mappum jbenet zibbo_ kanzure petertodd optimator [\\\] pi07r K1773R Eliel HM amiller_ crescendo cfields btc_ kgk bobke iddo comboy NikolaiToryzin coryfields LaptopZZ Meeh poggy_ UukGoblin danneu catcow TD-Linux [Tristan] helo otoburb ryan-c mmozeiko roasbeef pajarillo Keefe Gnosis ahmed_vegas
08:05:17wilhelm.freenode.net:Users on #bitcoin-wizards: Logicwax so starsoccer midnightmagic kinlo pigeons lianj Apocalyptic mr_burdell fluffypony SomeoneWeird forrestv Anduck Taek42 asoltys @ChanServ phedny burcin lechuga_ abc56889 Alanius throughnothing harrow DoctorBTC [nsh] sipa
12:20:33lysobit:lysobit has left #bitcoin-wizards
12:23:58instagibbs:rodarmor: I'm no wizard but that sounds like a DDoS recipe. Nodes would be smart to not accept any of these messages.
13:10:59wumpus:sipa: I tried to test headers-first and this happened! http://showterm.io/c2ef65790f3bc306d01bd can you help? :-)
13:20:07wumpus:eh, should be in dev not wizards
18:37:04sipa:wumpus: dang; sorry, it was at your own risk
19:08:37Guyver2:Guyver2 has left #bitcoin-wizards
19:17:39mlilenium_:mlilenium_ has left #bitcoin-wizards
20:10:40andytoshi:i feel like somebody could really blow this guy's mind https://bitcointalk.org/index.php?topic=820614.0 with a bit of a group theory lesson, a n-of-n schnorr demonstration and maybe an n-of-m demonstration
20:12:54nsh:i feel like you may be that somebody
20:13:13andytoshi:lol, i might, in the next couple days
20:13:29nsh:* nsh smiles
20:14:41fluffypony:andytoshi: please pick up that gauntlet
20:16:11fluffypony:else if you'd prefer, please read his "BitcoinDark Teleport" paper
20:25:34gmaxwell:andytoshi: ed25519 uses a modified schnorr singnature IIRC, it might break threshold signatures.
20:26:50andytoshi:oh, that's right, it does point compression in a funny way :/ i'll have to look it up
20:27:26andytoshi:maybe you can do a standard schnorr then as a last step "ed25519-ify" it, idk
20:28:43gmaxwell:yea, it may be fine. IIRC one thing it did was include the pubkey in the message hash. (which prevents rearranging things so you can do a pubkey recovery, but I think doesn't break threshold signing, so long as you know the ultimate pubkey)
20:48:59sipa:gmaxwell: indeed, it includes the pubkey in the hahs purely for anti-malleability
21:05:48gmaxwell:We should probably formalize the security game for signature systems where its harder to forge a signature before you've ever seen a signature at all; as it's applicable to bitcoin and things like using hashes of pubkeys can get you that property.
21:08:22nsh:hmmm
21:15:34heath:heath has left #bitcoin-wizards
21:32:06heath:heath has left #bitcoin-wizards
21:46:33lmatteis:dear all. given that WebRTC is the only way to do true P2P in a web browser, i wonder if there has been any talk to integrate WebRTC capabilities in bitcoin-core
21:47:20nsh:bitcoin-core is not on the web. as far as anyone whose opinion matters is concerned, this is a perfectly acceptable state of affairs
21:49:35lmatteis:nsh: webrtc is a communication standard. it has the word "web" in it simply because it was initiated by web browser
21:49:47nsh:being glib, sorry :)
21:50:05heath:lmatteis: you aren't going to run chromium on your server
21:50:15lmatteis:but it could be a perfectly viable standard to use for broadcasting bitcoin transactions
21:50:58lmatteis:hrm, chromium has little to do with webrtc
21:51:03lmatteis:apart from implementing it
21:51:06gmaxwell:I've looked into doing this (having worked on webrtc some)... but a challenge there is that the minimum codebase for a datachannel outside of a browser is huge.
21:51:33gmaxwell:On the other of 100kloc. ... you need userspace sctp and dtls implementations among other things.
21:52:06gmaxwell:I hope and assume someone will eventually make a minimal implementation just for datachannels which will be easy to write a gateway for.
21:52:21nsh:sounds like a good summer of code project
21:52:34nsh:or whatever today's equivalent of that is, if that's not a thing any more
21:52:50heath::)
21:54:24lmatteis:gmaxwell: cool. the WebTorrent people have done something similar for bittorrent. whereas the bittorrent standard/network doesn't support WebRTC, the WebTorrent people have created sort of "bridge nodes" that work on the server and can bridge between WebRTC clients and bittorrent clients. allowing you to effectively do bittorrent in the browser
21:55:11nsh:could moot splitting off the code on the list ( https://groups.google.com/group/discuss-webrtc ) or ask how viably / soon it might be done maybe
21:56:22heath:lmatteis: i guess you are referring to the stun servers
21:56:31heath:surely someone has built one by now
21:56:52heath:i'm assuming most people are using google's atm
21:57:02heath:like they were 2 years ago
22:08:46lmatteis:gmaxwell: i'm not sure what the limitations you mention are. but wouldn't WebRTC be enough to at least broadcast transactions?
22:09:41sipa:lmatteis: the problem is that webrtc requires a *ton* of code
22:10:05sipa:and you don't want a bitcoin node to require a browser
22:10:28lmatteis:sorry, i didn't mean node. i'm thinking mostly a SPV client
22:10:39sipa:well what would the SPV client talk to?
22:10:52sipa:that other thing also needs to implement WebRTC
22:10:54lmatteis:other WebRTC clients
22:11:11sipa:SPV clients talking to eachother doesn't gain you anything
22:11:15lmatteis:and eventually "bridge nodes" to communicate to the bitcoin world
22:11:38sipa:then it's not really P2P, right? :)
22:11:54sipa:i see what you mean - and more transport protocols is always good, especially if they're optional
22:12:02sipa:but your question was about adding it to bitcoin core
22:12:32sipa:where we're particularly conservative about what gets into the codebase
22:13:19lmatteis:right perhaps not directly into bitcoin-core
22:13:45lmatteis:i'm just thinking because having full fledged wallets (no server side) in browsers is really elegant imho
22:14:58lmatteis:although i believe webrtc peers can only communicate if they're sort of "browsing" the same site
22:16:05kumavis:lmatteis: I missed the context, but I have some experience with webrtc
22:17:08kumavis:webrtc peers connecting from different origins (serverA.com and serverB.com) can still communicate
22:19:14lmatteis:ah interesting. although perhaps the server must provide ways for peers to find each other. meaning serverA must know of serverB existence
22:19:48lmatteis:do you know of examples of large networks of peers being built with webrtc?
22:20:15lmatteis:most the stuff i found was chat rooms running from a single server. still cool, but requires the site for the network to function
22:21:24nsh:.g federates webrtc
22:21:24yoleaux:http://bloggeek.me/webrtc-ends-like-email/
22:21:34nsh:*ed
22:22:22nsh:there's some talk of 'islands' but it seems to be mostly speculative
22:23:33lmatteis:http://www.slideshare.net/tsahil/webrtc-islands ?
22:24:06nsh:* nsh nods
23:08:28gmaxwell:webrtc still needs an introduction mechenism, alas. And stun/turn servers are usually needed. But sure, wallets in the browser should be using datachannels to talk to webrtc compatible bitcoin full nodes... it's just right now doing that isn't trivial. I should look at what webtorrent is doing, perhaps they've solved it.
23:09:16gmaxwell:There are other reasons to run over webrtc, other than working in browsers... it gives you a somewhat censorship resistant transport, ... it's easy to block all bitcoin traffic, blocking all webrtc would have more collateral damage.
23:09:48gmaxwell:So you're stuck analyizing traffic patterns ... and if you're not mining and don't care about 0conf you can basically make bitcoin traffic have any shape you want.
23:13:48nsh:pluggable transports for bitcoin traffic wouldn't be the worst thing in the world
23:13:55nsh:blockchain.ceo... heh
23:15:16lmatteis:gmaxwell: ah didn't even think of that reason
23:15:40phantomcircuit:i am the ceo of the blockchain
23:15:41phantomcircuit:i command you to send me all your bitcoins
23:15:50gmaxwell:nsh: well 'pluggable' can be as simple as things like matt's relaynetworkclient.
23:16:19gmaxwell:nsh: e.g. just speak traditional bitcoin p2p to bitcoind... and implement whatever protocol outbound you want.
23:16:28nsh:right
23:16:48gmaxwell:This is my prefered design. The result is maybe someday we use this to totally process seperate the networking.
23:17:47nsh:what advantage is there to process isolation between the network and wallet-handling?
23:18:02nsh:i guess it's a potentially nonzero security advantage
23:18:38Adlai:and modularity. a company could produce a better end-user wallet, while still reusing the rest of the software.
23:18:56nsh:* nsh nods
23:20:36gmaxwell:security, plus if you have multiple transports you could imagine someone DOS attacking one while the other runs... also on the most recently linux you can confine process down to the level of applying script that filter particular syscalls... so you can make exploitation of the network daemon completely harmless.
23:20:49phantomcircuit:Adlai, they can do that today, simply distribute with --disable-wallet
23:21:02phantomcircuit:nsh, it's a much greater than non-zero security advantage
23:22:58kumavis:lmatteis: ah sorry i missed your responses - I don't know of any large rtc networks, it seems there are problems establishing connections for some peers... I don't know enough about how networking actually happens to provide insight there
23:24:26kumavis:to establish a connection the peers must exchange an identifier, this is usually done via a signalling server but you could send this information over a side channel, e.g. here is a blob of text that I can use to find my peer, that the peer gave me over irc
23:25:48kumavis:I made a demo of an in browser multiplayer minecraft clone that used webrtc
23:27:03jgarzik:gmaxwell, ICYMI, bitpay's stuff has been using WebRTC, since our wallet needs rendezvous with other copay users, to collaborate on multisig
23:27:41jgarzik:There was no "chatter" protocol in existence for multisig proposals, so one had to be built
23:27:55kumavis:you can have apps running over looser network topologies using something like #scuttlebutt
23:28:29kumavis:some peers connected over rtc connected to other groups via some other connection
23:32:58phantomcircuit:kumavis, webrtc works great when it works and not at all when it doesn't
23:33:19phantomcircuit:iirc you can expect ~75% success rates
23:41:15Luke-Jr:phantomcircuit: 0% in my experience :x
23:41:58phantomcircuit:Luke-Jr, it works reasonably well if the rendevouz server is setup correctly
23:42:06phantomcircuit:but getting STUN setup correctly is black magic
23:47:22nsh:* nsh reads about http://openpeer.org/
23:47:59nsh:(friends don't let friends host their whitepaper on scribd)