<stellar-slack>
<graydon> we download one checkpoint at a time from history stores
<stellar-slack>
<graydon> a checkpoint contains 64 ledgers worth of txs, ledgers, results
<stellar-slack>
<sacarlson> and that one ledger I was told has 200k transactions in it?
<stellar-slack>
<jed> not one ledger one bucket has 200k or so entries
<stellar-slack>
<jed> graydon and it pulls these down in parallel? the testnet machine that is trying to catch up has 32+ aws processes running right now
<stellar-slack>
<graydon> yes it runs up to 32 downloads in parallel
<stellar-slack>
<jed> ok cool
<stellar-slack>
<graydon> (this is the subprocess-maximum, you can configure it up or down depending on how strong the machine is)
<stellar-slack>
<sacarlson> oh I would like that to configure it down. I've already set mine to use only one of my 4 cpu processors
<stellar-slack>
<sacarlson> I was looking into setting it to only use a limited amount of mem so it won't kill my system
<stellar-slack>
<graydon> MAX_CONCURRENT_SUBPROCESSES=4 or 2 or whatever
<stellar-slack>
<graydon> in the .cfg file
<stellar-slack>
<graydon> note this will slow down your catchup when you get out of sync, because it can't run as many curl or aws processes as it might like
<stellar-slack>
<sacarlson> cool thanks, will that also prevent it from using all my 8gb of mem?
<stellar-slack>
<graydon> no, I still don't know what's going on with it using all your memory
<stellar-slack>
<sacarlson> ok then I'll just have to make a cage for it as I can't have my system shutdown
<stellar-slack>
<graydon> can I get a config.log from your build directory? and/or maybe the output of ldd src/stellar-core ?
<stellar-slack>
<graydon> I've got a hunch that this has something to do with the surprising WAL behavior we're seeing in sqlite
<stellar-slack>
<sacarlson> sure but now the last build I went even more back that won't even start I dont' think
<stellar-slack>
<graydon> if you want a short-term fix I'd suggest trying to run a node on postgresql, though I'll keep digging at the sqlite problem
<stellar-slack>
<sacarlson> problem is my mss-server I never upgraded it to support postgresql yet.
<stellar-slack>
<graydon> ok, np
<stellar-slack>
<graydon> I have a short-term fix I can give you that'll make the WAL files significantly smaller (20x) but I'm still trying to find the root cause of the problem
<stellar-slack>
<graydon> it's not checkpointing, so .. ideally I'd like it to checkpoint properly!
<stellar-slack>
<sacarlson> ya I recall that wal problem that I think lab had might be that
<stellar-slack>
<graydon> yeah. huh ok so I just inserted a manual checkpointing operation and that works. I wonder why autocheckpoint doesn't work.
<stellar-slack>
<sacarlson> well I think if I spent two days I can upgrade multi-sign-server to run from postgresql, so maybe I should invest in that
<stellar-slack>
<graydon> I'll definitely get *some* fix in for this shortly. I just ... don't know how short-term a fix to put in, y'know?
<stellar-slack>
<sacarlson> yes it's a mater of what to invest time in. it's hard to know what has the most value over the short and long term
<stellar-slack>
<sacarlson> show me this manual checkpoint thing so maybe I can take care of it myself
<stellar-slack>
<graydon> it's a little bit of code. but um .. weird. it turns out if I just manually set the autocheckpoint pragma myself, to the same value it's supposed to have, it works.
<stellar-slack>
<sacarlson> cool good enuf
<stellar-slack>
<sacarlson> how do I configure it
<stellar-slack>
<sacarlson> oh that it's supposed to have
<stellar-slack>
<graydon> yeah weird eh? it's like I'm telling it the same value for a pragma variable that it already (supposedly) has, and by telling it, it works
<stellar-slack>
<graydon> grum
<stellar-slack>
<sacarlson> so it can't be too far off then
<stellar-slack>
<sacarlson> it has the value just didn't apply it yet
<stellar-slack>
<graydon> nope! I'm tempted to just post this and dig further on my own time. this will fix your problem.
<stellar-slack>
<graydon> (I think! still no idea why it's eating 8gb...)
<stellar-slack>
<monsieurnicolas> FYI on windows it takes 8 minutes to catch up and 7 MB of RAM
<stellar-slack>
<sacarlson> I can't really say what it ate up since my system was locked up for some time before I had any control to look at anything
<stellar-slack>
<graydon> yeah, on my mac too. I don't know what's going on there. I'm guessing sqlite is somehow either using an in-memory db or somehow the wal is eating a lot of memory or something.
<stellar-slack>
<sacarlson> ya before this problem stellar-core was so low on resources I couldn't even see it on the top apps screen
<stellar-slack>
<graydon> that's how we'd like to keep it :)
<stellar-slack>
<sacarlson> and I'm sure you will someday
<stellar-slack>
<graydon> ah
<stellar-slack>
<graydon> ok it was not the pragma. it was the prepared statement cache, I was right.
<stellar-slack>
<graydon> bleah.
<stellar-slack>
<graydon> so ... we actually need to clear the prepared statement cache any time we want the WAL to have a chance to checkpoint.
<stellar-slack>
<graydon> on sqlite
<stellar-slack>
<sacarlson> cool so one line of code and it's done? make sure if you have a short term fix to send me the stellar-core commit that I should run
<stellar-slack>
<graydon> nearly so, yeah. composing changeset now.
<stellar-slack>
<graydon> posted
<stellar-slack>
<sacarlson> thanks
<stellar-slack>
<sacarlson> so I'll give this 3d35407d63ca832632089c8125a93d0cacf666ed a try then
<stellar-slack>
<graydon> no, it's not merged yet; try 0d223d52a992f1c171857353da0c14c3b2e6a5b3
<stellar-slack>
<graydon> (or you can wait for it to merge; needs a reviewer first)
<stellar-slack>
<sacarlson> no I'll try it
de_henne_ has joined #stellar-dev
de_henne has quit [Ping timeout: 264 seconds]
<stellar-slack>
<sacarlson> I ended up building stellar-core b2b1ae0c700c5576eabacf54cba3ee0e8a4e10cc and it seemed to come up in normal time with full reset. seems to have fixed my problem so far
<stellar-slack>
<graydon> glad to hear it. that's with a fresh database?
<stellar-slack>
<sacarlson> yes full reset so fresh database
<stellar-slack>
<graydon> cool
<stellar-slack>
<sacarlson> so for our next project we need to incorporate the new stellar offline infrastructure into a phone app. what features do we want?
<stellar-slack>
<sacarlson> some kind of bluetooth link setup to share the transactions between party would be cool
<stellar-slack>
<sacarlson> my websocket packages are like 500 bytes or so, so maybe too big for QR code with camera interface
<stellar-slack>
<sacarlson> wifi link is another option
<stellar-slack>
<sacarlson> sense presents within range and authenticate and verify funding available on the reciever mode side
<stellar-slack>
<sacarlson> sense receiver of funds present with info of what it is to be purchased and from who in the sender of funds mode
<stellar-slack>
<sacarlson> the app would also have a mode for auto refill each day. when you go home or when you ever get connected to the internet at a certain time it will setup a new locked fund with needed assets for another day out.
<stellar-slack>
<sacarlson> manual option to unload the funds that would put the funds back into your live stellar circulation when time lock expires
TheSeven has quit [Disconnected by services]
[7] has joined #stellar-dev
<stellar-slack>
<dzham> @sacarlson: it’s scary how we’re thinking about the same things
<stellar-slack>
<sacarlson> it's the known future
<stellar-slack>
<dzham> it’s* one obvious path
<stellar-slack>
<sacarlson> yes better put
<stellar-slack>
<dzham> anyone put some time into studying ripples new “interledger”?
<stellar-slack>
<sacarlson> no I'll have to look it up
<stellar-slack>
<dzham> it’s kind-of in the same direction as what we’ve experimented with, but connection different ledgers instead
<stellar-slack>
<sacarlson> ya I guess it could be used for anything like that
<stellar-slack>
<sacarlson> you just need a trusted point or chain to jump through space or networks
<stellar-slack>
<sacarlson> we've already automated that step
dobson has quit [Read error: Connection reset by peer]
dobson has joined #stellar-dev
de_henne_ has quit [Remote host closed the connection]
[7] has quit [Remote host closed the connection]
TheSeven has joined #stellar-dev
de_henne has joined #stellar-dev
Kwelstr has quit [Ping timeout: 246 seconds]
Kwelstr has joined #stellar-dev
<stellar-slack>
<jed> testnet down for an upgrade
nivah has joined #stellar-dev
<stellar-slack>
<sacarlson> ok thanks jed
pixelbeat has joined #stellar-dev
Travis__ has joined #stellar-dev
Travis__ has left #stellar-dev [#stellar-dev]
<stellar-slack>
<donovan> @dzham: RE: interledger, it looks like it wants to be a standard without specifying the actual standard! In terms of implementation, I haven’t seen any code that implements the notaries/witnesses, which is the core of it all. It was the same problem with Codius, with multiple independent remote processes, how to decide which of the processes first publishes the fact that the transaction has been witnesse
<stellar-slack>
<sacarlson> yes I agree even with an automated robot witness that would send both nets it's signature that it has seen what it has seen. what if there is a failure in transmition
<stellar-slack>
<sacarlson> there is some protocol needed to lock the two transactions on both nets
<stellar-slack>
<donovan> I’ll wait until there is some code. The whitepaper was very woolly on how notaries reach agreement.
<stellar-slack>
<sacarlson> suspend payment, what is used as the event that unlocks it? another signature of another key holder?
<stellar-slack>
<donovan> ``` Any account may submit a SusPayFinish. If the SusPay ledger entry specifies a condition, the SusPayFinish must provide the sfMethod, original sfDigest, and sfProof fields. Depending on the method, a cryptographic operation will be performed on sfProof and the result must match the sfDigest or else the SusPayFinish is considered as having an invalid
<stellar-slack>
<donovan> Note that i only supports XRP ;)
<stellar-slack>
<sacarlson> ok ya just an added signature is needed. I think we could setup a protocol between ripple and stellar then with robot witnesses between to settle movement of funds without the need of a third party escrow holding the funds. they would just lock them
<stellar-slack>
<donovan> That robot used to be called a gateway :)
<stellar-slack>
<sacarlson> no this robot is just a witness it moves no funds
<stellar-slack>
<sacarlson> it's just a trusted entity that acts on contracts on both sides from what it see's in the contracts it is given to analize
<stellar-slack>
<donovan> I’m guessing the robot submits the SusPayFinish or SusPayCancel to the Ripple network, but who knows without documentation...
<stellar-slack>
<sacarlson> in my model that is used to lock funds for movement of funds without internet. it is the original holder that sets the lock that will require the robot witness and himself to free the funds
<stellar-slack>
<donovan> Ok, I was just talking about interledger :)
<stellar-slack>
<sacarlson> I'm speaking of how we and all networks can connect together at some point when we all have smart contracts
<stellar-slack>
<sacarlson> it is inevitable
<stellar-slack>
<donovan> I don’t know if it is, ripplefox has been doing STR=XRP for ages and DividendRippler has been doing various coin swaps as well. Feels like trying to automate gateways out of existence. Far better to encourage gateways to operate...
<stellar-slack>
<donovan> Largely depends if your focused on banks’ desire for privacy, or adding utility for the normal user.
<stellar-slack>
<sacarlson> once the assets are within one network they can be moved within it without problem. as now we move between them with gateways as you say and gateways will never be replaced I don't think
<stellar-slack>
<sacarlson> I'm just speaking of moveing asets from one network to another, but for the most part the assets are not in eather so what is done in my case is just tradeing assets from one gateway that is on one network to another gateway that is on a different network
<stellar-slack>
<donovan> The cynic in me just thinks that interledger is just a way to force XRP to be included in multi-ledger payment paths. You don’t really need all this infrastructure if you just trust a gateway to do it on your behalf.
<stellar-slack>
<sacarlson> that can be done with this method I now speak of that uses automated witnesses
<stellar-slack>
<donovan> Also, how does an automated notary know how to gather all the required KYC information for funds transfers?
<stellar-slack>
<sacarlson> kyc?
<stellar-slack>
<donovan> Know Your Customer. The Comments field in the Bitstamp withdrawal form :)
<stellar-slack>
<sacarlson> I have tools in stellar that analize transaction envelopes. these envelope transactions can be analized by robots to verify they do what is expected in the contract
<stellar-slack>
<donovan> Yes, but to be compliant you need to keep metadata like name, address, reason for large withdrawal to be associated with the movement of funds.
<stellar-slack>
<sacarlson> that the contract have the valid signatures needed to be processes. so the one added signature on both sides is from the robot that analizes the contracts of each then signs both
<stellar-slack>
<sacarlson> I'm not concerned about the logistics of compliance, that's the job of someone else, I just need to know that when this botton is pushed that the botton on the other net will also be pushed
<stellar-slack>
<sacarlson> and that it can only happen with signed keys for security on both sides
<stellar-slack>
<donovan> Well, in the UK, if a funds transfer over a certain threshold occurs, then you have various authorities that you have to inform of that transfer, with associated metadata provided. Such is the state of regulation :)
<stellar-slack>
<dzham> but that metadata is in neither ripple or stellar as-is, so would have to be added at a meta-level
<stellar-slack>
<donovan> Yeah, hence the need for gateways :)
<stellar-slack>
<sacarlson> well different networks and different gateways will have different regulations also dependent on there location, but there will also evolve a black or gray market networks that will also movement of fund with fewer restrictions
<stellar-slack>
<donovan> Anyway, I don’t really think this is the use case of interledger. It’s more for connecting a bank’s private ledger to Ripple via the use of XRP.
<stellar-slack>
<sacarlson> metadata being location id info? there is the memo field that would be limited to maybe a passport number, lic number or ??
<stellar-slack>
<donovan> @sacarlson: I wouldn’t want my passport number sitting in the memo field of a tx on a public ledger :)
<stellar-slack>
<sacarlson> good point
<stellar-slack>
<sacarlson> oh it could be encrypted in memo
<stellar-slack>
<sacarlson> I don't recall the space needed
<stellar-slack>
<dzham> memo is 32 bytes, IIRC
<stellar-slack>
<donovan> Yeah, but then you have to store the private key per user somewhere and you’re back to being a gateway :)
<stellar-slack>
<dzham> passport number would be with your gateway, when you sign up
<stellar-slack>
<sacarlson> ya 32 bytes so still enuf for an encrypted passport number
<stellar-slack>
<dzham> oh yeah, they are most definitely needed
<stellar-slack>
<dzham> the gateways
<stellar-slack>
<dzham> but that might just be part of your ordinary banking relationship
<stellar-slack>
<sacarlson> gateways will only be needed as long as people continue to need paper money and the old money to pay rents and buy beer. but when it can all be done on one network or all nets then not sure how much a gateway will be used
<stellar-slack>
<dzham> OK then.. s/gateway/issuer/
<stellar-slack>
<donovan> A Paypal=Stellar gateway would still need to do KYC/AML stuff.
<stellar-slack>
<sacarlson> hopefuly we will replace paypal so we won't need it
<stellar-slack>
<sacarlson> but yes
<stellar-slack>
<donovan> Well, I had to send some money to my brother in Ireland (EUR) and Paypal was by far the easiest and cheapest way to do it compared to banks and/or Ripple/Stellar/Bitcoin.
<stellar-slack>
<sacarlson> paypal has hiden expenses with very poor exchange rate
<stellar-slack>
<donovan> So does Bitstamp :)
<stellar-slack>
<sacarlson> I need to sell my remaining bitcoin before they become worthless
<stellar-slack>
<donovan> Want to know a funny thing about Bitstamp?
<stellar-slack>
<sacarlson> sure
<stellar-slack>
<donovan> You can’t do inter account transfers in Bitstamp.
<stellar-slack>
<sacarlson> smart you have to move in and out so they make more money ha ha
<stellar-slack>
<donovan> Therefore canny users transfer to Ripple and then back to Bitstamp. This represents a very large proportion of the USD/Bitstamp and BTC/Bitstamp volume reported on the Ripple network.
<stellar-slack>
<sacarlson> I know little about ripple even though I do have an account in it
<stellar-slack>
<sacarlson> but I keep all the funds in ripple currency
<stellar-slack>
<donovan> It’s just funny that UI quirk on a gateway makes a network look much busier than it really is.
<stellar-slack>
<sacarlson> well that's the cool thing about being a gateway bank as most the infrastructure is suplied free of charge. all you need is the process to move funds in and out
<stellar-slack>
<sacarlson> I can become a gateway here with nothing but a bank account in my thai bank that has a very good API. I just run a small program that can run on a $100 computer that handles all the transactions of 1000's of people per day
<stellar-slack>
<donovan> Well, be weary of legislation. If you don’t record who you are dealing with and an officer of the law knocks on your door and asks for records of your customers, you can get in trouble quickly.
<stellar-slack>
<buhrmi> your bank has an api?
<stellar-slack>
<buhrmi> bank as in "real bank connected to swift and credit card networks and everything"
<stellar-slack>
<buhrmi> ?
<stellar-slack>
<sacarlson> that's the other cool think there will be 100000's of small outfits like me that will ignore legislation and will sometime get shut down
<stellar-slack>
<sacarlson> for a $100 investment why not?
<stellar-slack>
<donovan> Well, that’s already happened with RippleTradeJapan and Pax Moneta being shady in another place.
<stellar-slack>
<donovan> There was the UK Ripple gateway way back, where Simon Tomlin got completely shafted on chargebacks as well.
<stellar-slack>
<donovan> Justcoin...
<stellar-slack>
<sacarlson> small busnesses can take biger risks
<stellar-slack>
<donovan> Maybe, but it can be your customers who get shafted :)
<stellar-slack>
<sacarlson> with less to looose
<stellar-slack>
<sacarlson> yes but you only need the gateway when you want to exit that takes only 2 secounds so what are the chances that the entity will be shut down at the instant you move your funds?
<stellar-slack>
<sacarlson> we don't have to store the funds there
<stellar-slack>
<donovan> All the people holding your issued asset will not be able to redeem them.
<stellar-slack>
<sacarlson> true
<stellar-slack>
<sacarlson> so don't keep too many there
<stellar-slack>
<donovan> Sounds like a “low-trust gateway” :)
<stellar-slack>
<sacarlson> I'm not in the gateway buz I just said I could
<stellar-slack>
<sacarlson> if someone wants to set one up I can consult and do it for them
<stellar-slack>
<donovan> Main problem with crptocurrency is the lack of respectable well-run gateways in most countries of the planet.
<stellar-slack>
<donovan> Some see banks as the solution to that problem.
<stellar-slack>
<donovan> Others hope for more gateways.
<stellar-slack>
<sacarlson> yes we need some nice big trusted bank to move in so we have a good place to park stuf
<stellar-slack>
<sacarlson> that still has minimal restrictions
<stellar-slack>
<sacarlson> wellsfargo would be cool
<stellar-slack>
<sacarlson> get them too hook up and I'll park some money on there gateway
<stellar-slack>
<donovan> Trouble is they don’t want you holding their funds unless they know who you are.
<stellar-slack>
<donovan> And most bank customers don’t want you to see their transfers
<stellar-slack>
<sacarlson> ya but they still need to allow me to pass my funds to some shady place so I can make purchases of wierd stuf
<stellar-slack>
<donovan> Lol, bitcoin.
<stellar-slack>
<sacarlson> or scotty's bank of thailand
<stellar-slack>
<raymens> Any plans for a horizon docker image?
<stellar-slack>
<sacarlson> you want to run the full horizon on your system? I've only run the ruby side one time
<stellar-slack>
<raymens> Yeah the latest GO that's still in development. (that one is replacing the ruby one right?)
<stellar-slack>
<sacarlson> last I heard the go version still requires having the ruby part running along side it
<stellar-slack>
<sacarlson> it might be past that point by now I'm not sure
<stellar-slack>
<raymens> for the creation of transactions or something like that right?
<stellar-slack>
<sacarlson> but the problem I had with horizon is I couldn't see all the values I wanted from the database stellar database through it
<stellar-slack>
<raymens> compared to?
<stellar-slack>
<sacarlson> well compared to my multi-sign-server now that allow seeing all the values inside the stellar network
<stellar-slack>
<sacarlson> but doesn't have the features of the recorded orders that horizon is setup for
<stellar-slack>
<raymens> sounds like Horizon needs a PR for the multi-sign stuff
<stellar-slack>
<sacarlson> the multi-sign-server now also has the feature to see most any part of the stellar-core database
nivah has quit [Ping timeout: 240 seconds]
<stellar-slack>
<sacarlson> no multi-sign I don't think will replace horizon, it's not designed in any way like it
<stellar-slack>
<raymens> I don't mean replace, but enhance. Unless you're multi-sign is fundamentally different?
<stellar-slack>
<sacarlson> if you just want to do transactions or look at details of a single account multi-sign-server should work for you
<stellar-slack>
<sacarlson> the server is a bit deprecated now with more work done on websocket
<stellar-slack>
<sacarlson> but at this point it now requires that stellar-core be running with it to have full functionality but it also works with limited functions with just horizon as it's interface to stellar network
<stellar-slack>
<raymens> What if Horizon would have a passthrough bridge, that forwards any request to the stellar-core. Or do you require database access?
<stellar-slack>
<sacarlson> passthrough to perform a transaction? it can do that but I can't view the threshold values of an account or see who is presenly setup as a singer on an account using horizon as far as I know
<stellar-slack>
<sacarlson> if there is any value that I can't see on horizon I just add it to mss-server
<stellar-slack>
<raymens> Oh yeah, I'm just thinking... If you're missing some information using Horizon. Big chance someone else will eventually want that kind of information too. So for me it seems Horizon should be expanded by exposing that information
<stellar-slack>
<sacarlson> I can also search and find the results of a transaction in the past
<stellar-slack>
<sacarlson> my system also translates errors into english
<stellar-slack>
<sacarlson> instead of base64 coded stuf
<stellar-slack>
<sacarlson> it's more of a tools to look at what is presently inside the stellar-core database
pixelbeat has quit [Ping timeout: 260 seconds]
<stellar-slack>
<raymens> That sounds like some useful stuff
<stellar-slack>
<sacarlson> good then rewrite it and make it better
pixelbeat has joined #stellar-dev
<stellar-slack>
<donovan> Just been spending some time building a PEG parser for the Stellar XDR structures and have been studying the XDR spec. Seems like the `#include` directive and `namespace` keywords aren’t part of the XDR standard. Should they be part of the code gen process rather than be included in the source directly? Also, is it possible to get this directory broken out into a separate repo? https://github.com/stellar
<stellar-slack>
<sacarlson> the missing information in horizons API is mostly only involved in multi signing transacitons that I'm more involved in
<stellar-slack>
<sacarlson> donovan: what's a PEG parser? I've broken up the transactions envelope structures into ruby hash that might be considered a parser
<stellar-slack>
<sacarlson> I also have parsers that convert the error codes structures into hash to make them readable
<stellar-slack>
<donovan> Excuse the bad formatting of the peg file...
<stellar-slack>
<donovan> Pretty much the same as Scott’s use of treetop, just in Go.
<stellar-slack>
<sacarlson> what is it used for? parse to what final format?
<stellar-slack>
<donovan> Well, I guess more strictly it’s a lexer which I’ll use to write the parser which will be used to generate Go code that handles discriminant unions in a more idiomatic way
<stellar-slack>
<sacarlson> it's the best way to learn by looking deep into the structures it gives you the better view of how it all works
<stellar-slack>
<sacarlson> unfortunatly I did it last ha ha
<stellar-slack>
<sacarlson> this is the tool I use to view and check the results of envelopes
<stellar-slack>
<jed> donovan: you can just ignore the includes in the .x they are just their to make things easier on the c++ side.
<stellar-slack>
<donovan> @jed Yeah, but then I’ve written a non-XDR compliant lexer :) It’s more the `namespace` keyword that is problematic
<stellar-slack>
<jed> sorry I meant you can ignore the namespace
<stellar-slack>
<donovan> @jed, ok I’ll just prefilter the source files to remove those lines. Is it ok to get the directory in its own repo?
<stellar-slack>
<jed> yeah we have been meaning to do that. I'll bring it up again today
<stellar-slack>
<donovan> great, thanks!
<stellar-slack>
<scott> @donovan: +1 for more idiomatic tagged unions for go. They’re painful to work with right now, and I’ve got some ideas about how to make them better but if you want to work on it, all the better!
<stellar-slack>
<donovan> @scott cool, got a few ideas as well using interfaces, but just need to get a good feel of the whole protocol, hence the parsing/lexing exercise first. Will report back soon!
<stellar-slack>
<scott> sweet! I’d love to see pointlander/peg at work, had been meaning to play with it myself at some point. If you need any xdr-specific commentary, I’m happy to help.
<stellar-slack>
<donovan> Great, it’s basically a Go version of xdrgen. Just working on making a sensible AST now. I’ll push something soon.
koshii has quit [Ping timeout: 264 seconds]
koshii has joined #stellar-dev
<stellar-slack>
<jed> If anyone wants lumens on the live network let me know
<stellar-slack>
<raymens> Is core still actually doing something? (testnet) ``` 2015-10-13T13:20:56.973 04c3ad [] [History] INFO Decompressing tmp/catchup-8df1 984c4875550a/ledger-00017f7f.xdr.gz 2015-10-13T13:20:56.974 04c3ad [] [History] INFO Verifying bucket-3ae31b7c2cf5e 6a2115da34cb9eaa4b66f7e0ff7085e4745cf13d26e98263460.xdr 2015-10-13T13:20:56.979 04c3ad [] [History] INFO Archive bucketListHash: ce65e5 2015-10-13T13:20:56
<stellar-slack>
mLastClosed bucketListHash: ce 65e5 2015-10-13T13:20:56.980 04c3ad [] [History] INFO Applying buckets for level 10 at ledger 98175 2015-10-13T13:20:56.981 04c3ad [] [History] INFO Applying buckets for level 9 a t ledger 98175 2015-10-13T13:20:56.981 04c3ad [] [History] INFO Applying buckets for level 8 a t ledger 98175 2015-10-13T13:20:57.492 04c3ad [] [History] INFO Applying buckets for level 7 a t ledger 98175
<stellar-slack>
<jed> yeah
<stellar-slack>
<jed> It takes awhile to catch up
<stellar-slack>
<jed> stellar-core --info
<stellar-slack>
<jed> there are a lot of accounts on the testnet right now since we have been doing stress testing
<stellar-slack>
<donovan> Probably needs a bit more of an example, broken down into the usual Alice and Bob. The Bitcoin example has a timeout, but don’t see that in the Stellar one. Also: ```H( signature ) = signer``` How does someone generate a signature that can be hashed to a known value?
<stellar-slack>
<donovan> Is the idea to do "One Time Signatures"?
<stellar-slack>
<jed> well we already have the timebounds mechanism in stellar
<stellar-slack>
<jed> yeah it is basically one time use. after someone signs then everyone knows what x is
<stellar-slack>
<jed> this is required for the atomic swaps
<stellar-slack>
<donovan> So, in the same bundle of operations, the signer gets removed after the actual transfer operation goes through?
<stellar-slack>
<jed> well I was assuming it would be an escrow account but you could do it that way
<stellar-slack>
<donovan> “One Time Account” :)
<stellar-slack>
<jed> yeah :)
<stellar-slack>
<donovan> Well, sounds good. Automated escrow is the flavour of the day :) I’m still learning all the protocol data structures, so I’m a bit behind at the moment.
<stellar-slack>
<sacarlson> I'm not totaly understanding your question about timebounds but I have examples using them
<stellar-slack>
<sacarlson> in ruby
<stellar-slack>
<sacarlson> one time account? I can reuse accounts or delete them, I can add signers or delete them
<stellar-slack>
<sacarlson> my present usage of timebounds is to lock an account from the original master for some window of time
<stellar-slack>
<sacarlson> but it can be used as in the text examples to make a montly payment contract or other
<stellar-slack>
<donovan> @sacarlson: I was discussing this: https://github.com/stellar/stellar-core/issues/846 :) If you want to mock up a transaction that does what’s specified there, that would be helpful :)
<stellar-slack>
<sacarlson> I'm trying to understand this new proposed adition, it sounds like it just adds an option to add new formats of signers instead of the standard base32 version we now have
<stellar-slack>
<sacarlson> so it can't be done with the present software other than with trust bots doing it outside of the stellar-core
<stellar-slack>
<sacarlson> I'm guessing at this point in my present intoxicated state after a night of drinking
<stellar-slack>
<sacarlson> but I assume this means that a bitcoin keypair or maybe ripple or most any keyset of most any crypto currency known or at least the seed could be used in stellar-core so could be used in cross network contracts
<stellar-slack>
<sacarlson> sounds cool to me
stellar-slack has quit [Remote host closed the connection]
stellar-slack has joined #stellar-dev
pixelbeat has quit [Ping timeout: 246 seconds]
<stellar-slack>
<raymens> @jed: the new build of the testnet branch seems to have fixed the issue :)
<stellar-slack>
<jed> sweet
<stellar-slack>
<raymens> I still have trouble running the 3 node simulation shown on the docker repo though