Author

Topic: BTCD is no more - page 218. (Read 1328507 times)

legendary
Activity: 1876
Merit: 1000
September 26, 2014, 10:49:37 AM

I do own some BTCD, Am I then one of the stakeholders?     I am still fuzzy on the details.

Jim


As long as you keep the wallet open and unlock to stake then you are one of the stakeholders. The point is to keep the network as secure as possible and only people staking can make that happen. Along with gaining more BTCD, the dividend is pretty much an incentive since so much of SuperNET will be riding on BTCD. There is also mention of checking how long each user stakes to determine fairness of dividend so that opening the wallet once a month for a few hours doesn't gain the same benefit as someone that always keeps theirs' open. Basically, you are rewarded twice over for keeping the wallet open and staking.



NICE... However it says the dividends will be paid to an associated nxt addy? how does that work.


you pick a public BTCD address to use. It doesnt have to have much BTCD in it. The software will automatically map this address to a NXT address (using its privkey), then it will make a NXT alias so that you can use the same public BTCD address even inside NXT

James

James,  Thank you much for answering.

My only question left is:
How do I 'pick a public BTCD address to use'?    And I assume I want to use the addy that holds all my btcd.
legendary
Activity: 1181
Merit: 1018
September 26, 2014, 10:01:08 AM
yep - the laowais repo. I'll try, thanks!

edit- that did it! I have a nice BitcoinDarkd running now.

the mkdir obj obj/zerocoin is supposed to be done in /src

It seems I missed out on the 'strip symbles' somehow, I have an executable of ~58MB, whereas the qt as 8MB.
Now I want to try to talk to it via rpc- I know how to do that from bitcoin, so I'll start tweaking the ./BitcoinDark/conf

Thanks again!
sr. member
Activity: 255
Merit: 251
September 26, 2014, 09:57:12 AM

Ok so I am partially successful in building bitcoindark.

I did manange to build Bitcoindark-qt and it is running nicely. I also got 0.0005 or so from a faucet, so it appears to running correctly.

Now I am a bit insecure because I can not find any wallet encryption. Since I rarely use bitcoin (NXT rulez!), I vaguely remember that tehre was s.t. about that.

Was that omitted in BTCD on purpose or did my build go wrong somehow and the encryption got dropped out?
 

Also, I do NOT get the headless testserver to build- and usually it is the gui stuff that is more bitchy than the server stuff:

notary@notty:~/workbench/Blockchains/bitcoindark/doc$ cd ../src/
notary@notty:~/workbench/Blockchains/bitcoindark/src$ make -f makefile.unix
g++ -c -O2  -pthread -Wall -Wextra -Wno-ignored-qualifiers -Wformat -Wformat-security -Wno-unused-parameter -g -DBOOST_SPIRIT_THREADSAFE -I/home/azure/workbench/Blockchains/bitcoindark/src -I/home/azure/workbench/Blockchains/bitcoindark/src/obj -DUSE_UPNP=0 -I/home/azure/workbench/Blockchains/bitcoindark/src/leveldb/include -I/home/azure/workbench/Blockchains/bitcoindark/src/leveldb/helpers -DHAVE_BUILD_INFO -fno-stack-protector -fstack-protector-all -Wstack-protector -D_FORTIFY_SOURCE=2  -MMD -MF obj/alert.d -o obj/alert.o alert.cpp
alert.cpp:273:1: fatal error: opening dependency file obj/alert.d: Datei oder Verzeichnis nicht gefunden
 }
 ^
compilation terminated.
make: *** [obj/alert.o] Fehler 1


Anyone got any hints for me? Thanks!

Are you building from the laowais repo? Or the dev repo?

If the laowais:
Code:
mkdir obj obj/zerocoin

Matthew
legendary
Activity: 1181
Merit: 1018
September 26, 2014, 09:50:46 AM

Ok so I am partially successful in building bitcoindark.

I did manange to build Bitcoindark-qt and it is running nicely. I also got 0.0005 or so from a faucet, so it appears to running correctly.

Now I am a bit insecure because I can not find any wallet encryption. Since I rarely use bitcoin (NXT rulez!), I vaguely remember that tehre was s.t. about that.

Was that omitted in BTCD on purpose or did my build go wrong somehow and the encryption got dropped out?
 

Also, I do NOT get the headless testserver to build- and usually it is the gui stuff that is more bitchy than the server stuff:

notary@notty:~/workbench/Blockchains/bitcoindark/doc$ cd ../src/
notary@notty:~/workbench/Blockchains/bitcoindark/src$ make -f makefile.unix
g++ -c -O2  -pthread -Wall -Wextra -Wno-ignored-qualifiers -Wformat -Wformat-security -Wno-unused-parameter -g -DBOOST_SPIRIT_THREADSAFE -I/home/azure/workbench/Blockchains/bitcoindark/src -I/home/azure/workbench/Blockchains/bitcoindark/src/obj -DUSE_UPNP=0 -I/home/azure/workbench/Blockchains/bitcoindark/src/leveldb/include -I/home/azure/workbench/Blockchains/bitcoindark/src/leveldb/helpers -DHAVE_BUILD_INFO -fno-stack-protector -fstack-protector-all -Wstack-protector -D_FORTIFY_SOURCE=2  -MMD -MF obj/alert.d -o obj/alert.o alert.cpp
alert.cpp:273:1: fatal error: opening dependency file obj/alert.d: Datei oder Verzeichnis nicht gefunden
 }
 ^
compilation terminated.
make: *** [obj/alert.o] Fehler 1


Anyone got any hints for me? Thanks!
hero member
Activity: 690
Merit: 501
September 26, 2014, 08:26:20 AM
Price dropping on Bittrex? People haven't been reading the forum the past couple of days!

Good, I'm still buying  Smiley Smiley
full member
Activity: 237
Merit: 100
September 26, 2014, 05:46:38 AM
the blockchain is used to verify the funds before crediting the sender
Alice wants to buy something from Bob and Jack, but has enough money only for one purchase, not both. Nonetheless she sends her privkeys to them both, they verify that funds indeed belong to the privkey, and send her the purchases. After waiting reasonable amount of time, so that the purchases already sent, Alice performs regular onchain transaction sending the funds to herself.

Bob sweeps the funds into a new account (on blockchain). Jack or Alice can no longer spend them.
hero member
Activity: 572
Merit: 506
September 26, 2014, 05:18:26 AM
the blockchain is used to verify the funds before crediting the sender
Alice wants to buy something from Bob and Jack, but has enough money only for one purchase, not both. Nonetheless she sends her privkeys to them both, they verify that funds indeed belong to the privkey, and send her the purchases. After waiting reasonable amount of time, so that the purchases already sent, Alice performs regular onchain transaction sending the funds to herself.

Please read the whole whitepaper or check the post made before in this Thread. People already asked this question the whole time without taking their time to investigate them self.

You want to learn something ? Spend some time, we won't do the thinking for you.
All I see relates to sofisticated routing, onion layers, telepod fragmenting, etc. I ask simple question however. If you know a post where it's answered, please point to that post.
sr. member
Activity: 364
Merit: 250
September 26, 2014, 04:17:55 AM
The market on Bittrex is not reflecting the latest developments I see  Undecided
legendary
Activity: 1764
Merit: 1031
September 26, 2014, 02:56:23 AM
I tryed reading the whitepaper, although I didn't read it to the end. Do I understand right, that basically the idea is safely sending privkeys to transaction recipient?

You can broadly think of it that way, though with various extra safeguards. If you use an address that has never been used before, and there is no way of tracking you outside the blockchain (which is incredibly easy in many cases) then the transaction cannot be traced to you.

Think of it like playing pass the parcel in the dark, except you and the recipient are wearing infrared goggles.

I love this analogy Cassius!!  It's original and it made me smile seeing the mental picture Smiley

You'll appreciate from James' response that it's a little more complicated than that. But this is the 'GUI stuff' version Smiley
hero member
Activity: 572
Merit: 506
September 26, 2014, 02:07:43 AM
the blockchain is used to verify the funds before crediting the sender
Alice wants to buy something from Bob and Jack, but has enough money only for one purchase, not both. Nonetheless she sends her privkeys to them both, they verify that funds indeed belong to the privkey, and send her the purchases. After waiting reasonable amount of time, so that the purchases already sent, Alice performs regular onchain transaction sending the funds to herself.
legendary
Activity: 1764
Merit: 1000
September 25, 2014, 10:01:36 PM
the darkhole is dying
newbie
Activity: 43
Merit: 0
September 25, 2014, 09:48:01 PM
sweet, all u do is greatly appreciated very much
sr. member
Activity: 255
Merit: 251
September 25, 2014, 09:41:45 PM
just had first successful SuperNET message from one of my servers to someone else's server!


I hope everyone here appreciates what is going on right now!

SuperNET is now being actively tested, anyone who knows their way around a command line can volunteer to help out over at forum.thesupernet.org

I am very excited about where we are headed value-wise. This is going to change our community for the better Smiley

Matthew
legendary
Activity: 1176
Merit: 1134
September 25, 2014, 09:24:58 PM
just had first successful SuperNET message from one of my servers to someone else's server!
legendary
Activity: 1176
Merit: 1134
September 25, 2014, 08:56:27 PM
I am doing a design level review with anonymint via PM
Also Kristov Atlas will be doing a review, hopefully of both the design level and the code conformance to the design

James
legendary
Activity: 1206
Merit: 1000
September 25, 2014, 08:35:09 PM
I tryed reading the whitepaper, although I didn't read it to the end. Do I understand right, that basically the idea is safely sending privkeys to transaction recipient?

You can broadly think of it that way, though with various extra safeguards. If you use an address that has never been used before, and there is no way of tracking you outside the blockchain (which is incredibly easy in many cases) then the transaction cannot be traced to you.

Think of it like playing pass the parcel in the dark, except you and the recipient are wearing infrared goggles.

I love this analogy Cassius!!  It's original and it made me smile seeing the mental picture Smiley
legendary
Activity: 1176
Merit: 1134
September 25, 2014, 04:01:30 PM
I tryed reading the whitepaper, although I didn't read it to the end. Do I understand right, that basically the idea is safely sending privkeys to transaction recipient?
There is the encapsulation of funds into a self-contained package (telepod)
This is then sent and verified (cloned) so that the anon set is all the clonings during the specified timewindow (clonesmear)

However, different users have different clonesmear parameters so the attacker wont even know what the complete anon set is.

With the addition of even a small percentage of trusted teleports, the sender's anon set is the entire duration from the sender's cloning (when the funds were received) to when the destination account clones. this could literally be everybody as it is possible to age a telepod for months.

There are random delays wherever possible to make correlations difficult. Even the selection process of what telepods to use to fulfull a tx using a genetic algorithm that is based on evolution toward the best metric, but it is a stochastic process.

Each packet is put into L onion layers. The number of onion layers is randomized so it could be 1 layer or L.

The private nodes use probabilistic routing, or rather the network uses probabilistic routing to reach the private nodes. There is no (IP <-> acct) mapping, just a statistical histogram that each node that ever received a message from the private node maintains. For nodes that never received a direct message, there is no historical data to even look at. Each private node can determine what public nodes it announces itself to, and it will use its own loopback privacy server as a gateway to do this. It is possible that a determined attacker can do some brute force sybil attack to get a higher than noise level correlation of (IP <-> acct) so if you are really privacy minded, I would advise to NEVER publish your really private acct #. Only send this really private acct number to people you absolutely trust over the encrypted network. If the attacker doesnt know your acct #, then he cant run any sybil attacks to correlate it. Also, the longer the clonesmear window, the more private, so be patient and let time be your friend

Then there is the M of N fragmenting of each telepod with probabilistic dropout at each hop. What that means is that looking at packet traffic, it is quite difficult to know if a packet coming in was meant for that node, or whether it was dropped. Nor whether a packet coming out was originated from that node or just forwarded. When M packets arrive, the telepod is reassembled just like it was sent "directly"

As you can see Teleport is a bit more than "safely sending privkeys to transaction recipient"

James

P.S. ./BitcoinDarkd SuperNET '{"requestType":"sendmessage","dest":"13434315136155299987","msg":"hello"}'

The above is how to invoke the SuperNET API sendmessage command to send the message "hello" to dest acct 13434315136155299987
I don't see how doublespends coud be prevented with this approach.
the blockchain is used to verify the funds before crediting the sender
hero member
Activity: 572
Merit: 506
September 25, 2014, 03:49:29 PM
I tryed reading the whitepaper, although I didn't read it to the end. Do I understand right, that basically the idea is safely sending privkeys to transaction recipient?
There is the encapsulation of funds into a self-contained package (telepod)
This is then sent and verified (cloned) so that the anon set is all the clonings during the specified timewindow (clonesmear)

However, different users have different clonesmear parameters so the attacker wont even know what the complete anon set is.

With the addition of even a small percentage of trusted teleports, the sender's anon set is the entire duration from the sender's cloning (when the funds were received) to when the destination account clones. this could literally be everybody as it is possible to age a telepod for months.

There are random delays wherever possible to make correlations difficult. Even the selection process of what telepods to use to fulfull a tx using a genetic algorithm that is based on evolution toward the best metric, but it is a stochastic process.

Each packet is put into L onion layers. The number of onion layers is randomized so it could be 1 layer or L.

The private nodes use probabilistic routing, or rather the network uses probabilistic routing to reach the private nodes. There is no (IP <-> acct) mapping, just a statistical histogram that each node that ever received a message from the private node maintains. For nodes that never received a direct message, there is no historical data to even look at. Each private node can determine what public nodes it announces itself to, and it will use its own loopback privacy server as a gateway to do this. It is possible that a determined attacker can do some brute force sybil attack to get a higher than noise level correlation of (IP <-> acct) so if you are really privacy minded, I would advise to NEVER publish your really private acct #. Only send this really private acct number to people you absolutely trust over the encrypted network. If the attacker doesnt know your acct #, then he cant run any sybil attacks to correlate it. Also, the longer the clonesmear window, the more private, so be patient and let time be your friend

Then there is the M of N fragmenting of each telepod with probabilistic dropout at each hop. What that means is that looking at packet traffic, it is quite difficult to know if a packet coming in was meant for that node, or whether it was dropped. Nor whether a packet coming out was originated from that node or just forwarded. When M packets arrive, the telepod is reassembled just like it was sent "directly"

As you can see Teleport is a bit more than "safely sending privkeys to transaction recipient"

James

P.S. ./BitcoinDarkd SuperNET '{"requestType":"sendmessage","dest":"13434315136155299987","msg":"hello"}'

The above is how to invoke the SuperNET API sendmessage command to send the message "hello" to dest acct 13434315136155299987
I don't see how doublespends coud be prevented with this approach.
legendary
Activity: 1176
Merit: 1134
September 25, 2014, 01:54:51 PM
hehe maybe those ten testers with the VPNs ran into the higgs particle while testing and fried all the circuits. ?  Wink

Are they doing this proof of concept test within the live environment?  Shocked
That's what test networks are good for!

SuperNET integration will not cause a hard fork. Current nodes will completely ignore our testing  Smiley
However the multisig expansion and PoS v2 will cause a hardfork
legendary
Activity: 1176
Merit: 1134
September 25, 2014, 01:53:37 PM
I tryed reading the whitepaper, although I didn't read it to the end. Do I understand right, that basically the idea is safely sending privkeys to transaction recipient?
There is the encapsulation of funds into a self-contained package (telepod)
This is then sent and verified (cloned) so that the anon set is all the clonings during the specified timewindow (clonesmear)

However, different users have different clonesmear parameters so the attacker wont even know what the complete anon set is.

With the addition of even a small percentage of trusted teleports, the sender's anon set is the entire duration from the sender's cloning (when the funds were received) to when the destination account clones. this could literally be everybody as it is possible to age a telepod for months.

There are random delays wherever possible to make correlations difficult. Even the selection process of what telepods to use to fulfull a tx using a genetic algorithm that is based on evolution toward the best metric, but it is a stochastic process.

Each packet is put into L onion layers. The number of onion layers is randomized so it could be 1 layer or L.

The private nodes use probabilistic routing, or rather the network uses probabilistic routing to reach the private nodes. There is no (IP <-> acct) mapping, just a statistical histogram that each node that ever received a message from the private node maintains. For nodes that never received a direct message, there is no historical data to even look at. Each private node can determine what public nodes it announces itself to, and it will use its own loopback privacy server as a gateway to do this. It is possible that a determined attacker can do some brute force sybil attack to get a higher than noise level correlation of (IP <-> acct) so if you are really privacy minded, I would advise to NEVER publish your really private acct #. Only send this really private acct number to people you absolutely trust over the encrypted network. If the attacker doesnt know your acct #, then he cant run any sybil attacks to correlate it. Also, the longer the clonesmear window, the more private, so be patient and let time be your friend

Then there is the M of N fragmenting of each telepod with probabilistic dropout at each hop. What that means is that looking at packet traffic, it is quite difficult to know if a packet coming in was meant for that node, or whether it was dropped. Nor whether a packet coming out was originated from that node or just forwarded. When M packets arrive, the telepod is reassembled just like it was sent "directly"

As you can see Teleport is a bit more than "safely sending privkeys to transaction recipient"

James

P.S. ./BitcoinDarkd SuperNET '{"requestType":"sendmessage","dest":"13434315136155299987","msg":"hello"}'

The above is how to invoke the SuperNET API sendmessage command to send the message "hello" to dest acct 13434315136155299987
Jump to: