Whats the *real* deal with BTC paper wallets versus trying to do it with NXT? Paper wallets are generally created by printing a brand new public address and private key onto paper, and then sending bitcoins from a "live" wallet to the printed wallet's public address for safekeeping. People have been saying that NXT cannot accomplish this because to have 2^256 security for a NXT account requires publishing of the NXT public key, thus being online. It seems to me that it shouldnt be too much different - to be 100% sure with a BTC paper wallet, shouldnt you boot to a live CD and generate the wallet from there? Sure, you dont have to be online to do this and there is no public key to publish, but is publishing a public key really that big of a deal, especially since it can be done by booting to a liveCD and running NRS from there? discuss. |
|
|
|
Hey I have a question with transaction malleability. From the NXT Wiki: Transaction malleability is an issue with Nxt, as it is with all cryptocurrencies. Do not rely on a transaction ID alone to verify transactions! I was reading up on the BTC malleability issue from here: On the one hand, you can argue that malleability has been a known issue since 2011 and companies should have known to be watching for the non-malleable payment details of a transaction to show up, rather than waiting for the transaction ID to show up. If you’re not doing this, your system is buggy and it’s your own fault. Or so this argument goes. I think I understand the concept 100% but heres where I get stuck: So if an exchange should not rely on just looking for a transactionID, what is the proper method? Do they have to attempt to track sendingAccountID, receivingAccountId, and amount? OR, am I working on old information, and is what Im describing the the Dr.Evil discovery that has been completely fixed and is not an issue with NXT any more? |
|
|
|
1) a single account has 91% of all NXT in its balance
2) a single account balance + all the effectiveBalances leased to that single account where the sum is 91% of all NXT
The suggestion I was making (and it is only a suggestion) would be that both the single account and one owning "leased addresses" are limited to a max. amount of forging power (say 1% for convenience). So any additional forging power by the way of extra NXT or extra leased accounts would be "useless" and therefore most likely to be allocated elsewhere (*manually* with my suggestion rather than somehow *automatically* via the *penalty* concept). I made an identical suggestion a few days ago, but no one seemed to see it. I forgot what values I suggested, I think it was 5M or 10M or something like that. Assuming no penalty exists as our current situation, is there any difference between the 2 scenarios I presented? They are the same, right? no? IMO this forging thing is the most important thing we have to consider for the future. How to encourage forging, and prevent centralization in a trustless manner. BTC cannot solve this - pools must choose to do the right thing. But if we limit the amount of forging power then IMO we run the risk of making it even easier to mount 90% attack, if very little NXT is actively forging. Hard stuff.. Do we make forging profitable as a means to protect the network? Or can we depend on the circumstances that BCNexts' plan targets? Hard stuff |
|
|
|
What do you think about limiting max forging power to anywhere between 1% to 5%
I didn't come to a conclusion yet. i still say this is one of the things we all need to talk through and address first. how do we prevent centralization of forging in a non-trustless manner? and can someone answer a question on the following 2 scenarios: 1) a single account has 91% of all NXT in its balance 2) a single account balance + all the effectiveBalances leased to that single account where the sum is 91% of all NXT Do both these scenarios present the same risk of a 91% attack? It seems to me that they do, but some people seem to have been suggesting otherwise, or at least thats how I understand some conversations Also, can anyone answer this: in what cases would you use broadcastTransaction API? Is it only for light-clients to use to send to a full node? I thought we were saying before that if some forger never picked up your transaction you could use broadcastTransaction to resend it, but that requires full bytes of the transaction, and you cannot obtain that unless you pull it from the blockchain, which means it is already *in* the blockchain.
I dont understand?
|
|
|
|
where does this public node reside at? if not a VPS and only you have physical access to it (its not in a datacenter, etc) then it should be safe |
|
|
|
|
if someone can tell me how to access IRC from tor I can hang out there.
|
|
|
|
|
in what cases would you use broadcastTransaction API? Is it only for light-clients to use to send to a full node? I thought we were saying before that if some forger never picked up your transaction you could use broadcastTransaction to resend it, but that requires full bytes of the transaction, and you cannot obtain that unless you pull it from the blockchain, which means it is already *in* the blockchain.
I dont understand?
And can someone get me some testnxt please? 16155265664111966451
|
|
|
|
|
hey joefox, can you please edit your cloudflare captcha settings to not require such an impossible captcha? they really are impossible to solve if you are using tor. i mean really fucking stoopid impossible. you can tell it to use an easier captcha. did i mention that the current settings are impossible to solve?
|
|
|
|
@opticalcarrier: how do you feel about setting up an exchange implementation group, as outlined below? Might be bounty in it for ya......
I vote that we don't.
We have talented guys in NXT that have been helping with exchange implementation (opticalcarrier springs to mind, + others).
If we spent the 100 kNXT bounty on financing these guys to set up an exchange implementation workgroup and get them to fully document their procedures, we can get a package together that will allow all exchanges to implement NXT without the technical problems that so many seem to be having.
Helping, documenting, spreading the implementation info and providing support will pay off way better in the long run than simple bribery.
Again, if providing tech help doesn't cut it, then we can try bribery.
Don't forget, we just blew something like 2-3 BTC on MintPal and they then turned around and said: "Sorry , we don't understand NXT, how about some nice TeslaCoin instead? "
I say we offer them 20k Nxt for testing purposes along with the help of our devs. You could even tell Cryptsy that BTC38 and BTC-e are adding Nxt and vice versa. Tell them it was an easy implementation with the help of our devs. Sure but i have no idea about running an exchange. I can prob write some stuff up on wiki on which apis to use, and examples of howto use them, and tailor it to the interactions ive had with some of the exchanges ive already worked with |
|
|
|
1984, guys. Future, we shall never see!
Im kind of expecting to hear from bcnext on this page |
|
|
|
I wondered what happened to NXT on Mintpal...
Thought they were going to add it today.
Why is there no dedicated, knowledgeable, person in the next community who handles all this exchange stuff?
For all I care: pay that person a ongoing bounty to handle this!
i hope ive made it clear that any exchange can consult with me for free on NRS/NXT design/operation for integration into their exchange. |
|
|
|
@mynxt.info, nxtcrypto.org and nxtbase.com : If you open up bot access, please also enable CORS. This allows cross domain ajax requests which web clients like mine ( http://nxtra.org/nxt-client/ ) need to access remote nodes. THANK YOU!I have not idea what CORS is or what it does or how it works. can you give me some more info on exactly what is going on by allowing that? any downside? |
|
|
|
How to start 0.8.3? does not work. Error: no main manifest attribute, in nxt.jar follow the release notes for the 1st 0.8 experimental release. I put it up on experimental client thread on nxtcrypto.org |
|
|
|
thanks, had to be POST but if I remove the -H content-type it works :-) bittrex exchange is back at work on integrating nxt :-)
that particular request will automatically use POST |
|
|
|
Hey, bittrex asks why this doesn't work: > curl -X POST -H "Content-Type:application/json" --data "secretPhrase=xxx" http://127.0.0.1:7876/nxt?requestType=getAccountId
{"errorCode":3,"errorDescription":"\"secretPhrase\" not specified"}
What is wrong here? this will work: curl --data "requestType=getAccountId&secretPhrase=xxx" http://127.0.0.1:7876/nxt |
|
|
|
yes, they extract IP and use that to determine if the extracted IP matches the source of blocks. IF you hallmark then you identify your account with your IP address, so just be aware of that. you can still hallmark with NAT IP, but if your IP address changes then your hallmark automatically becomes invalid and you have to redo it. |
|
|
|
not exactly see you in maths
...
no, your comparison is between leased-effectiveBalances scenario and your shared-fee-group scenario, where the only difference is the number of forging nodes. my comparison is between current state (non leasing) and your shared-fee-group scenario. How are they not identical? |
|
|
|
Very strange. On 0.8.xe versions after several hours my node always forks. That was not the case on 0.7.x. I usually forged >1 block a day but on 0.8 i got nothing  Downgrading. mine doesnt fork, but every few hours my 0.8.1e forging NRS node just hangs on a block and stops receiving new blocks. I upgraded to 0.8.2e, same thing. All 25 of my nonforging public/hallmarked VPSs on 0.8.1e can keep the latest block though. ?? |
|
|
|
I don't get your idea, or I get it. I don't know.
Instead of leasing forge power, you commit with your account to share fees among others in the same "share fee group" if you forge a node. You still try to forge a block on your own, but you commit to share the incentive with others if you are successful (with special conditions like committing to run the node for some time, ...). Could this be done with AT and would that make sense?
there really isnt much point in this mechanism. what you are describing is basically a rube goldberg contraption that produces the exact result of current NXT account/network forging |
|
|
|
Maybe, I missed that part: why are streaks dangerous?
Without penalty or some other approach the forger who gets a long streak can "undo that many confirmations" by building a "secret" chain. you know, im really embarassed to have to ask this question, but can you go into even more detail here? IM just not seeing it |
|
|
|
|
Show Posts
