Obyte: Totally new consensus algorithm + private untraceable payments

[drays]

Sorry if this sounds lame (I admit I didn't read the whole whitepaper ), but is there any way to see in block explorer or anywhere else, the date/time when a transaction is actually made!?  

[1714210513]

1714210513

[1714210513]

1714210513

[1714210513]

1714210513

[1714210513]

1714210513

[CryptKeeper]

Sorry if this sounds lame (I admit I didn't read the whole whitepaper ), but is there any way to see in block explorer or anywhere else, the date/time when a transaction is actually made!?  

Look in the wallet at the "History" tab, then click on a tx to see the details.

[drays]

Sorry if this sounds lame (I admit I didn't read the whole whitepaper ), but is there any way to see in block explorer or anywhere else, the date/time when a transaction is actually made!?  

Look in the wallet at the "History" tab, then click on a tx to see the details.

Ok, thanks. But I meant the transactions made by others (not from/to my wallet)
Is there any way to see the timestamps on them?

[Dynamic Index]

So before the supposed snapshot in med February, would it be more profitable to buy bytes of exchange and store in wallet (will simply storing the byte in wallet gain byte at snapchat)?

Or to link BTC address and gain byte that way

Let's assume with the same amount of bitcoin that you would be buying byte with or linking.

[yvv]

So before the supposed snapshot in med February, would it be more profitable to buy bytes of exchange and store in wallet (will simply storing the byte in wallet gain byte at snapchat)?

Or to link BTC address and gain byte that way

Let's assume with the same amount of bitcoin that you would be buying byte with or linking.

Just do your math bro During next giveaway, 1BTC gives you 62.5Mb, the same amount as 625Mb gives you. So, if bytes are cheaper than 625Mb per BTC, it is better to buy bytes with BTC, otherwise sell bytes to have more BTC.

[Dynamic Index]

So before the supposed snapshot in med February, would it be more profitable to buy bytes of exchange and store in wallet (will simply storing the byte in wallet gain byte at snapchat)?

Or to link BTC address and gain byte that way

Let's assume with the same amount of bitcoin that you would be buying byte with or linking.

Just do your math bro During next giveaway, 1BTC gives you 62.5Mb, the same amount as 625Mb gives you. So, if bytes are cheaper than 625Mb per BTC, it is better to buy bytes with BTC, otherwise sell bytes to have more BTC.

What if I were to take a bank loan out for lets say one month of $50,000 and buy 62 bitcoin. Then I wait until snapshot, verify bitcoin address, receive Mb, then sell bitcoin to pay back loan?

[Dynamic Index]

Okay a serious question:  What's the best way to backup wallet?  I wrote down restore phrase and wrote down encryption key.  Do I need to backup anything else?  I couldn't find a wallet.dat in application support (mac)

[CryptKeeper]

Okay a serious question:  What's the best way to backup wallet?  I wrote down restore phrase and wrote down encryption key.  Do I need to backup anything else?  I couldn't find a wallet.dat in application support (mac)

FYI

Byteball Backups and Recovery

Byteball uses a single extended private key for all wallets, BIP44 is used for wallet address derivation. There is a BIP39 mnemonic for backing up the wallet key, but it is not enough. Private payments and co-signers of multisig wallets are stored only in the app's data directory, which you have to back up manually:

macOS: ~/Library/Application Support/byteball
Linux: ~/.config/byteball
Windows: %LOCALAPPDATA%\byteball

[jwinterm]

CryptKeeper, are you and how much are you getting paid to run this thread? Are there other people on "the team" getting compensated? Where's the money coming to pay people, presuming people are getting paid?

[Dynamic Index]

Okay a serious question:  What's the best way to backup wallet?  I wrote down restore phrase and wrote down encryption key.  Do I need to backup anything else?  I couldn't find a wallet.dat in application support (mac)

FYI

Byteball Backups and Recovery

Byteball uses a single extended private key for all wallets, BIP44 is used for wallet address derivation. There is a BIP39 mnemonic for backing up the wallet key, but it is not enough. Private payments and co-signers of multisig wallets are stored only in the app's data directory, which you have to back up manually:

macOS: ~/Library/Application Support/byteball
Linux: ~/.config/byteball
Windows: %LOCALAPPDATA%\byteball

Is this data encrypted?  I'm about to store on secure cloud account.

[Espo]

Okay a serious question:  What's the best way to backup wallet?  I wrote down restore phrase and wrote down encryption key.  Do I need to backup anything else?  I couldn't find a wallet.dat in application support (mac)

FYI

Byteball Backups and Recovery

Byteball uses a single extended private key for all wallets, BIP44 is used for wallet address derivation. There is a BIP39 mnemonic for backing up the wallet key, but it is not enough. Private payments and co-signers of multisig wallets are stored only in the app's data directory, which you have to back up manually:

macOS: ~/Library/Application Support/byteball
Linux: ~/.config/byteball
Windows: %LOCALAPPDATA%\byteball

Is this data encrypted?  I'm about to store on secure cloud account.

No, You should ZIP/RAR the files with a strong Password.

[WorldCoiner]

CryptKeeper, are you and how much are you getting paid to run this thread? Are there other people on "the team" getting compensated? Where's the money coming to pay people, presuming people are getting paid?

Cryptkeeper is just a nice guy and community member, that did this purely out of altruistic reasons.
To be honest, me supporting Byteball also without small financial benefit (during the distribution I have had 3.5 BTC, really not a Byteball whale at all).
But I like Tony and I’m really impressed what he was able the achieve in such a short timeframe. Especially I focus always at new technology and the DAG can be the revolution of Cryptocurrency. It's in my view really a new generation, the third one.

There is at the moment no money at the table. Just the value of the Byteball we have received through the distribution can be lifted.

[Come-from-Beyond]

This explains why there is no a protection against an eclipse attack, which can be conducted if a naive peer discovery is used (which is the case of Byteball, I noticed this trying to recover byteballs of my friend). In IOTA necessity to talk to people is an anti-Sybil measure. Poor SatoNatomato doesn't understand all these nuances, I suggest to forgive his childishness.

For the record, peer discovery is irrelevant to consensus in Byteball.  Even if Sybiled, a node cannot select a wrong branch, by design.  The worst that can happen to a node while it is Sybiled, is that the node will stay stuck at some old point on the DAG, as if it were offline.  CfB if you want to reply, IOTA thread is not the best place for in-depth discussion of Byteball, post to https://bitcointalk.org/index.php?topic=1608859.0.

This is an attack that came to my mind while I was reading the source code trying to get what "device ID" was for:

The whitepaper says:

There is no partial order between them. In this case, we accept both. We establish a total order between the units later on, when they are buried deep enough under newer units (see below how we do it). The one that appears earlier on the total order is deemed valid, while the other is deemed invalid.

In normal use, people mostly link their new units to slightly less recent units, meaning that the DAG grows only in one direction.

The former allows to trick a user into believing that he received coins (if we can censor the traffic). The latter allows to make the others extend a branch we need (if we can (to some extent) censor the global traffic).

Imagine that I have poisoned the network and 90% of the nodes (not physical machines, just IPs) are controlled by me. What stops me from scamming a merchant in such way:

1. Issue a payment to the merchant and a payment to myself with "no partial order between them"
2. Make the others to prioritize the payment to myself (the branch with the payment to merchants will be extend too and this is the only transactions the merchant will see)
3. Get the purchased item delivered
4. Stop the attack, my payment is already considered as a part of the main chain, let the merchant to see that his payment is not.

[kaicrypzen]

Is there a trading thread?

Yes there is: https://bitcointalk.org/index.php?topic=1728405. You can also trade on Slack: https://byteball.slack.com, check the channels #trading, #book, #auctionroom and #trading_blackbyte.

[coinhugger]

This explains why there is no a protection against an eclipse attack, which can be conducted if a naive peer discovery is used (which is the case of Byteball, I noticed this trying to recover byteballs of my friend). In IOTA necessity to talk to people is an anti-Sybil measure. Poor SatoNatomato doesn't understand all these nuances, I suggest to forgive his childishness.

For the record, peer discovery is irrelevant to consensus in Byteball.  Even if Sybiled, a node cannot select a wrong branch, by design.  The worst that can happen to a node while it is Sybiled, is that the node will stay stuck at some old point on the DAG, as if it were offline.  CfB if you want to reply, IOTA thread is not the best place for in-depth discussion of Byteball, post to https://bitcointalk.org/index.php?topic=1608859.0.

This is an attack that came to my mind while I was reading the source code trying to get what "device ID" was for:

The whitepaper says:

There is no partial order between them. In this case, we accept both. We establish a total order between the units later on, when they are buried deep enough under newer units (see below how we do it). The one that appears earlier on the total order is deemed valid, while the other is deemed invalid.

In normal use, people mostly link their new units to slightly less recent units, meaning that the DAG grows only in one direction.

The former allows to trick a user into believing that he received coins (if we can censor the traffic). The latter allows to make the others extend a branch we need (if we can (to some extent) censor the global traffic).

Imagine that I have poisoned the network and 90% of the nodes (not physical machines, just IPs) are controlled by me. What stops me from scamming a merchant in such way:

1. Issue a payment to the merchant and a payment to myself with "no partial order between them"
2. Make the others to prioritize the payment to myself (the branch with the payment to merchants will be extend too and this is the only transactions the merchant will see)
3. Get the purchased item delivered
4. Stop the attack, my payment is already considered as a part of the main chain, let the merchant to see that his payment is not.

This is a scary thought. I hope the developer can mitigate this potential vulnerability if the above-mentioned procedure really works.

[tonych]

Sorry if this sounds lame (I admit I didn't read the whole whitepaper ), but is there any way to see in block explorer or anywhere else, the date/time when a transaction is actually made!?  

Look in the wallet at the "History" tab, then click on a tx to see the details.

Ok, thanks. But I meant the transactions made by others (not from/to my wallet)
Is there any way to see the timestamps on them?

There are no timestamps in Byteball protocol, they are just not needed.  That's why there are no reliable timestamps.  The ones you see in History tab are the times and dates when your wallet first learnt about the transaction (or, if you are on light wallet, when the light vendor first learnt about the tx).

[SatoNatomato]

This explains why there is no a protection against an eclipse attack, which can be conducted if a naive peer discovery is used (which is the case of Byteball, I noticed this trying to recover byteballs of my friend). In IOTA necessity to talk to people is an anti-Sybil measure. Poor SatoNatomato doesn't understand all these nuances, I suggest to forgive his childishness.

For the record, peer discovery is irrelevant to consensus in Byteball.  Even if Sybiled, a node cannot select a wrong branch, by design.  The worst that can happen to a node while it is Sybiled, is that the node will stay stuck at some old point on the DAG, as if it were offline.  CfB if you want to reply, IOTA thread is not the best place for in-depth discussion of Byteball, post to https://bitcointalk.org/index.php?topic=1608859.0.

This is an attack that came to my mind while I was reading the source code trying to get what "device ID" was for:

The whitepaper says:

There is no partial order between them. In this case, we accept both. We establish a total order between the units later on, when they are buried deep enough under newer units (see below how we do it). The one that appears earlier on the total order is deemed valid, while the other is deemed invalid.

In normal use, people mostly link their new units to slightly less recent units, meaning that the DAG grows only in one direction.

The former allows to trick a user into believing that he received coins (if we can censor the traffic). The latter allows to make the others extend a branch we need (if we can (to some extent) censor the global traffic).

Imagine that I have poisoned the network and 90% of the nodes (not physical machines, just IPs) are controlled by me. What stops me from scamming a merchant in such way:

1. Issue a payment to the merchant and a payment to myself with "no partial order between them"
2. Make the others to prioritize the payment to myself (the branch with the payment to merchants will be extend too and this is the only transactions the merchant will see)
3. Get the purchased item delivered
4. Stop the attack, my payment is already considered as a part of the main chain, let the merchant to see that his payment is not.

This is a scary thought. I hope the developer can mitigate this potential vulnerability if the above-mentioned procedure really works.

Its bull and FUD, which CFB would have known if he actually read the whitepaper.

This is what witnesses are for, the payment is not Finaluzed as Confirmed unless a witness sees it, which in the scenario doesnt happen. Its the same dumb attack as sending a goods after no confirmations in bitcoin.

[tonych]

This explains why there is no a protection against an eclipse attack, which can be conducted if a naive peer discovery is used (which is the case of Byteball, I noticed this trying to recover byteballs of my friend). In IOTA necessity to talk to people is an anti-Sybil measure. Poor SatoNatomato doesn't understand all these nuances, I suggest to forgive his childishness.

For the record, peer discovery is irrelevant to consensus in Byteball.  Even if Sybiled, a node cannot select a wrong branch, by design.  The worst that can happen to a node while it is Sybiled, is that the node will stay stuck at some old point on the DAG, as if it were offline.  CfB if you want to reply, IOTA thread is not the best place for in-depth discussion of Byteball, post to https://bitcointalk.org/index.php?topic=1608859.0.

This is an attack that came to my mind while I was reading the source code trying to get what "device ID" was for:

The whitepaper says:

There is no partial order between them. In this case, we accept both. We establish a total order between the units later on, when they are buried deep enough under newer units (see below how we do it). The one that appears earlier on the total order is deemed valid, while the other is deemed invalid.

In normal use, people mostly link their new units to slightly less recent units, meaning that the DAG grows only in one direction.

The former allows to trick a user into believing that he received coins (if we can censor the traffic). The latter allows to make the others extend a branch we need (if we can (to some extent) censor the global traffic).

Imagine that I have poisoned the network and 90% of the nodes (not physical machines, just IPs) are controlled by me. What stops me from scamming a merchant in such way:

1. Issue a payment to the merchant and a payment to myself with "no partial order between them"
2. Make the others to prioritize the payment to myself (the branch with the payment to merchants will be extend too and this is the only transactions the merchant will see)
3. Get the purchased item delivered
4. Stop the attack, my payment is already considered as a part of the main chain, let the merchant to see that his payment is not.

If the user waits that the transaction is final, he cannot be defrauded.
In your example, you isolate the merchant from the real network and feed him with a fake branch.  The merchant will accept your units and add them to his version of the DAG, but since there are no witness-authored units on your branch, it will not move the stability point forward and your double-spent payment will stay unconfirmed for as long as your attack continues.  Number of nodes is totally irrelevant, it is the presence of witnesses what makes a branch real.

[coinhugger]

This explains why there is no a protection against an eclipse attack, which can be conducted if a naive peer discovery is used (which is the case of Byteball, I noticed this trying to recover byteballs of my friend). In IOTA necessity to talk to people is an anti-Sybil measure. Poor SatoNatomato doesn't understand all these nuances, I suggest to forgive his childishness.

For the record, peer discovery is irrelevant to consensus in Byteball.  Even if Sybiled, a node cannot select a wrong branch, by design.  The worst that can happen to a node while it is Sybiled, is that the node will stay stuck at some old point on the DAG, as if it were offline.  CfB if you want to reply, IOTA thread is not the best place for in-depth discussion of Byteball, post to https://bitcointalk.org/index.php?topic=1608859.0.

This is an attack that came to my mind while I was reading the source code trying to get what "device ID" was for:

The whitepaper says:

There is no partial order between them. In this case, we accept both. We establish a total order between the units later on, when they are buried deep enough under newer units (see below how we do it). The one that appears earlier on the total order is deemed valid, while the other is deemed invalid.

In normal use, people mostly link their new units to slightly less recent units, meaning that the DAG grows only in one direction.

The former allows to trick a user into believing that he received coins (if we can censor the traffic). The latter allows to make the others extend a branch we need (if we can (to some extent) censor the global traffic).

Imagine that I have poisoned the network and 90% of the nodes (not physical machines, just IPs) are controlled by me. What stops me from scamming a merchant in such way:

1. Issue a payment to the merchant and a payment to myself with "no partial order between them"
2. Make the others to prioritize the payment to myself (the branch with the payment to merchants will be extend too and this is the only transactions the merchant will see)
3. Get the purchased item delivered
4. Stop the attack, my payment is already considered as a part of the main chain, let the merchant to see that his payment is not.

If the user waits that the transaction is final, he cannot be defrauded.
In your example, you isolate the merchant from the real network and feed him with a fake branch.  The merchant will accept your units and add them to his version of the DAG, but since there are no witness-authored units on your branch, it will not move the stability point forward and your double-spent payment will stay unconfirmed for as long as your attack continues.  Number of nodes is totally irrelevant, it is the presence of witnesses what makes a branch real.

@Tonych, thanks for clearing that up. Nothing to worry about then. Keep up the good work!

 

[Come-from-Beyond]

If the user waits that the transaction is final, he cannot be defrauded.
In your example, you isolate the merchant from the real network and feed him with a fake branch.  The merchant will accept your units and add them to his version of the DAG, but since there are no witness-authored units on your branch, it will not move the stability point forward and your double-spent payment will stay unconfirmed for as long as your attack continues.  Number of nodes is totally irrelevant, it is the presence of witnesses what makes a branch real.

Great, I hope now SatoNatomato sees why IOTA couldn't use the same method of peer discovery.