<stellar-slack1>
<scott> @brian.ebert: You get that at the moment you call ` transaction.sign(keypair)`? It doesn’t seem like you should (in fact it sounds like an error occurring when trying to serialize the resulting envelope to XDR), in which case you should be able to see exactly what the sign calls is returning by looking at the envelope. `transaction.toEnvelope().signatures` should give you that array.
<stellar-slack1>
<scott> By “running a while”, you mean that nothing else has changed other than the date? or did you update dependencies? What revision of js-stellar-base are you running?
<stellar-slack1>
<scott> I’m going to be heading home in just a sec, but I’ll jump back online when I get home to help.
dobson has quit [Quit: Leaving]
bit2017 has quit [Ping timeout: 240 seconds]
dobson has joined #stellar-dev
<stellar-slack1>
<brian.ebert> Hi Scott, the error is actually thrown when I submit the transaction. If I log transaction.toEnvelope().signatures() to the console I see a ChildStruct that has a signature field in it, with a Uint8Array[64], but the data is not the data found in the secret key of the key pair. I have to go out for a while too. Thanks for looking.
<stellar-slack1>
<scott> Okay, it makes sense that the error is thrown at submission time. That’s when the actual XDR is generated (i.e. when `toXdr(‘base-64')` is called
<stellar-slack1>
<scott> In regard to your error, I’m thinking of two possibilities: 1) For some reason, the signature objects are losing their relationships with the `DecoratedSignature` class
<stellar-slack1>
<scott> I’ve seen this happen when doing a deepClone or other clone operations on the object. The test to see if this is the case: `tx.sign(keypair); console.log(tx.toEnvelope().toXdr(‘base-64’);`
<stellar-slack1>
<scott> If you get output, that means somewhere else in your process you’re losing that type info
<stellar-slack1>
<scott> 2) the Uint8Array[64] is perhaps telling, as it is a typed array
<stellar-slack1>
<scott> Actually, scratch 2, I don’t think that would be a cause anymore
<stellar-slack1>
<scott> I won’t even bother explaining it fully, it doesn’t make sense
<stellar-slack1>
<scott> Is this in node? and if so, what version?
bit2017 has joined #stellar-dev
<stellar-slack1>
<dzham> @scott: As much as I love IPFS, a hash is just a hash. It’s all up to a 3rd party protocol to interpret what the hash points to anyway, so why would Stellar even have to know it’s an IPFS specific hash
<stellar-slack1>
<scott> so, the original proposal is _just_ for multihash support, which is agnostic
<stellar-slack1>
<scott> By supporting it, we would allow not only clean ipfs support, but also clean integration with any future project that happens to use multihash for addressing.
<stellar-slack1>
<dzham> OK, gotcha
<stellar-slack1>
<dzham> So variable length hash, with a prefix to denote the type
<stellar-slack1>
<sacarlson> and these files in IPFS are to be used for what type of data? maybe KYC data?
<stellar-slack1>
<dzham> @sacarlson: that’s up to the application
<stellar-slack1>
<sacarlson> well give me any example so I see a use for it
<stellar-slack1>
<sacarlson> I don't really understand why file pointing is needed in fund transactions other than maybe KYC, but I just lack imagination
<stellar-slack1>
<dzham> Me neither, but if it’s a support for other types of hashes than just 32-byte ones, then, yeah
<stellar-slack1>
<sacarlson> or more maybe a stellar transaction would authenticate a file like a way to sign it saying I accept it?
de_henne_ has joined #stellar-dev
<stellar-slack1>
<scott> @sacarlson: Imagine being able to attach any piece of digital data to a payment. For example, a payment could contain the invoice that the payment should be credited to. For practical reason, I doubt that the core transaction system would ever allow such flexibility, but it can link to that data using the memo field.
<stellar-slack1>
<scott> If something like ipfs could integrate with stellar, then we could leverage that system to store the raw attachment data
<stellar-slack1>
<sacarlson> very good example, I can buy that
<stellar-slack1>
<scott> and we would get the best of both worlds… flexible attachments, efficient payment network
<stellar-slack1>
<scott> anyways, I’m going to sign out for the night. cheers!
de_henne has quit [Ping timeout: 248 seconds]
TheSeven has quit [Ping timeout: 240 seconds]
TheSeven has joined #stellar-dev
_whitelogger_ has quit [Remote host closed the connection]
_whitelogger has joined #stellar-dev
stellar-slack1 has quit [Remote host closed the connection]
stellar-slack has joined #stellar-dev
nivah has quit [Ping timeout: 240 seconds]
nivah has joined #stellar-dev
<stellar-slack>
<bartek> @brian.ebert: which version of SDK are you using? and can you share your code? we have a bunch of tests in JS SDK and imho it shouldn't be a bug on our side but I want to check it out.
nivah has quit [*.net *.split]
ggherdov` has quit [*.net *.split]
koshii has quit [*.net *.split]
etrepum has quit [*.net *.split]
DigitalFlux has quit [*.net *.split]
jbenet has quit [*.net *.split]
koshii has joined #stellar-dev
DigitalFlux has joined #stellar-dev
DigitalFlux has joined #stellar-dev
bit2017 has joined #stellar-dev
etrepum has joined #stellar-dev
jbenet has joined #stellar-dev
_whitelogger has joined #stellar-dev
ggherdov` has joined #stellar-dev
DigitalFlux has quit [*.net *.split]
TheSeven has quit [*.net *.split]
dobson has quit [*.net *.split]
termos has quit [*.net *.split]
moo-_- has quit [*.net *.split]
dobson has joined #stellar-dev
DigitalFlux has joined #stellar-dev
DigitalFlux has quit [Changing host]
DigitalFlux has joined #stellar-dev
TheSeven has joined #stellar-dev
moo-_- has joined #stellar-dev
termos has joined #stellar-dev
moo-_- has quit [*.net *.split]
TheSeven has quit [*.net *.split]
dobson has quit [*.net *.split]
etrepum has quit [*.net *.split]
jbenet has quit [*.net *.split]
olinkl has quit [*.net *.split]
Kwelstr has quit [*.net *.split]
loglaunc- has quit [*.net *.split]
TheSeven has joined #stellar-dev
Kwelstr has joined #stellar-dev
dobson has joined #stellar-dev
moo-_- has joined #stellar-dev
loglaunch has joined #stellar-dev
patsToms has quit [Ping timeout: 272 seconds]
patsToms has joined #stellar-dev
etrepum has joined #stellar-dev
acetakwas has joined #stellar-dev
olinkl has joined #stellar-dev
jbenet has joined #stellar-dev
bit2017 has quit [Ping timeout: 260 seconds]
patsToms has quit [*.net *.split]
loglaunch has quit [*.net *.split]
bittrex-richie has quit [*.net *.split]
loglaunch has joined #stellar-dev
patsToms has joined #stellar-dev
bittrex-richie has joined #stellar-dev
bittrex-richie is now known as Guest80355
pigeons has quit [*.net *.split]
pigeons has joined #stellar-dev
pigeons is now known as Guest73460
DigitalFlux has quit [*.net *.split]
DigitalFlux has joined #stellar-dev
DigitalFlux has joined #stellar-dev
etrepum has quit [Ping timeout: 246 seconds]
acetakwas has quit [Ping timeout: 248 seconds]
etrepum has joined #stellar-dev
acetakwas has joined #stellar-dev
acetakwas has quit [Excess Flood]
acetakwas has joined #stellar-dev
_whitelogger has joined #stellar-dev
acetakwas has quit [Read error: Connection reset by peer]
Kwelstr has quit [*.net *.split]
ggherdov` has quit [*.net *.split]
sdehaan has quit [*.net *.split]
Kwelstr has joined #stellar-dev
ultrashag has joined #stellar-dev
acetakwas has joined #stellar-dev
acetakwas has quit [Ping timeout: 248 seconds]
sdehaan has joined #stellar-dev
ggherdov` has joined #stellar-dev
bit2017 has joined #stellar-dev
sdehaan has quit [Ping timeout: 268 seconds]
sdehaan has joined #stellar-dev
Kwelstr has quit [Ping timeout: 268 seconds]
etrepum has quit [Read error: Connection reset by peer]
etrepum has joined #stellar-dev
Kwelstr has joined #stellar-dev
<stellar-slack>
<scott> A decorated signature is just a stellar specific “signature plus attached metadata” struct. Specifically, it contains a hint for the public key that created the signature to make transaction validation more efficient
<stellar-slack>
<brian.ebert> I'm on v4.1 of the sdk
Guest80355 is now known as bittrex-richie
<stellar-slack>
<brian.ebert> I looked at the hint field. It's very small. It helps speed reconstruction of the public key? How?
<stellar-slack>
<scott> so, a signature contains no extra data, it does not identify the key that signed it in any way. ithout any additional information, to validate a transaction you must verify a signature against all potential public keys
<stellar-slack>
<scott> the hint is just the last 4 bytes of the public key that created the signature, which allows stellar-core to reduce the number of potential keys it must test against
<stellar-slack>
<brian.ebert> Thank you!
<stellar-slack>
<brian.ebert> So, why not just include the whole public key?
<stellar-slack>
<scott> I’m not sure, you’d have to ask @monsieurnicolas about that… I believe he designed that portion of the protocol
<stellar-slack>
<scott> My guess is that 99.99% of the time the last 4 bytes is enough by itself to uniquely identify the key within the context of transaction validation.
<stellar-slack>
<jed> yeah it is just to save space
<stellar-slack>
<scott> oh duh, and XDR is 4 byte aligned so that’s the smallest amount we could use.
<stellar-slack>
<sacarlson> brian.ebert: I'm going to guess your problem is in this line var freshKP = model.stellarBase.Keypair.fromRawSeed(from._secretSeed);
<stellar-slack>
<scott> @brian.ebert: Can you just try this line at the point of error: `console.log(new model.StellarSDK.xdr.DecoratedSignature({hint: "1234", signature: "1234567"}).toXDR('base64'));`
<stellar-slack>
<sacarlson> I normaly gen keys with something like this key = StellarSdk.Keypair.fromSeed(seed.value);
<stellar-slack>
<scott> It should log `MTIzNAAAAAcxMjM0NTY3AA==`
<stellar-slack>
<scott> For me, using node 0.12.7 and js-stellar-sdk 0.4.1 It succeeds. If it fails for you, that means something else in your environment is disrupting the process… in what way I am not entirely sure
<stellar-slack>
<brian.ebert> @scott, I get the same log output you quote
<stellar-slack>
<brian.ebert> @sacarlson: that line is just there to ensure key pair type is present. I can take it out and sign with the original key pair and the same thing happens.
<stellar-slack>
<scott> okay, so thats progress. Just to confirm, does `from._secretSeed` actually contain the raw seed? i.e. does it begin with the letter `S`? or not
acetakwas has joined #stellar-dev
Guest73460 is now known as pigeons
<stellar-slack>
<scott> What does `console.log(kp.signDecorated('foo').toXDR('base64'));` output?
<stellar-slack>
<scott> or sorry, `console.log(freshKP.signDecorated('foo').toXDR('base64'));`
<stellar-slack>
<brian.ebert> @scott: from._secretSeed is a 32 byte buffer. First value is 56, so no, not an s.
<stellar-slack>
<scott> hmm, fuck. I’m almost out of ideas. what does `console.log(transaction.toEnvelope().signatures()[0].toXDR('base64’))` output when run in your script. I expect an error
acetakwas has quit [Quit: Leaving]
acetakwas has joined #stellar-dev
<stellar-slack>
<brian.ebert> @scott: I'm so glad I can say fuck on here, thank you.
<stellar-slack>
<scott> :)
<stellar-slack>
<scott> We’re trying to improve the financial world, of course things will get vulgar :)
<stellar-slack>
<scott> so, any luck? did that last snippet error out or did you get some output?
<stellar-slack>
<brian.ebert> Yeah, I got:[Log] QS0UzgAAAEBRiDPYAkPXm4sxBnYHlztFhv4Xl1MUK+Z07DIPrx2CHXI2p916Y/67lYIcI1eOW8swoD3A2x1FzhflvnqYwdcM (bundle.js, line 103418)
<stellar-slack>
<scott> okay! so, that’s progress… I’m now wondering if perhaps the error is originating somewhere else
<stellar-slack>
<brian.ebert> I think somewhere the signature isn't getting referenced correctly
<stellar-slack>
<brian.ebert> Because you can see it when you reference it explicitly.
<stellar-slack>
<scott> ``` console.log(transaction.toEnvelope().signatures()[0].toXDR('base64')) console.log(transaction.toEnvelope().toXDR('base64'))` console.log("shouldn't see me") ``` Just to confirm, you don't see "shouldn't see me" when running that in your script?
<stellar-slack>
<brian.ebert> Yes, you've got it now.
<stellar-slack>
<scott> Okay, one last confirmation before I start digging into the xdr code base: `console.log(transaction.toEnvelope().tx().toXDR('base64'));` does it error or not
acetakwas has quit [Ping timeout: 250 seconds]
olinkl has quit [Ping timeout: 240 seconds]
<stellar-slack>
<brian.ebert> That line did not error
termos has quit [Read error: Connection reset by peer]
TheSeven has quit [Remote host closed the connection]
<stellar-slack>
<scott> hmm, well I’m all out of ideas then… have you seen if older, known good revisions work/break?
<stellar-slack>
<scott> If old revisions work, I would recommend doing a git-bisect to find what revision broke things
<stellar-slack>
<scott> If old revisions break as well, that makes me think something in your specific environment is breaking things… meaning you would either need to build a fresh environment to get a repro or open up your specific environment for someone else to investigate directly
<stellar-slack>
<brian.ebert> I just tried that code on an older version and it ran
<stellar-slack>
<scott> okay, so that means you can find what revision breaks your build and that will give us more information about where to investigate next
<stellar-slack>
<scott> If you track that down, and give me a `git show` of the commit that introduced the breakage I can help find where we should investigate next
<stellar-slack>
<brian.ebert> Allright. Thanks for the help. I'm going to do something else for a while and return to this later.
TheSeven has joined #stellar-dev
<stellar-slack>
<scott> sounds good. I’ll be around :) sorry about all the pain
termos has joined #stellar-dev
olinkl has joined #stellar-dev
<stellar-slack>
<brian.ebert> @scott: I took the build I'm struggling with and rolled back my js-stellar-base revision to 5.0 and js-stellar-sdk revision to 4.0. That matches the configuration of the version of my sw I reported working earlier this morning. Now the problematic build is working.
<stellar-slack>
<brian.ebert> How do you recommend I proceed?
<stellar-slack>
<jed> is it possible for you to give us the code so we can just test here?
<stellar-slack>
<scott> @brian.ebert: do you have both js-stellar-base and js-stellar-sdk in your package.json?
<stellar-slack>
<scott> I’m thinking perhaps the problem is related to node’s module system
<stellar-slack>
<brian.ebert> @jed: I'd rather not release the code until I'm happy with the condition it's in. I plan to drop it into open source some day, but not today. I'll be in North Beach tomorrow and am happy to make some time if you want to see it yourself.
<stellar-slack>
<brian.ebert> @scott: yes, the stellar modules are in my package.json, but when I tested the .0 revisions minutes ago I installed the stellar modules individually, overwriting the later versions.
<stellar-slack>
<scott> okay, could you try _removing_ stellar-base, clearing your node modules and re-installing?
<stellar-slack>
<scott> stellar-sdk wraps stellar-base, and if for some reason both the stellar-base that sdk loaded was different than the one your scripts were using this could cause a problem.
<stellar-slack>
<scott> you should only need stellar-sdk
<stellar-slack>
<otto_mora> hey Folks
<stellar-slack>
<otto_mora> silly question, can I send a "circular" payment, meaning from Account A to Acccount A? Just for the purposes of having a transaction reflected on the ledger?
<stellar-slack>
<jed> yep
<stellar-slack>
<otto_mora> awesome, thanks for the info
<stellar-slack>
<brian.ebert> @scott: I think you may have hit the nail on the head with package versioning. I was running sdk v4.1 with base v5.2. I looked at package.json for sdk v4.1 and it calls base v5.1. FYI, base v5.2 is the latest version on npmjs. I'm feeling a bit worn out with this, but later on I'll try things with base v5.1, or not including stellar-base at all. I'm a little uncomfortable with that because I've be
<stellar-slack>
it some thought.
<stellar-slack>
<scott> kk. I’ll try to repro with sdk4.1 and base5.2
<stellar-slack>
<scott> repro'd
<stellar-slack>
<scott> ``` var S1 = require('stellar-base'); var S2 = require('stellar-sdk'); var sig = new S1.xdr.DecoratedSignature({hint: "1234", signature: "12345"}) S2.xdr.DecoratedSignature.toXDR(sig) // XDR Write Error: [object Object] is not a DecoratedSignature ```
<stellar-slack>
<scott> Alright, I’m going to consider this case closed.
<stellar-slack>
<brian.ebert> Yeah, looks good from here too. Why do you push base v5.2 to npm without an sdk that works with it?
<stellar-slack>
<scott> the sdk will work with 5.2 just fine… we would just need to up the dependency to 0.5.2 and redeploy, causing npm to not install a second version
<stellar-slack>
<brian.ebert> There isn't a second version of stellar-base in my environment. One version at any given time.
<stellar-slack>
<scott> yeah there is… go look into `node_modules/stellar-sdk/node_modules`
<stellar-slack>
<scott> this is just how npm deals with conflicting dependencies
<stellar-slack>
<brian.ebert> Oh! I set depth to 0 when doing npm ls. I get it now.
<stellar-slack>
<scott> cool! happy to help
<stellar-slack>
<scott> to be clear, I haven’t done much work on strategy when it comes to our javascript libraries… I would be happy to receive recommendations about how we should manage the two. If you know anyone who wants to take a look at the projects and recommend changes to our release management, I’d be happy to talk with them.
<stellar-slack>
<scott> at the very least I’ll be adding a warning to the stellar-sdk README about this specific issue
<stellar-slack>
<brian.ebert> I don't know what's involved with taking a look at the projects, but I'd be happy to try. I get screwed up with stellar versions all of the time. I think there should be very consistent outward facing versions. Today is a good example: if I ask npm to install a package at the command line sans version spec, that should be the same version installed by the other package. Also, if I want to read the
<stellar-slack>
documentation, I'd like the default to be the released version. Saves me looking like a bigger idiot. Oh, and some time.
<stellar-slack>
<brian.ebert> I'm going to ride my bicycle for a while and get some air. That was yeoman work this morning and I'm grateful for your help
<stellar-slack>
<scott> > Open Blockchain uses a slightly different model and manages the admission of participants at its core. In other words, it is a permissioned shared ledger. This approach wastes less computation cycles, scales much better, and responds to many requirements arising in industrial uses, such as strong identity, auditability, and privacy.
<stellar-slack>
<scott> Interesting stuff, looks like I’ve got some reading material for the night :)
edubai__ has joined #stellar-dev
<stellar-slack>
<bitmynt> Any developer in here interested in brainstorming? I have a half-baked concept I thought up and wish to refine and see if it can apply to Stellar. Hit me up!