Hello Oldtimegin!

The goal of the money we are going to raise with this project, is to build a decentralized platform that allows FinTech specialists and companies to find each-other directly, without an intermediate party in the middle.

More information can be found in our Whitepaper.

Thanks,

~Wiebe-Marten, CTO of FintechFans

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

The last couple of weeks I've been talking to a group of developers, and it turned out we had a mutual itch: There was not yet a location where any developer working with any typeo f Blockchains or other Distributed Ledgers could exchange information with other developers. All the communities that exist today are focused around one single technology, and objective comparisons between these technologies are nearly non-existent.

Also, there is very little communication between technologies, which is unfortunate since there is a very large overlap between the different technologies that are being used and created.


This is why the Distributed Ledger Technologies forum (dltforum.org) has been created. You're invited to join us and  talk about any type of Distributed Ledgers, Blockchains, Consensus algorithms, decentralized data storage and all the other related technologies.
There both is this forum, as well as a Discord group, for people who want more direct, semi-ephemeral contact.

I hope to maybe see you there. The community is very new, so all contributions are greatly valued.
Also, feedback is very welcome. :-)

~Wiebe-Marten/Qqwy


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJaIpE2AAoJEBfPRUP+BdzsGvQP/0nj+dopbBT8qLnqp7tiS/ne
wSExxzYaMOvMWfuKk8+ia7SdsNyM7EpZ3avyUZF2QxhKa1ttZcQX1xgDDihPtE78
LgfjNCrmt3yvSSW0YavYnj3wPFA7JC4/Qx1Vn6waY/Dzxx/3N/TdAUIWsC6em97a
pjIE+D+vJBtcPKck9vgWo3mA4wWwF7bV/o7mXTVOR0AQHcrLlJ+VI2ht+ocH++88
nAF5BtQFw1gD2qgrCHqXu4KB5iatlFo0UxAssBeF5QFOaDTUS5cYNoK3tHKsoqBR
93XBzqPgyW9iaJEWNxTuCVkswDGOlP1p+0NogWKCKI+5SEeznFXk2w19jtlJpyrJ
dwVWcjFGwqOsC+1JPRqUZAJdCOkGQWfMQXe4r8A/EvBX81sq4PPT9YLvKDD58ex3
e5qfg7j/6S3v/wktNuyjqeLYHtS7mCXKls/+V5G/1AxWX/Hgjw3hcG8yb/I8TALC
udDBfX7JySw1lVlwZp/B+6nlpVc8DbYUPJ+ejO1so5q3owA/c5uYnlOFu5vPfbgB
9NbCnNqdYCfEQhZRenB8uiflzORqhXh6THZY0DDTczRJZbeTvlqIhh+WVXhP7uU1
h80c6Oj5gi7qI4UaunusYCxtmqTuqlI/Zx5Gi56IAT77D7Ccurg9VhAc3COeOsV6
mlTFx+up8SG0le/kGEnF
=cCQI
-----END PGP SIGNATURE-----

That said, it is of course a lot of fun and a good exercise both for your mental prowess as well as your focusing ability :-)

~Wiebe-Marten

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512



The Bitcoin blockchain currently consumes more energy than the total consumption of the state of Ireland. The total energy consumption of even a concern-size company, even including energy consumers like airconditioning, heating, lifts, coffee machines and photocopiers, will be FAR below this.

~Wiebe-Marten


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBCgAGBQJaDWp2AAoJEBfPRUP+Bdzs7yYQAKQV84Zx/OFG7MZXUPUdkVq0
oJ8vuD4XQRQoYQmbBGplyUqhyQwexbxQz9CYH6jplhe18CTRcw26yB9XY8zjJwRv
TrLw2zikpqO6nBPV72t2WahZRHoJ497RykoMwmyiPUedR7M+GRPv0t/rvqVRchWh
wgM6OoGZ27qhO7Q50s97hT4S9WaI5YNVDCQtN5T+Mc4EyAXgaEQqPP7TujyTNylh
JomxX7VgEKW+MmP/5Dv1JY3MhnwsH0ivFNkXR8bkqI6I9CfnoE5QJGUMwySBfXvz
7VoiqvzFZAxv79lgig+edeAdo+y7Wg89HyKLcnk3kvdgGfWFEFZncY+RPu2inamh
iitrLa26qao94EL9GmrR0wdgQKdJyGz7CBVcHIC9XtnJwZgnDRBC7ncSgdUpbtjt
Ry7OLH4ZyE/gDK5Q3wjn+OAv7SphGQDiP+RmXLpt3hQG6/FM20aDH/MobUL9O27R
uPRacztrOT7+8Yhr1UytNr4r8tjCI1AFRAuG9aPjHVZbaP5oJEQCc1vmYatF0dIM
pJlSD4tyqLXN/oannRr04to72cPLr7FCRtjJ/8ximjQ1INtIZtdU5eu0ctS0zXfD
usPmtm3PIJCOelCXZD0Q34SJZKWhTDqdWcBv3wXgcNdkpOCNgciSH40NU5xtKfRv
5ZmivIl2n4cFl7iQZ62c
=HMAn
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512




DevOps indeed stands for Development Operations. This mostly means the costs of server/infrastructure maintenance (of the centralized aspects of our architecture).

---

For who is interested, the Source Code of the Smart Contract(s) to run the Tokensale is available on GitHub. Any criticism and feedback is of course extremely welcome!

~Wiebe-Marten, CTO of this project


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBCgAGBQJaDVP9AAoJEC6j/0EVBxxBRVwP/jWlRqWT3unb555ltEVL55li
fyvZMWAfLZotaHsfoAcLuT2ZMcp5zE1BraC1XthO67FEOjeRzBcDnpRAcl4NcEMu
vGtLAn166XgqQjNvtVwkbTC6Ino4POeUictVTeingSD3iegST2LV36Scpo8mvGSd
TCZRArUCNP2WqSoC3qHru4L9LiQi8h4Q+rMb1Jf25te9MtfmCEwwroPMh/JRgNuk
pik7/7DjUBqhxIaAkFsjSQ133gxlJHXo+97crF3ywiS3sNKbesBaEG6uhaXonS6W
dCT5LsuV6qgzVipps37bYMdqoqBPGAzaCcw/MFY0iEnykpyC4xp1rgJKW3lqp1A8
gTsnPiHBTDdy50zMliWuiq9Ln9zH3mt3ihOWozg0yjDqSwwylUzFlmHzlVdXMhqZ
3roJxTARfNc0GynYY21JbM0Ca1+SBKV5o0ml7oTdDKaZnmOIOTBCUsRksBlEhY9W
m1VVKEWrd5o7gw+0qmRTwGMqPttaxoVOnxgI8Zv9KXX7B/hWeAgp7f1UPwwOcNGJ
EvMfj8fgf2SQyuN1K8EVI+jcf+OOb1GVeoo40qP4JDkgj4KqxFuzcSfdFrBOTuXf
T36yySVybQSJszDLt91OAp6pDRVtirsHNIjQ+GGPgXHRNogsFKzXafz+N0PSdUpF
qsmA2Ezd8k+1/on6MuXg
=UQQR
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512


The fun fact about open source software, is that this is software in which it is not required to have a business model built in. This means that suddenly completely different design choices are possible.

Forking an open source project is not a weakness, it is a strength: If the original version of some tool is wide-spread, then people know that version and will keep using it. If, however, it turns out to have some flaws that the original development team does not fix, then it is possible for people to move to their own variant.

If it is at all possible to reconcile, developers will by using Pull Requests. And if it is not, then it is great to create two versions, where each version is better suited for some particular requirients.

> IS THERE A WAY TO KEEP SUCH IMPORTANT SOFTWARE OPEN SOURCE (to be able to vet it) WHILE STILL PROVIDING MEANINGFUL FINANCIAL INCENTIVE TO DEVELOPERS?

Yes, there is. Companies like GitLab and Piwik do so with great success :-).



By the way, it is also possible to open-source paid software, and open-source software in such a way that you are the only party that is allowed to make money from it. Don't think that all projects have to go 'all the way' to FOSS (Free and open source).

~Wiebe-Marten


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBCgAGBQJaCxjwAAoJEBfPRUP+BdzsFLEP/1k284/4wZMiBCMZKO3x54Y/
wVvU3sKPAcPFsS2a2q/3Ai5WPtniKe4QlCzSL+TTsQzUipy8ggYYSs6o/gEcOMl0
CqcWAHEEZ5yPjFLlEEqPLNm0VucZj+YOLEP8BeSt5K0mbl1A4ddut9RBWB3dxy7A
s+uIBh2CL8zczR5fL70PJ3wMzRk3p80rVGKkk0cPjLaA7//L/NUkSB0sDydsj9oh
+wZxtsMIqGUZ6FVjOawE1vr80Aqb48UomOWxuAwCQY6gtLfK4imdRkfOSAEU/pZg
FyJ5fAS2pf/YjCXGcq5ps4E/qkQEYHZ/v+KF+coTruV0gSSAcRzT+MSuS7FblC8+
CkPkp0fvmMeUecf8p0q+Db/UDyLcOKds+5sc8X/gKlEC7OTi6y/N0pK0VRdNHiMI
T1SnXHTtrdWJH91Uf4VOY5yuUKeHj9CunQqBtDyJ30YkwvozZImsPbRoesXrKGT/
MsSrihiC0z2xIFXA1WGe75zzqRLYHpCtvRvIuUqkyJbEqFf+mJIpI4Ztt2LbTPkW
dW3cHduC/SsGF+6UnZ9IcM0AWI/9RCqHdMcG2CJhc/R7o43+FLDcwp/oKmfkzXkz
odEuIc+eVimzFjT3D58992cuqfKBlyrR5v4XhWPGuh64hDtiC3s3NmETPFu7Sd7r
A3nl7wVieJHOpHuXZD7R
=HSty
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512



This question is not basic at all. In my personal opinion, no 'dumb' questions exist, but only people that do not want to invest the time to answer.

Short answer: To transfer bitcoin funds, a party needs to have access to the private key of an address. Therefore, these systems need to have some way to do that.
I can think of:

1. The funds are only moved to the user's wallet once the user states that they want to be paid out. Or, alternatively, only transactions are made from a special wallet that the user explicitly fills.
2. The party _does_ know the user's seed/private key.
3. The address is a '1 of n' multisignature wallet. Hmm, in practice this would be similar to (2) I guess.
4. The user is asked every time a transaction is supposed to take place for their password.

I do know that most exchanges have full control over the funds you store at them, which is also why they go to rigorous lengths in attempts to prove that they are not stealing from anyone. (Also, some 'exchanges' did run away with money in the past).

I believe most exchanges use either (2) or (4) (haven't used them for a while though, so I do not have hard evidence).

~Wiebe-Marten
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBCgAGBQJaCv3xAAoJEBfPRUP+Bdzsn7IP/Rm346yY/TC+WwYItEuYYbjz
JUmVUYGRcLQye5eJEBe97mosG3RzCEbVk32cqGXTrO9NbzXHzY10GByohPYRGgJh
lG3k6Gn97XbIHCnnbzoy29o1EmS0OHB+jedMe2gb2eveIVyyB40gvCnmgK870cEu
5SpXsQw3ViTE9XB1r7w/Y96iPbR1z4rjlwgHYm8qqA2r9VZs2JwvXZibB7K8ceTW
xjDDeQpi3KAKySqvF6yKL+ize2566sr50fuChVSukR03Jej4Hm7ECRtvTZXihRuG
YFHxpViRqYiFsarEJGOIG0CirBBwipdfc52xOfbKoHWc4F45TVnlh0L3opjeCCq1
R7tSNrwOQloeiHNqGs5uTX5ph1jExgjrRssKg4MxoK8OlLYhJb1IMa5yjzKBbIuq
Zm97hKk+oXaW9ePeOMMDWh9ta8BEhuftmSzi1K6QSBc6woarkw8O23MbkiGBBsTT
VyZcnX3Rb+p2B1TgeRuP0uWF1/RacFxBxgnIV4nqajt63cadQwtprZHMykkxrHBS
Be5/tq+LYUmnzdlLMrDnYbhwvWYNWiB7pU2Cht8s7RiWrWx26RC/bgrQ8Soy2f/N
jX4cx0lYfpNcxSJmhxq4AqdpZgxOd5dvL1n3JTyJtNdD9R7VIrQz8Zdpy/3sOctZ
UelymraUUL/tTNO3HN81
=MmLs
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512


@The_Dark_Knight: So what is the definition you'd like to see used:

1. The original chain is the one that does not make backwards-incompatible changes to their source code, or:
2. The original chain is the one that is supported by (the majority of) the current core developers.


For Bitcoin, we might use (1) or possibly either one, but for Ethereum, it is very clear that (2) has happened in the past with the big DAO-fork (resulting in Ethereum Classic).

~Wiebe-Marten
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBCgAGBQJaCvumAAoJEBfPRUP+BdzsgQcP/32U/WeZZ+CLoatR6Ejrdd6O
4ngo1Wv8m1fFBSrvIvaYxPVRZcxjLZCpzWPSSbzR0+5fMg6NORW1uMpgMNoNWxxe
6ThSGOVR7Qbg/infLzBFNa1NW2fD4q1cHPNfSldVdZlzQC1doehY/OKVbiGL8VyK
802vU8rMEBcxjLQmYDEso1A7EoslJM5Np5LIGD0SErrYOY7Eaya9i5pqZ2+uXY/V
Ieg9S7Kir6HbMexJaD5+Wbd75vsU2QHEXUvirbO7MexK2xlE4NeLs6CHNUGxXpho
myVAOfAD/Tnp5XlgyjmX2e9nW0VPF21jO/2t3QL8BPkXC6Jra03Fsd3ETlqSIJRh
7tp1e889GOgHmd9zUBBCWRd3innRK53oWbx+iKuJ+SooeNTXNgr5Vz+xYPkx1xLa
/i54MysOys4f9LWRKp9b5ulyevslhgR1uw8JbavEMWI6EhAOTDXD+QeXA44VUth9
p2KEM4+fQnKwMurfvVpUGNXHjCBWKCoylfV66PpGfTjo3764ZD1YOm2oeyxEV2hh
QXqlKUniOxyX9Cpr8kho4/DxJBsXqwIhrfEh/+OW8gbQDGYPPJcRHEs2NqKlq1cI
HdrVHRyTZ+JnvepAkDUGDw/HhKHzhZBgo0SH0Tr593Ax4a1Hc8dJxsRj2nD6yZnn
WuX8JUgS62TE8RWWmzjF
=JzrY
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


The security between these two is not the same because when you do not store the transactions that caused a change, you lose the ability to audit what happened.


Ripple stores both the transactions as well as the effects the transactions had on the global state of the network. (See Ripple Tech Talk: Understanding Consensus (Mar 2015) for an in-depth description, this is covered at 22:34).

~Wiebe-Marten


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJaCnjPAAoJEBfPRUP+BdzsJ1QP/jtjn6lDyc042oAgApMmLNGu
+BdqkyPkNgRjk3hwkk4ChsYQVJaCieUlE8IGd6fxKn+jQm4Ngz9/F31Uc1S+jsnZ
FDxQfwZQiZfW13GV6v5r2AkTDQzynFKIzwBJPzk1anyZin8V1ozOZySGn2yE9BWm
2Xg4wr349nASX4nKM2KEPkjvkQ8+Chm1jjSo7li44m8qodaWgYgk0Z8Tc+D2Ploq
1osjuJo8A0emFx6dBqEHLUFtF7DoEzcaffEusZU4FzTtaGhbz7DBx3yva2KONtLf
qtESNzuHYuizst50XVGH9JHzQvQWCmVOM7Aazc0ErBJM50XOBks/ApHZnPPEEMNG
+cMH72lOT/a/HTBvarN87qcYSoGL1vmzAvBrsB9Vuw2ZQL3QJVbqKFuQrrgrjNTc
+PZiPk2aRFBR0ARN+UQkuzqXQzXPPIaa8LPYgti/dnYzgCRWBs57HE/zZ+MSd26q
pb9TlnuGuKndpeWd1A4fS6QGAD+7HGeCZwKdxeNNryE2R6lfl7F0ogr5TLa+5BIf
ohunPv06MRft/R5Dza+EH/k4A7G0dCpi5xl+1i1I+pXbkvkhsiguRFxlZCoXoZ9P
biamef+oeS0T+Ltvg+YNcJSQ91+1pGpKqNB28LMGVfpIC64Ru8fwS5zo5McFkomL
saQsGLVaWgPbOtY/HsoK
=PWLl
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Maybe it is good to mention here that:

1. It is possible to interact with a running Bitcoin client from other languages by using its RPC (Remote Procedure call) interface.
2. If you want to make drastic changes to the way the client ought to work, there are projects like the fairly new Tendermint that do the common work of distributed ledger systems for you, but allow you to write part of the functionality in any programming environment of your choice. (There probably are some strings attached, I do not know a lot about this project at this time.)

~Wiebe-Marten

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJaCg5oAAoJEBfPRUP+Bdzsy7UP/05obkSCgSCan7GE8EhsejsT
go9RHUW8VKAWvs7hAIPGCXAcSeDHoQHyI/VyVbde9PxhekFGXzvw0suF5Ako66wB
qvcqA0LgXhCrAmOwC9mJCpcL9EFKm0zcmxAy5p4TO+MPuOuSQCEXyFKjan9aIP2q
gdqCECl3PrBUjS8pd2kh3zFtJK9YwwgAlCLlr9gQATXoMFMcd4jNkfr86a/mGg9l
UWKMIkD+zpE/0MDdKNWl83RqTzH2ZK3pOOHPhyOm2178oGndhxZ3256ShgZbIa87
i5dx/d3RM4w8LAKJURqmJgQphqitJiOBMKUIbquWZdc+t01ae06NCrbSGL1Teqlv
Kbgp3Jgo9S8YZ9OeRKtbQzUkPTn5iPOmD3giHQq/wYEFNiv95Wpr0u3auUOpTlnR
nynfug+pulgykVvV5HuiHnknRqp+YpzqDON9aptrhQO6g+VS7nTdbpTiQ0LMPZk1
8qtk4+x1pbOcRDB0MqQjlCCtgy+psw/eQ+6QvE3DeBl5InLAp6yA6gRuZHHKbxCY
jFdAbr7M1+5dGuqf5Ak2qF++TyyMYD+1VTtlCSFKGkssLo0Ls5ivags7yGwom8XO
Or16XWxbCicQ4nkBUk4jGcUD2Q+Ch7H2N91djeOu48vAF5y0IY7DDcOxBWO7Va7p
WHjUb5SOtDFioBY8n5hY
=BMjm
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



What do you mean?

Ripple does have 'blocks', but in Ripple parlance they are called 'ledgers':

- - Transactions compete to be part of the next ledger.
- - Once a majority of nodes agrees on a set of transactions, a new ledger is created and propagated through all of the network.
- - The ledger contains a list of transactions, a reference hash to the previous ledger (building a merkle chain) as well as the changed 'state' of the system, similar to how Ethereum's system changes state. This ensures that all nodes can verify locally that the listed transactions indeed result in the given state change, making forks (near?) impossible.

Nodes are definitely decentralized in Ripple:
- - Everyone can run their own node.
- - Nodes can connect to any other node. In fact, users can configure which other nodes they want to connect to exactly.

Also, I am not really sure what "securities united with Paypal" looks like. Could you give some more information on this?

~Wiebe-Marten

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJaCg03AAoJEBfPRUP+Bdzsp8IP/3Ujqo+nTnlIziPjEFk+tOc7
BrcEVZIeX20dBxdJjHDLq/cxkmhDx5XPeYjRarMHgQAUwMI7kRNiZUx/fo50k71A
ggoTy+HSGdWqxo/DVUBg+fuL/QsyWmWg9+OQGAqP0UwA4/Ab9IZAB/v8ChkORZuc
nQ5NqB55w0oyHoVURNc2g8h5gm4udYUVxplLWf3vTjRhQ/aQrp5qeT/t1wcpqKCV
L+nW3MsCeqUYUspobJ14lJuYJHKxbxTdlFbzrJoCr9/hJnN94MpoABuOB5XSPzA2
c4n0FoQP7gCM9ZbTDttP634pyaifHUG4CKv97e1n7c6A5dT4yABf79XJNnSFK+Wg
70blykfqySOmiKI306jiEHraDNmNCAxsuKqT3EBQ0l/39ysLvCsOGFnUAMWAfHdy
1JZ/jvQjBSXd1eXnNiCAwCbseaaUY7DYlSH68RfTVyYneK1ppQVKU8QAu+G4emq0
etJEea3ThQ1OIRHmiGVaPIFTy14xJEvuxvLNAgcGzeZJmzS8/wmEKVniZaRyUZOF
zlg6ow7ueA+8HIps21e6E7H3ngFfF40hiCvuVcJwqru3pKgwxC7WMkA18Ds7RSBM
dV/VrEovHIx0xiBE2uf0E1/Up34FmD4INOGEncaghrIVhZcjAEugVvsH6+sETJTo
pIG2FR/nWAGZYtpLou7y
=NHLj
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1




Proper answer is: It depends. If you have only a couple of nodes and they can be trusted, a system like Paxos or other 'classical' Byzantine Consensus algorithms are probably a lot faster.

But if you have a lot of nodes, or a large group of nodes might be untrustworthy, these will not perform as well.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJaCa5vAAoJEBfPRUP+BdzsTusQANYtQAyieYuCN/0GOyqIYJRN
Iabo3aZbp1HI/2ML20InWerKRvsJTDLi3OfYVF1Ao+iUVQQTWS1PVIu+SuChJuUN
kK2xBFdLGzG6M0BMsdi3LxfLO1+IxpnMAK2GGJ17QYVt+F9PEA33EUs0s59YXDbS
/pZBVHnNFFUUZYwhvkpsF8+4XYkSFpGPaBqvLO9Z+rkLZKp/FkIVdVsaID1r981C
eZcRd0mf3rNEarodav+JSr5xWYyLoZo69+jRRblctG1HzVtJgE4fUmgIJUNrxgEe
wCPHly8/FFjD4HT+9wC9GQsAlMOJdT9UYRv20oxFu4avj1VJ+ZCQgGCEIqbDYCbC
002TpTXpSzLhtpOGQh0xKkWmxSNNOquJg/EhpdFcncyed7MOp/qcF1KCBo0LHVat
sBKoJ2xXPBmekxj1CKH3h/0JS8YG41QMeMtwzhunpBKvXMCQoz4Iv5btstEsyF6x
JKq0gui5FJYURhTnUXv8UVrPATZDLiwmBdEcE4FCIQtACkDIfBwBkaCZWE8getGy
kXQazaMhJmMOx1FkvFliE+uvc+XghTIjy+Ak2GDiWwYjR/Yp2QXrc5oS+5H7LHBL
SDwub4v6plN3cx1CiDhPGTUBz0/c6yFo4nQM+VLZMD4+jeCXeBjKqNMmbacO/e3u
AcHhb36QM0R/98XetwNb
=g6ZJ
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Recently I read the whitepaper about Ripple's consensus mechanism.
Of course, it has slightly other invariants than Bitcoin. For instance, in Ripple, when less than 80% of the network is honest, no honest transactions can be sent so the network grinds to a halt. On the other hand, if less than 20% of the nodes is honest, malicious transactions could be stored permanently. In Bitcoin, 51% is enough to rule the network and there is not a lot of introspection to decide whether the majority is still honest.
Another 'problem' that Ripple has, is that all users need to have a good 'Unique Node List'. If the UNL is not a proper representation of the network as a whole, then it might be possible to game the system earlier.
On the other hand, because being thrown off of the UNL by many nodes is a very valid response to misbehaving that is very bad for the node that tried to cheat (you are now effectively excluded from the network), this seems to keep all nodes 'in check'.

I saw someone describe this this as 'Ripple allows you to shoot yourself in your foot. But it also allows you to react when someone tries to shoot you in the head'.


At least for me personally, Ripple, at least for financial transactions, seems to have the better method to go from transaction requests to an ordered transactions list.
Keep in mind though that I have not worked with Ripple directly myself, so I am not yet aware of the warts that it might have. (Usually warts of any language, framework, technology or tool are harder to find, because they are not as widely publicized and talked about).

Proof of Work is definitely an 'arms race' with no end and we need a replacement. I think we can all agree about that. It does not really matter for the security of the network if 100 nodes mine or 10000 nodes mine, but that the latter takes a whole lot more energy.

I believe there is a lot of research focused in this area right now. Besides Ripple, here is a list of other tech I happen to know of that is being worked on, including some notes about their current progress:

- - Proof of Stake: Still not mathematically proven enough to be acceptable. (Do note that there are multiple different variants of Proof of Stake that each work slightly differently)
- - Proof of Elapsed Time: Greatly hyped by HyperLedger, but it is proprietary technology by Intel that only works if you have a certain Intel chip, and places trust in the Intel company. I don't know enough about how this should work to know why it wouldn't be possible to e.g. make a fake hardware chip.
- - Proof of Burn. Not entirely sure how the progress is on this one.
- - The IOTA Tangle. Seems a very promising method to build a DAG rather than a chain. A problem of which I don't know how they want to solve it, is how it is prevented that new info is added as children of 'old' elements, essentially 'inserting something in the past'.
- - The Hashgraph. Currently closed source (the team does claim that it will be published as FOOS at some point though). Also builds a DAG in a different way than the Tangle does. It is easier to see how the network as a whole prevents 'insertions in the past'. What is not yet known, is how/or even if the Hashgraph can work in a public context; it currently requires a static number of nodes (where all nodes know each other at the start) and where a supermajority of nodes is online at all times. There are some vaguely-described extensions to this, but these do not explain how someone could join and leave at any time as people can do with other ledgers.

This list is by no means complete.

~Wiebe-Marten
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJaCYtdAAoJEBfPRUP+BdzsKn0QAMxYDjBQMEG90V8cDQQnl8IX
m7pbQMh1LAgqhGqUf8HOp3iXVGpJ4UH3n3HSmkMJVAO3acXX+CCb3rQ+HBnUkB3j
6WhlEQVNXVRNiKzAMzwFxXxe12fT+0pSZxnIvCMQatmqg6WffOVRS6tej6+driif
bNwA+zdSaDO8IlWD0p0p+RFPTLLeV2D48TXjZF+4ZKiZviFD4wHfBEyfiRYXVcHy
AXi+7H4w2XFuKyPUydsDXT94HV2PVZ2uW+tPuXR51DKKtffCgMtP5tyj84EP5kuV
E+Z2B/RFKa1aQnmpS+f0c21Jiz6lnhv6TOt/0GUoRVYVmCpyW+x2vOIaOuKVb2ea
C4NuWJEsb6XkOAPODKMVjEsRDaQWlNwLgby/PRMSc6uZD8bOhAYCqU+7NsO9rPTK
2VKbyr0l82jmnMc4PtBaT1rDg1TuQVKAUyZlOgmqopKmnY3OHpEQny7u/o5G5LSL
RQWr6QNlxgIszhwcHsj/TgZdF6Xal4coAFURHLcvCMziFmKx9zABWUnanpzlPtb1
sQ69roskSU6AMmw6nReyrDlbCPyqX1zknjBnHGCSBFUt43AhBVgXzRWFgHYOeDtk
0MpEkMqHXMhEE3B5OjviwA3rtYMXI38uQjI/DREznP5PGpkrEI7r8zqs1oGqD1QI
pBeyuEhEA3mKNc9ZiWvh
=4i5F
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

This is an interesting thought that came to mind yesterday while sitting in the bus for multiple hours.


Merkle Chains

You all know about the concept of Merkle chains, where new information that is published refers back to earlier snippets of information, ensuring that:

 - New information depends on the old information.
 - Thus, we create a temporal ordering of information snippets.
 - This also means that the old information cannot be changed anymore without invalidating all information that (directly or indirectly) referred to it. (And if re-creating an information snippet is expensive, this means that the further in the past, the more expensive it would be alter a snippet).

Of course, this is one of the core concepts that is used in the Blockchain, with each block referring to the previous block.

[em]I make te separation here between a Merkle Tree, where tree elements contain a 'summary hash' of their children (allowing you to check tree consistency without requiring access to the whole tree's data), and a Merkle Chain, where every element refers back to the previous one. Obviously, a Merkle Chain is(/can be modeled as) a Merkle Tree where the 'root' element is moved to a subtree every time with the latest element becoming the new root. [/em]

Commit-Reveal

On the other hand, we have the commit-reveal protocol that now is used in some betting systems (like provably fair casinos), decentralized random number generators, decentralized voting systems and schelling-point-based oracle systems.

Here, every node first has some time to publicize a hash (called the commit) of the value they will reveal later.
After a party has received enough commits (or after a certain timeout has passed), it will publish its value.
Everyone can then check if the published value matches with the commit.

This simple protocol ensures that a node cannot 'change their mind' after seeing the result of (one or multiple) other nodes.

The combination

Interestingly, these two techniques are basically each others inverses:
When creating a Merkle chain, you first publish some information, followed by some information that refers back to it using a hash.
When using the commit-reveal method, you first publish a hash, and later publish some information that the hash turns out to refer to.

Besides this realization, something interesting happens when you enforce that a snippet of data should both refer back to a previous piece of information, as well as referring forward using a hash to the next snippet of information:

 - These hashes can only be predicted when all information (of which the currently-sent snippet is a part) is known prior to sending the first snippet.
 - To do it properly, the first information snippet and the last information snippet need to refer to each-other. You're now creating a basically closed immutable loop of information (that can only be replaced as a whole).


Maybe there are other interesting properties as well.

I am not sure if there are practical applications for this knowledge, but I thought it was interesting enough to share. Maybe it sparks some other idea in someone else's mind :-).

~Wiebe-Marten
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJaCYaNAAoJEBfPRUP+Bdzsdq0P/1Cz1s6I6lRtO/DuKx8iU6Qs
lDD0R8cbqZX+gTlhnkYMp+0M32qrsgEKQob+oNMfH2lJsV2l9Vr6YlPQO3T4lEpT
G3U0+TRGPeaqvJPSx2BIM0/qHgEKdrK9fsB6mBGFswjsK+sA+KVQIfRiBjHmw8cx
u8plAdnw/lDkLWKbtav3qr6m2oXtV2vl8qmnneF4aXPjogjvf+MvE3Am6ZEVd4fS
RQqoHmIGPRDWFaigcHGQuf0aJJ+lvSaA9Cgx+M33TujNu4JoaQGsLdJrH96YUwSQ
CH1r5rIaASTCyMqQbnI9xO/ZWt6UFeorz3yBO9OJNLPFFcrkNCLV+oG9RICqDP+C
2PjQGszf0OmpN3BEMksRwxElA1i+jG+yXlEAUpsT/vJsAcHrEUhFON232a+1ImEx
0Id7el+Sb070ztarEe8UpXpWQHuEiHzhx6c2Ull4J6BC+glvfoLbL/VRik8Iz2/+
quzeN/eVqzu9TRPYxJDZn0XLuMz/FjwhAgvj0ncWhYMv5Vi1WxiCzyN5MPTmPYqH
+DmRq0nhdZSmL1vGF89EVwNWMF+dryJg+kuckneCvSTZruAkBJ49OysZ/u1yT+RA
nfVSR2EfNSScS7Lh7PckZYdRFccfcCUMcYcoopVoJlsYgpW9pm5PVUTxP6EJjS+w
uWxLWWP/5BjFQbur4gE6
=OaM0
-----END PGP SIGNATURE-----